Комментарии 13
После перехода на Flutter RN вспоминается, как страшный сон. Должен признать, тому были и субъективные причины: RN аппу получили в наследство, с очень низким качеством кода - ни одного теста, простыни по 1500 строк кода в файле, куча ошибок в логах, процент крэша сессий до 30 (!!!). Около года боролись, пытаясь привести в чувство, но не слишком преуспели. То есть стало сильно лучше, но даже 5% крэшей - слишком много, ну и постоянные проблемы со сборкой утомили. Может, конечно, мы так и не научились его готовить, но каждый билд превращался в квест с неясным исходом - особенно, если сопровождался апдейтом библиотек или, не к ночи будь помянут, самого RN.
Плюнули, переписали на Flutter. Тоже около года заняло, но это просто другой мир - особенно после добавления null safety. Сейчас у нас 16 приложений на одной кодовой базе, никаких проблем со сборкой (CI/CD в полный рост), ноль крэшей, три платформы (Android, iOS, web) с минимумом платформ-специфик кода. Отсутствие OTA updates тоже сильно не напрягает: благодаря CI/CD и правильно организованномому процессу деплоя релизы, как правило, раз в неделю. Если надо, можем и чаще, но грубые ошибки обычно вылавливаются при тестировании, а для исправления мелких недельного цикла достаточно. Программисты счастливы, юзеры тоже 😁
Подписываюсь под каждым словом. После перехода на Flutter мы получили опыт (как пользователи фреймворка) совершенно иного уровня.
Кстати, если говорить по Code Push у Flutter сейчас есть стороннее, довольно неплохо работающее, решение - Shorebird. В проекте участвуют довольно значимые в комьюнити разработчики, он активно развивается. Работает достаточно хорошо для небольших изменений (фиксов), мы используем в проде без особых проблем
Если бы вы нормально переписали старый плохой код на хороший в том же RN, было бы еще лучше.
Фраза “особенно после добавления null safety” как бы намекает что вы не очень разбираетесь в правильном стэке для RN, а именно использовании TS.
Хотите меньше проблем с нативной частью, предпочитайте ненативные модули.
Если бы вы нормально переписали старый плохой код на хороший в том же RN, было бы еще лучше.
Опять голословные утверждения? Мы честно пытались – но годовые усилия не дали удовлетворительного результата. А на флаттере мы его получили, значительно быстрее и с меньшими усилиями.
Фраза “особенно после добавления null safety” как бы намекает что вы не очень разбираетесь в правильном стэке для RN, а именно использовании TS.
Там был ещё JS.
Независимо от этого, комментарий намекает на то, что Вы не вполне понимаете разницу между наличием оператора
?.и встроенной в язык sound null safety.
Мне кажется файлы по 1500 строк и ужасная архитектура пооекта - это не свойство RN
Я может конечно оптимист, но если уж у бизнеса все так расслаблено что он готов оплатить эксперименты, то можно и рефакторинг приложения устроить, но нужно конечно системно понять - что плохо, почему так, втащить TypeScript, если проблемы со сборкой - перейти на expo с их генерацией проекта из конфига, вообщем прям пункт за пунктом построить план улучшения и улучшать developer expirience.
Мне кажется файлы по 1500 строк и ужасная архитектура пооекта - это не свойство RN
Разумеется. Это свойство программистов, от которых мы тот код получили.
можно и рефакторинг приложения устроить, но нужно конечно системно понять - что плохо, почему так, втащить TypeScript, если проблемы со сборкой - перейти на expo
Это уже не рефакторинг, а полное переписывание. А коль скоро всё равно переписывать, то нет необходимости цепляться за конкретную технологию – тем более ту, которая уже однажды показала себя не лучшим образом. Я поизучал, что есть в кроссплатформе, ознакомился с опытом других и принял решение использовать флаттер. Не пожалел, решение вполне себя оправдало.
Если вы замеряли FPS до и после перехода, то было бы интересно их увидеть. Очень интересно
Разве Codepush не является грязным хаком с точки зрения версионирования приложения?
согласен с чуваком, самое вкусное не опубликовали показатели на рн и после на флаттере
FPS главного потока в RN почти всегда максимальный (60).
Нет.
Самое лучшее применение codepush - это при тестировании и доработке конкретного pull request отправлять изменения. QA просто сканируют qr код и без пересборки приложения работают с конкретной фичей
Это все очень ускоряет процесс разоаботки, когда компиляция идет только конда надо отправить сто то в сторы или при обновлении нативных библиотек (что планируемо и можно делать раз в квартал)
Если вы замеряли FPS до и после перехода, то было бы интересно их увидеть
Разве Codepush не является грязным хаком с точки зрения версионирования приложения?
Больше звучит как оправдание тимлида за неудачно выбранную технологию - про производительность скромно умолчали, но добавилась проблема отсутствия быстрых обновлений и следовательно костыль в виде BDUI.
А самая распространенная проблема в RN - бездумное добавление множества некачественных нативных зависимостей. Когда на флаттере появится столько же мусорных сторонних пакетов, "очумелые ручки" начнут их добавлять и там. Решение - минимум зависимостей, особенно нативных. А те что добавляются - тщательно анализируются, хотя бы по количеству issue и их поддержке. Работает кстати для любой технологии.
Road to Flutter – анализ опыта миграции с React Native