Обновить

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

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

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

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

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

Публикации