Обновить

React Native в 2026 году: New Architecture, нативный код и AI в реальном проекте

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели7.1K
Всего голосов 2: ↑1 и ↓1+2
Комментарии6

Комментарии 6

Хорошая формула про одну продуктовую модель и осознанно выбранные нативные участки. На границе native -> TypeScript я бы только не оставлял payload как Record<string, unknown>, особенно для push и background-событий. Такое событие может пережить процесс приложения, прийти повторно после холодного старта или быть обработано уже новой версией JS-кода после обновления. У нас в таких контрактах полезны eventId, schemaVersion и типизированный payload для каждого вида события, а перед внешним эффектом - дедупликация по eventId. Тогда можно отдельно тестировать не только симметрию iOS и Android, но и совместимость сохранённых событий между версиями приложения. Версионируете ли вы native -> TS контракт и проверяете ли сценарий, когда старое событие доставляется уже после обновления клиента?

Да, версионируем. В статье просто сильно упростил пример. В реальности там есть eventId, schemaVersion, типизированный payload и дедупликация. Старые события после обновления тоже отдельно проверяем. Спасибо за замечание!

Отличный обзор! Мне как react native разработчику откликаются описанные проблемы. Про AI я бы от себя ещё добавил, что агентская разработка сделала дешёвым качественный UI/UX. Теперь агент сам за короткое время может добавлять и отлаживать разные механизмы взаимодействий внутри экрана, на что разработчику раньше приходилось тратить часы и дни. А то и вовсе разные "удобства" было проще убрать в бэклог, чем тратить на них ресурсы.

Спасибо! Полностью согласен — AI особенно хорошо ускоряет небольшие UI/UX-доработки, которые раньше легко могли зависнуть в бэклоге.

Но у нас это всё-таки не полностью AI-разработка, скорее где-то 50 на 50. Компонентную базу и основные правила интерфейса мы изначально делали сами. А теперь AI уже из готовых компонентов собирает экраны, предлагает варианты взаимодействия и помогает быстро всё отладить.

Как раз об этом хотим подробнее рассказать в следующей статье: где AI реально экономит дни работы, а где без человека пока никуда.

Очень смешной раздел про архитектуру. Вы правда проиграли когда выбрали реакт. Причем выше даже перечислили кучу проблем которые сразу из коробки поставляются...

Мб вам рано об архитектуре думать ?) Лучше взять хороший инструмент/фреймворк где об архитектуре уже подумали заранее и нет целых КЛАССОВ типичных проблем, как считаете ?

Возможно со стороны так и выглядит :) Но пока React Native дал нам больше, чем забрал: одна команда, быстрые релизы и общий код для двух платформ. А проблемы есть у любого стека, просто у каждого свои.

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


Ну и справедливости ради: раздел про архитектуру мы сократили примерно с 15 абзацев до трёх. Поэтому сейчас он, возможно, выглядит немного поверхностным и слишком категоричным.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации