Это проблема. На самом деле вам не консультант нужен скорей всего. Потому что состояние "начальная настройка завершилась и можно только на js писать" увы, очень недолговечно. У вас в команде никто не выполняет роль нативного разработчика. А эта роль нужна, либо самим учиться, либо нанимать кого-то, если на две платформы, то это может быть и два человека в зависимости от... в общем, кто-то должен знать натив android и натив ios.

Большое спасибо за ответ! Так и есть. Придется самим учиться, видимо. Я вот сейчас после танцев с бубном все запустил. Но это случается постоянно и внезапно. Выматывает просто неимоверно. А как распределяются задачи? Все, что после нормального старта приложения — js-разработчик, все, что кроме этого — нативщик?

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

А нужен ли тогда React Native, если в команде есть нативщики, разбирающиеся в обоих языках?

Мне интересно, в каких случаях без нативщиков не обойтись.

Я могу только за себя говорить. Дело не в скорости реализации фич. Я многое нативно бы написал быстрее и проще, чем на js. Но писал бы это 2 раза. Сейчас в проекте кодовая база примерно 1-5% натив (не кроссплатформа), остальное js на android и ios, из этого ещё процентов 20% и в вебе работает. Довольно большая экономия. (Цифры из головы, если надо - могу точнее посчитать)

Это понятно. Но например?

А какие части на нативах?

Навигация и ещё несколько интерфейсов на всякие sdk

А с нативной навигацией вьюхи реакт нейтива на каждый роут рендерятся? Речь о чем-то более нативном, чем react-native-navigation и дохлом native-navigation?

Я пару недель назад переписывал апп с react- navigation на react-native-navigation С точки зрения передачи данных, каждый экран - отдельное "приложение" Т.е. createContext() будет вызван заново и т.п. Там принцип работы с данными между вьюхами другой

Во первых да, во вторых нужен был 3D-Touch

Ну и т.к. надо было причесать работу с данными и сделать local persistence, RNN вписался нормально в это все

Сколько скринов в приложении? Много времени ушло на миграцию?

Пара дней Скринов по памяти не скажу, то-ли 6, то ли 7

Почему решили переписать? Быстрее стало?

Пара дней непосредственного переписывания? Или сюда включено время изучения доков react-native-navigation?

Не знаю что на android, но на ios RNN ощущается как что-то абсолютно нативное. react-navigation субъективно проще для понимания, но выглядит абсолютно ненативно.

react-navigation и есть ненативный. js-имитация ж.

Даже с react-native-screens?

Даже с react-native-screens?

Впервые слышу 😅

Ну с переходами вперед может и норм, но свайп назад просто ужасен, например.

Эх, жаль, что Airbnb дропнули разработку native-navigation.

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

А с нативной навигацией вьюхи реакт нейтива на каждый роут рендерятся? Речь о чем-то более нативном, чем react-native-navigation и дохлом native-navigation?

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

Лучше, чем ничего. Но хочется именно на хорошие практики и чистые архитектуры посмотреть.

Подожду, пока 0.60 релизнут, хехе.