я использую react navigation и острую боль)

я использую react navigation и острую боль)

Куда без боли в РНе?)

я использую react navigation и острую боль)

А я использую Оперу

Artem, Timur, Vit спасибо!

Куда без боли в РНе?)

какой вообще смысл заниматься РН, если не будет боли)

Куда без боли в РНе?)

что такое PH?

кто здесь?

Куда без боли в РНе?)

Без сарказма спрашиваю

что такое PH?

реакт нейтив

а, на русском что ли, я всю голову сломал)

как отправлять данные / сообщения с помощью сокращения?

как отправлять данные / сообщения с помощью сокращения?

Откуда, куда и какого такого сокращения?

Откуда, куда и какого такого сокращения?

I want to enter data to server with redux

Enter data to server? Wtf is that suppose to mean?

Enter data to server? Wtf is that suppose to mean?

yes, but I do not know how, if using redux.

I want to enter data to server with redux

If you wanna send data to server, there are multiple solutions. The simpliest is 'redux thunk', but i personally prefer 'redux saga'

Ребят не подскажите какой самый стабильный router в react-native ?

я с react-navigation перешел на react-router https://reacttraining.com/react-router/ так как у них есть решение для сайта и для SSR

If you wanna send data to server, there are multiple solutions. The simpliest is 'redux thunk', but i personally prefer 'redux saga'

what redux saga is the same as redux thunk? could you have a simple example?

what redux saga is the same as redux thunk? could you have a simple example?

No, they are not the same, but both could solve your problem. If i were you i would choose redux thunk as a more simple solution. You can read more about it here: https://github.com/reduxjs/redux-thunk

what redux saga is the same as redux thunk? could you have a simple example?

But first you need to know, what a redux middleware is. These are the basics of redux, if you dont know it, then you should go through tutorials on official website of redux

No, they are not the same, but both could solve your problem. If i were you i would choose redux thunk as a more simple solution. You can read more about it here: https://github.com/reduxjs/redux-thunk

thanks, and i'm still learning redux, what i understand is redux store and other reducer still not understand

thanks, and i'm still learning redux, what i understand is redux store and other reducer still not understand

Well it's not the place where somebody would teach you the basics. You should teach yourself. This community is only to give you directions or some little tipps

Well it's not the place where somebody would teach you the basics. You should teach yourself. This community is only to give you directions or some little tipps

yes of course, I also understand it, thanks enlightenment

yes of course, I also understand it, thanks enlightenment

no problem

native-base header потерял тень, это нормально?

style elevation не помогает

Что в shadow thread происходит?

Что в shadow thread происходит?

В shadow thread работает yoga, которая осуществляет построение лэйаута исходя из RN'овских css-подобных св-тв, результатом этого процесса становятся проставленные св-ва (условно) x, y и width, height для каждой ноды, дальше эти св-ва отправляются в UI тред и реальные UI элементы перепозиционируются. Вот так, очень примерно.

В shadow thread работает yoga, которая осуществляет построение лэйаута исходя из RN'овских css-подобных св-тв, результатом этого процесса становятся проставленные св-ва (условно) x, y и width, height для каждой ноды, дальше эти св-ва отправляются в UI тред и реальные UI элементы перепозиционируются. Вот так, очень примерно.

Интересно, спасибо. Получается что react-native связан тремя потоками с нативным кодом?

Интересно, спасибо. Получается что react-native связан тремя потоками с нативным кодом?

сейчас систему тредов перерабатывают, емнизп в андроиде их 4, включая render thread, который работает с android L и выше

как-то так вроде треды распределены

как-то так вроде треды распределены

это в андроид?

это в андроид?

4й уникален для него, остальные также

Сколько интересно уже пожалело что взялось за rn

сейчас систему тредов перерабатывают, емнизп в андроиде их 4, включая render thread, который работает с android L и выше

это тот что fiber?

Сколько интересно уже пожалело что взялось за rn

с чего это? взвесив все плюсы и минсы RN лучшее что есть

давайте только без срача rn/flutter

давайте только без срача rn/flutter

интереса ради, у flutter есть решене для сайтов?

Интересно, спасибо. Получается что react-native связан тремя потоками с нативным кодом?

Не совсем... один поток - это JS, в нем работает JSC и собственно выполняет js-код. Один UI - это основной поток приложения и в iOS и в Android многие операции с нативными API и почти все, касающиеся UI можно выполнять только из него (это так операционки эти устроены). В отдельном потоке выполняется лэйаут теневого дерева, вот эта часть могла бы выполняться в других местах теоретически, но сейчас её в отдельном потоке держат. Дальше есть ещё модули, они могут выполняться в своих потоках, так что на самом деле их больше. И именно это устройство является причиной всего геммороя, что мы имеем. Но оно такое тоже не от хорошей жизни... это попытка избежать других проблем: 1. Отдельный JS-поток - позволяет долгому циклу в JS не блокировать UI 2. Отдельный теневой поток (лэйаут) - скорей всего родился из-за того, что yoga медленная, т.к. flex-layout по определению итеративный. 3. Отдельный UI-поток - требование осей. 4. Отдельные потоки для нативных модулей позволяют авторам модулей писать говнокод и не блокировать остальные части RN

это тот что fiber?

fiber я слышал только ui kit, в доках по тредам такого не упоминалось ?

fiber я слышал только ui kit, в доках по тредам такого не упоминалось ?

сори Fabric ?

сейчас систему тредов перерабатывают, емнизп в андроиде их 4, включая render thread, который работает с android L и выше

Интересно... надо заглянуть в код UI Manager в Android... по ходу там что-то не так, как я себе представлял

Не совсем... один поток - это JS, в нем работает JSC и собственно выполняет js-код. Один UI - это основной поток приложения и в iOS и в Android многие операции с нативными API и почти все, касающиеся UI можно выполнять только из него (это так операционки эти устроены). В отдельном потоке выполняется лэйаут теневого дерева, вот эта часть могла бы выполняться в других местах теоретически, но сейчас её в отдельном потоке держат. Дальше есть ещё модули, они могут выполняться в своих потоках, так что на самом деле их больше. И именно это устройство является причиной всего геммороя, что мы имеем. Но оно такое тоже не от хорошей жизни... это попытка избежать других проблем: 1. Отдельный JS-поток - позволяет долгому циклу в JS не блокировать UI 2. Отдельный теневой поток (лэйаут) - скорей всего родился из-за того, что yoga медленная, т.к. flex-layout по определению итеративный. 3. Отдельный UI-поток - требование осей. 4. Отдельные потоки для нативных модулей позволяют авторам модулей писать говнокод и не блокировать остальные части RN

Да вы Генадий энциклопедия) Спасибо доходчиво!

Я много времени убил пытаясь понять, как этот ворох безумного кода на самом деле работает (( Почему, к примеру в нативе определения св-тв многих дублируются в теневую ноду и в нормальную. Почему я не могу просто взять и получить в JS ровно тот текст, что сейчас в TextInput'е... и т.д.

Или почему если вставить неудачно SafeAreaView, то всё начинает в цикле "дрожать" на экране )))

Я много времени убил пытаясь понять, как этот ворох безумного кода на самом деле работает (( Почему, к примеру в нативе определения св-тв многих дублируются в теневую ноду и в нормальную. Почему я не могу просто взять и получить в JS ровно тот текст, что сейчас в TextInput'е... и т.д.

у нативных модулей есть свое api для асинхронности или вы о потенциальной возможности создания потока из нативного кода?

В ios специально это прописано: https://github.com/facebook/react-native/blob/0.56-stable/React/Base/RCTBridgeModule.h#L90 В Android так навскидку не скажу, но по моему тоже что-то подобное видел.

В android долгие операции(в том числе говнокод) тоже нельзя на ui потоке выполнять - получите anr

https://developer.android.com/training/articles/perf-anr

В старых версиях он в shadow-треде код модулей выполнял, сейчас создает под них свой тред под каждый.

интересно, нужно углубиться.

В android долгие операции(в том числе говнокод) тоже нельзя на ui потоке выполнять - получите anr

Ну понятно... просто я конкретное место, где описано поведение для нативного модуля вот так пальцем не могу показать сейчас )

непонятно. будет ли это актуально с приходом fabric

если они выпилят асинхронный bridge

Там только это, для точности. Я для простоты их тредами называю, но в iOS, это dispatch queue - абстракция над тредами

непонятно. будет ли это актуально с приходом fabric

Я не питаю особых иллюзий относительно fabric )

там возможно один тред пул на один queue?

и все модули юзают одну queue?

хз, не шарю в ios. 0)0

К примеру, я не верю, что redux-подобные архитектуры будут хорошо работать в языках процедурных по самому своему смыслу, типа C++. Либо это будет бесконечное копирование данных из одного места в памяти в другое, что очень медленно на современных процессорах. Либо это будет бесконечный lock-contention, если ленивое копирование делать.

там возможно один тред пул на один queue?

Нет, там может быть, один тред на несколько queue... GCD сам треды выделяет по необходимости...

ERROR: S client not available

К примеру, я не верю, что redux-подобные архитектуры будут хорошо работать в языках процедурных по самому своему смыслу, типа C++. Либо это будет бесконечное копирование данных из одного места в памяти в другое, что очень медленно на современных процессорах. Либо это будет бесконечный lock-contention, если ленивое копирование делать.

вот бы на pure на rn пописать)

Ну вот если бы для реализации бриджа и нативного кодинга использовался бы hackell, или ещё что, специально для оптимизации functional-кода предназначенное, то да... можно было бы посмотреть, что получится... А с C++... в общем, не буду никого расстраивать своими ожиданиями )))

К примеру, я не верю, что redux-подобные архитектуры будут хорошо работать в языках процедурных по самому своему смыслу, типа C++. Либо это будет бесконечное копирование данных из одного места в памяти в другое, что очень медленно на современных процессорах. Либо это будет бесконечный lock-contention, если ленивое копирование делать.

На сколько я понимаю, fabric должен разгрузить bridge и принести асинхроный рендеринг. Не объясните почему акцентируете внимание на redux?

Я мало знаю про фабрик, только то, что у facebook в блоге написано и то, что здесь Валентин постил.

На сколько я понимаю, fabric должен разгрузить bridge и принести асинхроный рендеринг. Не объясните почему акцентируете внимание на redux?

речь про redux-like архитектуру (TEA, если хотите)

Там было несколько причин перехода на fabric: redux-like (и immutable), синхронные вызовы в js...

да )

Ещё типа медленный dynamic dispatch (Очевидно намек на java и ObjC)

Но я знаю другое: C++ один из самых, блин, сложных языков из широко используемых... он реально огромен... и на нем очень легко писать плохой код.

но ведь нет альтернатив

непривычно в этом чате читать интересные вещи, а не про то, как очередной корявый npm пакет интегрировать в проект

Я много времени убил пытаясь понять, как этот ворох безумного кода на самом деле работает (( Почему, к примеру в нативе определения св-тв многих дублируются в теневую ноду и в нормальную. Почему я не могу просто взять и получить в JS ровно тот текст, что сейчас в TextInput'е... и т.д.

Супер )

Но я знаю другое: C++ один из самых, блин, сложных языков из широко используемых... он реально огромен... и на нем очень легко писать плохой код.

никто не будет на ленивом языке писать rn.

было бы конечно смешно. фейсбук нанимает отдел хаскелистов переписывать react-native с крестов.

было бы проще сделать транслятор из js в С++ и все были бы счастливы

вот бы на pure на rn пописать)

Зачем, если есть reasonml ?

было бы проще сделать транслятор из js в С++ и все были бы счастливы

Есть транслятор из дарта )

Есть транслятор из дарта )

ну такое )

К примеру, я не верю, что redux-подобные архитектуры будут хорошо работать в языках процедурных по самому своему смыслу, типа C++. Либо это будет бесконечное копирование данных из одного места в памяти в другое, что очень медленно на современных процессорах. Либо это будет бесконечный lock-contention, если ленивое копирование делать.

а зачем копировать?)

а зачем копировать?)

Можно не копировать (копировать лениво), но тогда надо защиту от одновременного доступа из разных потоков делать и это будет медленно )

так есть же иммутабельные структуры, они как раз для такого и предназначены

Коллекции на хешах быстро пересобираются

Специально оптимизируют жеж

так есть же иммутабельные структуры, они как раз для такого и предназначены

Что-то я их пока в Fabric не видел... и эти структуры довольно специфичны, чтоб их для дерева нод использовать.

так мы про Fabric говорим что ли) я чет запутался в вашем диалоге)

так мы про Fabric говорим что ли) я чет запутался в вашем диалоге)

Ну да... я собственно пытался обосновать свою позицию, что не жду от фабрика ничего хорошего ))

Коллекции на хешах быстро пересобираются

Там C++, мы когда-то пытались на нем google хеши использовать... типа самые быстрые... в общем да, быстро, но с кучей подводных камней, типа вырожденных случаев для которых всё становится медленным и т.п.

Вообще, с моей точки зрения, единственная архитектурная проблема RN в настоящем его виде (да, есть куча не архитектурных типа багов, платформозависимых компонентов, отсутствия некоторых критических компонентов), так вот, единственная настоящая проблема сейчас, это невозможность синхронного вызовов из натива в JS. Но это вообще не про фабрик, насколько я вижу... это про однопоточность JS... не проблема дернуть что-то туда из натива, JSC это позволяет, проблема, что тебе придется ждать, пока доработает текущий цикл JS кода... а потом отработает твой вызов. Это займет непредсказуемое время, которое твой поток будет ждать, если это UI-поток - всё зависнет на это время, если это layout - не будет лэйаута, если это твой нативный модуль, в нем не будет ничего происходить... И в текущем дизайне и вообще в любом другом дизайне без модификации JS api, я решения этой проблемы не вижу... возможно оно есть где-то в районе вывода в JS чего-то похожего на Web Workers... не знаю...

Примеры проявления этой проблемы: невозможность произвольно управлять анимациями из JS, опаздывающий measure и onLayout, проблемы с управляемым TextInput, кривая система респондеров и хендлинга тачей с огромным кол-вом багов... всякие KeyboardAvoidingView и SafeAreaView, проблема с лэйаутом кешируемых изображений и прочее...

Да решение то на поверхности - блокировать UI тред в нативной части. Но тогда будет очень сложно хвастаться 60fps UI, потому что вся ответственность за конечный перфоманс ляжет на девелоперов. Скорее всего добавят апи с синхронным вызовом и огромным предупреждением, что ребят, используйте на свой страх и риск.