React Native 0.88: новая модель событий и проверки интерфейса

React Native 0.88 меняет внутренний путь событий, сохраняя, по заявлению команды, поведение публичных event props. Поэтому обновление не означает обязательную переделку всех обработчиков. Приоритет проверки — библиотеки и собственный код, которые обращаются к внутренностям событий, плюс реальные действия пользователя во вложенном интерфейсе.

Default-механизм и Canary API — разные части новости

React Native 0.88 выпущен 19 октября 2026 года. Web-based event dispatching через EventTarget стал путём по умолчанию. Однако imperative addEventListener, removeEventListener и dispatchEvent на native refs в анонсе доступны в Canary. Нельзя брать такой пример как подтверждённый стабильный API обычной поставки.

Справка MDN по EventTarget объясняет интерфейс объектов, получающих события и поддерживающих слушатели. Это справка понятия, а не обещание, что любой браузерный пример без изменений работает в React Native. Применимые native API и статус проверяют по документации выбранного выпуска.

Проследить одно нажатие полезнее, чем проверять весь интерфейс наугад

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

Это наша матрица пользовательских проверок, не найденные дефекты React Native. Она не требует одинакового поведения всех вложенных элементов: нужный результат задаёт конкретный интерфейс. Иначе команда примет расхождение за ошибку, не договорившись, что должно было происходить.

Публичный контракт не равен внутреннему устройству библиотеки

Анонс говорит о сохранении имён props, объектов событий и порядка вызовов; direct events вроде onLayout остаются на цели, touch responder system не заменена. Отдельно команда просит проверять код, выходящий за публичный API во внутренний реестр событий. Эти сведения помогают выбрать приоритет, но не отменяют проверки своего приложения.

Если проблема проявляется только в стороннем компоненте, сохраните его версию, используемую конфигурацию и минимальную последовательность действий. Не начинайте с массовой замены всех обработчиков. Сначала установите границу: публичный контракт приложения или предположение библиотеки о прежних внутренностях.

Не добавлять Canary-зависимость ради прохождения теста

Один из рисков при обновлении — взять демонстрационный код из анонса, не заметив его статус. До исправления проверьте, доступен ли нужный API в той поставке, которую получает пользователь. Успех отдельной экспериментальной сборки не подтверждает готовность стабильного приложения.

Другие возможности релиза, включая variable fonts и жизненный цикл окна, рассматривайте по их назначению. Они не доказывают исправность пути событий и не являются причиной одновременно переписать оформление и навигацию. Ограниченный объём помогает понять найденное расхождение.

Как принять обновление интерфейса

1. Опишите критические действия пользователя и ожидаемые переходы.
2. Выделите библиотеки с обращением к внутренним механизмам событий.
3. Проверьте вложенные элементы, direct events и нужные жесты на согласованной поставке.
4. Разберите расхождения по минимальным воспроизводимым сценариям.
5. Сверьте статус API, используемых в исправлении.
6. Сохраните версии, результат и непроверенные устройства отдельно.

Для мобильной разработки такая матрица задаёт предмет приёмки. В доработке приложения сохраняйте последовательность действий, а для веб-приложений отдельно описывайте их собственные интерфейсные контракты. Общая модель событий помогает обсуждать поведение, но не делает проверки разных платформ взаимозаменяемыми.