Но меня вот что волнует, даже после беглого осмотра этого хозяйства, видно, что можно размер бандла уменьшить довольно значительно. В моем случае раза в полтора, думается... Где-то 100Kb можно от RN было бы выкинуть - ART, Experimental, Navigation, ListView, BatchedBridge и ещё по мелочам набежит, думаю. Дальше bluebird, pretty-format - я без них могу прожить (-130Kb) Дальше, если бы react-native-firebase перетряхивался, то было бы (-100Kb) Ну и мелочь всякая... regenerator-runtime, который мне не сдался вообще (ну не использую я await), lodash-es с lodash схлопнуть... если бы оптимизация была нормальная ещё бы половина mobx ушла (я довольно мало от него использую) А, точно... ещё там зачем-то ReactFabric на 70Kb... хотя он экспримент, и его по умолчанию бандлить не надо ) В общем в итоге,думаю бандл был бы не 1.7Mb, а около 1Mb, что как бы значительно лучше... И в этом свете странно, что когда я haul пробовал, он давал более объемные бандлы, чем metro... надо бы ещё раз проверить

Может его вообще, это... сперва через rollup пропустить перед продакшном, а потом уже в metro засовывать? )

Может его вообще, это... сперва через rollup пропустить перед продакшном, а потом уже в metro засовывать? )

Так а какую роль играет конечный бандл в продакшн сборке, если там трансляция в натив идет

Так а какую роль играет конечный бандл в продакшн сборке, если там трансляция в натив идет

Конечный бандл загружается в JSC, интерпретируется в нем и его код как раз работает в приложении. Соответственно его размер влияет на потребление памяти и скорость начальной загрузки приложения.

Конечный бандл загружается в JSC, интерпретируется в нем и его код как раз работает в приложении. Соответственно его размер влияет на потребление памяти и скорость начальной загрузки приложения.

но из этого выходит, что RN не до конца нативный, если все таки присутствует прослойка даже в релизной сборке

но из этого выходит, что RN не до конца нативный, если все таки присутствует прослойка даже в релизной сборке

Именно. Виноват, не дочитал до конца фразу. Да. RN не транслирует код в натив

открытие )

Именно. Виноват, не дочитал до конца фразу. Да. RN не транслирует код в натив

Весьма занимательно

Я то думал, что интерпретация имеет место быть в деве, но никак не в релизных сборках

Не знаю хорошо это или плохо... но я вообще не очень представляю, как такие динамические языки, как JS оттранслировать в натив... можно некий байт-код довольно низкоуровневой виртуальной машины, но это фактически не даёт преимуществ... потому что это всё те же динамические структуры данных... и всё равно транслятор весь встраивать, потом что eval и new Function (мне казалось в v8 даже был специальный бинарный формат для сериализации разобранного AST, но не уверен)... толку в общем от этого представления нет... Flatter способен транслироваться в натив, но там не javascript... это другой язык...

Не знаю хорошо это или плохо... но я вообще не очень представляю, как такие динамические языки, как JS оттранслировать в натив... можно некий байт-код довольно низкоуровневой виртуальной машины, но это фактически не даёт преимуществ... потому что это всё те же динамические структуры данных... и всё равно транслятор весь встраивать, потом что eval и new Function (мне казалось в v8 даже был специальный бинарный формат для сериализации разобранного AST, но не уверен)... толку в общем от этого представления нет... Flatter способен транслироваться в натив, но там не javascript... это другой язык...

ну дарт это отдельная песнепляска

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

Не знаю хорошо это или плохо... но я вообще не очень представляю, как такие динамические языки, как JS оттранслировать в натив... можно некий байт-код довольно низкоуровневой виртуальной машины, но это фактически не даёт преимуществ... потому что это всё те же динамические структуры данных... и всё равно транслятор весь встраивать, потом что eval и new Function (мне казалось в v8 даже был специальный бинарный формат для сериализации разобранного AST, но не уверен)... толку в общем от этого представления нет... Flatter способен транслироваться в натив, но там не javascript... это другой язык...

если под нативом иметь ввиду Android SDK(java), то флаттер не транслируется в него

он сразу в Native Library ассемблируется

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

Ну я с дуру собрал простенькое приложение на swift и ощутил эйфорию, как с этим жить теперь.. не знаю

он сразу в Native Library ассемблируется

В смысле в машинный код, не JVM байт-код?

В смысле в машинный код, не JVM байт-код?

конечно

Dart не JVM язык

Ок... я и не писал, что JVM... переспросил чтоб точно знать... потому что не работаю с ним )

он собирается в бинарь(.so)

Это логично, т.к. для iOS и прочего им всё равно только в бинарь собираться.

Ну я с дуру собрал простенькое приложение на swift и ощутил эйфорию, как с этим жить теперь.. не знаю

Жить просто... если вам нужно только приложение под ios или только под android и у вас под рукой нативный разработчик - то конечно RN не даст преимуществ, только недостатки (больший размер приложения, медленней, ненативные анимации)... Но если вам разрабатывать под обе архитектуры - стоит уже задуматься, а если вам удастся ещё и с web часть кода пошарить, то дальше на поддержку этого будет уходить намного меньше ресурсов... Настолько "намного", что это скорей всего перевесит недостатки...

Схема, которую RN предоставляет просто сильно дешевле для конечного заказчика (по крайней мере в теории)

Схема, которую RN предоставляет просто сильно дешевле для конечного заказчика (по крайней мере в теории)

Вот тут есть две крайности. С точки зрения человекачасов и оплаты разрабов RN может быть дешевле, но для конечного клиента цена наверняка будет такой же

У нас в компании сейчас тендер на разработку приложения на RN под iOS и Android и по сути она равна стоимости разработки отдельных приложений. Не буду озвучивать конкретные цифры, просто мы запрашивали разные варианты

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

Ну да... на конечное ценообразование влияет ещё очень много факторов... макретинг не последний из них )) В конце концов, себестоимость кока-колы и просто минеральной воды примерно одинаковая ведь и примерно равна стоимости упаковки, а цена различается...

Ну да... на конечное ценообразование влияет ещё очень много факторов... макретинг не последний из них )) В конце концов, себестоимость кока-колы и просто минеральной воды примерно одинаковая ведь и примерно равна стоимости упаковки, а цена различается...

ну а если по сабжу, то кроссплатформенность это круто, но я пока с Web ее не представляю без реализации FlatList

Ребят, всем привет Суть проблемы такова: Если я убираю export default и оставляю connect, то StackNavigator работает, но при этом редукс не работает

Как это можно пофиксить?

Чтобы работало и то, и то

дефолтный экспорт может быть только один

вообще убирай дефолтные экспорты

оставь expor const ConnectedApp = connect()() export const StackNav = createStackNav()

import {ConnectedApp, StackNav} from 'path_to_file'

ну а если по сабжу, то кроссплатформенность это круто, но я пока с Web ее не представляю без реализации FlatList

Так ведь шарить не только компоненты можно... вот в том скриншоте, что я присылал виден модуль yetsi-core - он довольно большой (1/3 всего приложения). Там модели/логика и апи. Он отдельный модуль именно потому, что используется ещё и в вебе. А FlatList - не ноухау в RN, технология известная и в вебе давно применяется... вот, к примеру: https://github.com/bvaughn/react-virtualized

ради интереса запустил мак ос в virtualbox в ubuntu. bundle почти в 2 раза медленее. Если отключить анимации, то вполне юзабельуно, даже fullhd видео играет. жду пока xcode скачается. Ужасная идея запустить билд сервер на локалхосте, чтобы ios cобирался...

Так ведь шарить не только компоненты можно... вот в том скриншоте, что я присылал виден модуль yetsi-core - он довольно большой (1/3 всего приложения). Там модели/логика и апи. Он отдельный модуль именно потому, что используется ещё и в вебе. А FlatList - не ноухау в RN, технология известная и в вебе давно применяется... вот, к примеру: https://github.com/bvaughn/react-virtualized

В этом плане да

Что за случай с Медузой?

Чят, а подскажи, пожалуйста, либу/способ чтобы на клик по Image, само изображение открывалось в полный экран. Ну типа как галерея — кликаешь на превью изобржаение, и оно во весь экран.

@merryjs/photo-viewer

@merryjs/photo-viewer

Забыл уточнить, что мне для Экспо надо. :-) Этот вариант, скорее всего, не прокатит.

А что такое медуза

Написано так, как будто это что серьёзное и крутое

Всем привет! А кто-нибудь делал пуш-уведомления с детаченным экспо клиентом? Вижу решения для не-экспо или для недетаченного экспо. А есть ли именно с таким кейсом возможность их запустить? На иос.

А что такое медуза

meduza.io же

Первый раз вижу

Спасибо!

всё меньше дают - битки заканчиваются

Народ, всем привет! Может кто-нибудь в личку написать, как дебажить приложение при использовании андройд эмулятора

буду очень признателен

Народ, всем привет! Может кто-нибудь в личку написать, как дебажить приложение при использовании андройд эмулятора

Извините, что не в личку, но я считаю, что это знание должно быть доступно всем! 😄 1. Если вас интересует нативный дебаг, то: https://developer.android.com/studio/debug/ 2. Если js, то: https://facebook.github.io/react-native/docs/debugging#chrome-developer-tools

Прикольно, думал у медузы с самого начала был RN. А у них, оказывается, натив сейчас.

А зачем они нативщиков увольняют?

А зачем они нативщиков увольняют?

много просят денег, и мало работы когда есть реакт нативщики

много просят денег, и мало работы когда есть реакт нативщики

Ну просто первое время они могут быть нужны, наверное...

> много просят денег вы так говорите, как будто это плохо 🙂

не плохо если они работают, но тут разговор про то что вся работа теперь на реакт нативе

Все так, поменяла компания стек решением менеджмента, меняет инженерный состав чтобы соответствовал, обычное же дело.

А имя компании и название технологии это детали которые не стоят внимания, в данном случае.

для таких штук испульзуите это https://www.npmjs.com/package/react-native-root-toast ???

для таких штук испульзуите это https://www.npmjs.com/package/react-native-root-toast ???

Я для таких штук обычно реализую свой велосипед - потому что: 1. Это просто 2. Конечное решение получается компактней чем в универсальных модулях 3. Конечное решение лучше интегрируется в модель данных приложения

Вот вообще говоря не факт что экономия ресурсов есть. Спустя почти год разработки (50+ человек на одном приложении) для нашей компании вопрос ещё открытый, насколько мне известно. Опыт других компаний, которые делятся им в сети, тоже не однозначный. Технология точно имеет право на жизнь, но о превосходстве перед нативной разработкой говорить определенно рано.

Подобное и о ксамарине сказать можно

Именно, и это прямой конкурент для RN.

В формсах можно шарить 80-90% кода, в нативе около 40%

И тоже всё весьма непонятно насчёт выгоды

Ничо, ничо, скоро Флаттер всем покажет 🌝🌝🌝

Лол

Еще бы дарт выкинуть оттуда)

чем фэйсбук лучше гугла и эпла?

он может потерять интерес к проекту и в лучшем случае открыть полностью

https://medium.com/zynga-engineering/why-how-words-with-friends-is-adopting-react-native-b24a405f421c

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

^^ этому ответ был)

В этом и проблема, мы не знаем как далеко пойдёт Facebook с RN

Могут хоть завтра закрыть и все)

хз интересно ли кому. Сегодня тыкал xcode внутри virualbox на ubuntu. os и сама среда в 80% работает нормально. на симуляторе небольшие артифакты отрисовки, но скорость приемлема. Отклик явно быстрее чем teamviewer. Cборка проекта по ощущениям как на слабом mac mini. хост w530 c i7 с ssd.

хз интересно ли кому. Сегодня тыкал xcode внутри virualbox на ubuntu. os и сама среда в 80% работает нормально. на симуляторе небольшие артифакты отрисовки, но скорость приемлема. Отклик явно быстрее чем teamviewer. Cборка проекта по ощущениям как на слабом mac mini. хост w530 c i7 с ssd.

а долго ли запущен был xcode? он имеет свойство уходить в себя и что-то там индексировать, мне удавалось ~2 часа в нем ковыряться, пока не наставал момент, когда дикие тормоза игнорировать нельзя было и только ребут, но то винда с vmware, так же i7, ssd, 16гб

а долго ли запущен был xcode? он имеет свойство уходить в себя и что-то там индексировать, мне удавалось ~2 часа в нем ковыряться, пока не наставал момент, когда дикие тормоза игнорировать нельзя было и только ребут, но то винда с vmware, так же i7, ssd, 16гб

тоже часа 2, может чуть больше. но я ковырял больше js, в xcode только симуляторы переключал. сам по себе xcode не такой уж стабильный, может дело было не в окружении.