Comments 6
Спасибо за интересную статью! Давно тут на хабре не было новых статей про РН.
Подскажите пожалуйста, правильно ли я понял, что приложение на реакт-нейтив может обновляться прямо "на лету" во время пользовательской сессии? Условно, юзер открыл приложение, переходит на какую-нибудь определённую страницу, которая может лениво подгрузиться с новым обновлением?
И может ли быть такое, что юзер зашел на эту страницу, увидел, условно, старый интерфейс. Потом закрыл её и спустя какое-то время снова её открыл, а там уже новый обновлённый интерфейс? При этом саму апку он не закрывал?
Да, все так, на гитхабе есть пример, там как раз фичи/экраны с их логикой грузятся только при переходе на них. Это небольшие кусочки кода (если надо, то с ресурсами/картинками), потом код подгружается в движок в рантайм, запускается и рисуется UI.
Кейс обновления интерфейса без закрытия апки мы не пытались решить никак. Мысли такие: технически конечно сложная вещь, но звучит вполне реальной. В таком кейсе есть смысл только если мы юзера оставляем на экране, на котором он был, а значит надо стейт сохранять. А тут в голову сразу приходят проблемы: если стейт поменялся между версиями, то это уже миграции писать надо какие-то... ну и все такое. В общем все это сделать как будто можно, но сложность несравнимо высока с профитом от этого.
Спасибо за ответ! Про стейт то я сразу и не подумал )
У меня возник вопрос по одному гипотетическому случаю. Возможно это будет звучать как "высосанный из пальца" пример, но я был бы благодарен, если бы вы помогли мне с ним разобраться.
Представим, что в приложении есть сервис А, который запускается при старте приложения и экран Б, который использует данные из сервиса А
1. Пользователь заходит в приложение и сервис А запускается
2. В этот момент происходит новый релиз, в котором был обновлен экран Б и сервис А (предположим был расширен стейт или апи)
3. Спустя некоторое время пользователь открывает экран Б, к нему подгружается бандл с новым экраном, который требует больше данных из сервиса А. Но сервис А был запущен со старой версией и там необходимых данных нет
Как-будто при такой последовательности могут возникнуть проблемы. Хотя, вероятно, сам шанс такого крайне невелик и им можно пренебречь? Или я упускаю какой-то момент и этой проблемы, в принципе, не существует?
Не такая уж и высосанная из пальца ситуация, в этом случае все отработает хорошо, такой порядок:
При запуске будет скачена вся мета инфа о самых актуальных модулях (этакий пекедж джейсон)
Если после старта будет новый релиз, то юзер все равно до перезапуска про это не узнает
Ну а бандлы будут качаться при заходе на экраны в соответствии с последней загруженной метой
А как у вас построен workflow? И что получает юзер после установки из стора - там сразу качаются все актуальные обновления?
Мы просто обновления по воздуху (expo-updates) используем только для доставки хотфиксов (есть же правило сторов - не менять существенно функционал в обход).
А доставку фич реализовали постоянно делая релизы через CI/CD (закрывая не реализованные фичи фиче-флагами).
И что получает юзер после установки из стора - там сразу качаются все актуальные обновления?
Все последние на момент сборки самого приложения бандлы зашиваются в apk/ipa, поэтому юезр на первом старте не качает десятки Мб. Но если на момент запуска есть новые бандлы, то они будут обновляться.
(есть же правило сторов - не менять существенно функционал в обход).
На сколько я его понимаю, они просят категорически не менять приложение, а что-то дополнять всем ок. Многие компании используют те же самые флаги для показа того или иного функционала, BDUI или еще что-то и я не знаю случаев что бы за это прилетали баны. Тут подробнее инфа, пункт 3.3.1 B
Как мы в Купере переписали CodePush для React Native. Быстрее, легче, удобнее