Я бы сказал так, писать на RN только на бумаге и в курилке быстрее. По факту мы сейчас код, вместо того чтобы писать один раз, пишем три раза - на котлине под андроид, на свифте под айос и бизнес логику и врапперы на js для RN. Почему? Потому что как только что-то сложное, кастомное, с анимациями, оказывается что нативка вытирает ноги обо все и никуда от этого не деться. Бизнес логика - да, удобно. Стоит оно того? Только если у компании ОЧЕНЬ много денег или ОЧЕНЬ скромные запросы.

кстати, спрошу у эксперта по котлину, где сильнее выведение типов, в котлине или во flow?)

Я далеко не эксперт, но в котлине, как по мне, выведение предсказуемей. Но это скорее связано с тем что в джаве в принципе нет утиной типизации, что сильно упрощает жизнь в этом смысле.

Я бы сказал так, писать на RN только на бумаге и в курилке быстрее. По факту мы сейчас код, вместо того чтобы писать один раз, пишем три раза - на котлине под андроид, на свифте под айос и бизнес логику и врапперы на js для RN. Почему? Потому что как только что-то сложное, кастомное, с анимациями, оказывается что нативка вытирает ноги обо все и никуда от этого не деться. Бизнес логика - да, удобно. Стоит оно того? Только если у компании ОЧЕНЬ много денег или ОЧЕНЬ скромные запросы.

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

Эм так а без RN нужно будет делать тоже самое, только еще и бизнес логику дублировать

не знаю как в ваших приложениях, но в тех, в разработке которых я учавствовал, бизнес логика это от силы 5% кода. Мобилки это про клиент, про UI, анимации и юзер экспириенс. Вся бизнес логика должна быть вынесена на сервер, в идеале.

не знаю как в ваших приложениях, но в тех, в разработке которых я учавствовал, бизнес логика это от силы 5% кода. Мобилки это про клиент, про UI, анимации и юзер экспириенс. Вся бизнес логика должна быть вынесена на сервер, в идеале.

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

а у меня обычно наоборот 😄 что то в духе сделал красивую кнопку, и потом каждый спринт меняешь надпись в ней)

Кроме того RN великолепен для приложений которые раньше бы писались на cordova. По сути прямой апгрейд

так все решается динамической загрузкой надписи по идентификатору 😉

безусловно, переход от вебвью в нативный рендеринг это отлично. Вопрос в том стоит ли нативные приложения переписывать на RN?

Для упрощения разработки в отдельных случая может быть. Я бы смотрел по количеству нативных модулей, если все приложение только из них по сути и состоит то RN странный выбор конечно

не соглашусь) часто все забывают букву R в RN) я лично не видел нормального декларативного описания в нативке (в коде, манифест и IB не считаются 🙂)

Так декларативность будет заканчиваться при переходе в нейтив и в результате будет микс из декларативности и императивности.

это норм, те же монады так и устроены например

Просто контролировать анимацию из js допустим не получится же

Я к тому что если большая часть приложения из нативных модулей - от декларативности мало что останется

вы видимо как то не так понимаете декларативность

Перефразирую - в процентном соотношении часть приложения написанная в декларативном стиле будет примерно равна части приложения написанной на js. Если большая часть приложения - нативные модули - большая часть приложения будет вполне императивной.

Можно конечно просто воспринимать нативные модули как вещи в себе, про которые я просто знаю их внешнее апи и использую в своем JS приложении и в таком случае они, внешне, вполне декларативны

тут как бы нет смысла рассматривать в черно белом цвете, либо то, либо то. имхо даже небольшая часть описанная декларативно это хорошо

Ну, тут на практике зависит дает ли нам это достаточно преимуществ в плане облегчения поддержки/разработки приложения, в сравнении с если бы приложение было целиком нативное? Я честно говоря не знаю, не писал приложений где бы они прям вот совсем из кастомных нативных модулей состояли.

это кстати для меня большой вопрос в том же Kotlin Native, там не будет реакта)

опять же имхо - для меня большой плюс что в RN приложении мне не обязательно даже знать что внутри компонента до поры до времени) надо будет сделать быстро новую фичу, сделаю на js из View, да будет не нэйтив лук, но зато быстро. со временем спокойно можно будет переписать на нэйтив)

У меня есть главный StackNavigator в котором как screen указан компонент который содержит небольшую разметку, например "Home" и в разметке этого компонента у меня есть TabNavigator. Структура примерно такая: StackNavigator |— Home |— TabNavigator |— TabA |— Settings Немогу из "TabA" перейти на экран с настройками. Как я понял из-за того, что я использую TabNavigator внутри компонента, а не напрямую передаю его StackNavigator-у теряется контекст и TabNavigator не знает о родительких маршрутах. Никто с таким не сталкивался?

Ребят кто знает как запретить во время перехода через stack navigator вернутся назад ? Даже если ставлю header null все равно можно пальцем вернуться назад