Автор пишет о проблемах React.Context и возможных вариантах решения сейчас и в будущем. Основное назначение контекста в Реакте – управление состоянием, которое хорошо работает. Частое использование контекстов приводит к provider hell, который можно решить при помощи композиции:
Однако композиция не решает проблем с динамическим состоянием, которое может ререндерить всё поддерево.
Следующим шагом к оптимизации является использование useContextSelector из одноименного пакета и useSyncExternalStore из самого Реакта. Хук useSyncExternalStore является очень полезным, если необходимо синхронизировать внешнее состояние, но он всё ещё имеет проблемы с параллельным рендерингом. Ну а для решения проблемы с параллельным рендерингом в React Labs анонсировали улучшение хука use(store), которое, возможно, позволит перейти к варианту использования внешних сторов, а не контекстов.
Прошедшее заседание TC39 по ECMAScript принесло много новостей – рассмотрели 9 предложений, и целых 4 предложения перешли в Stage 4! Предложения, получившие Stage 4 теперь полностью готовы для включения в стандарт языка, и, скорее всего, появятся в грядущем стандарте ECMAScript.
На прошедшем заседании обновили статусы как и существующих предложений, так и рассмотрели новые: новые методы для итераторов, новый класс для работы с числами – Decimal, псевдослучайный генератор чисел с сидом, новый метод для работы с числами – Math.clamp и т.д.
В марте был анонсирован порт TypeScript’а на Go, и уже набрал ускорение компиляции до 10 раз. Теперь же сам порт стал более стабильным – теперь его можно попробовать в VS Code в реальных проектах в эксперементальном режиме.
TypeScript Native Preview включает в себя команду tsgo, которая является будущей заменой tsc. Теперь TypeScript на Go имеет большую часть проверок типов, а также поддержку JSX и JavaScript вместе с JSDoc. Авторы отмечают, что некоторые фичи пришлось переписать с нуля, и так некоторые конструкции на JavaScript и JSDoc потребуют использования более современного стиля написания кода.
К концу года нам обещают расширить нативный компилятор на TypeScript флагом --build и улучшенной поддержкой для редакторов.
Команда React Router анонсировала поддержку React Server Components. Подход, который является наиболее убедительным, выглядит следующим образом: React Router использует loader для понимания того, какой компонент необходимо отобразить на основе данных. Такой подход обеспечивает уменьшение клиентского кода, т.к. на клиент попадает только нужный компонент со своей логикой. Использование RSC внутри loader’ов позволяет получить преимущества серверных компонентов – не нужно полностью перерабатывать компоненты в остальных местах.
React Router, как и большинство крупных современных инструментов, использует жесткие именования компонентов для понимания того, какой код является серверным, а какой – клиентским. Для обработки серверных компонентов роутер будет обращать внимание на компонент с названием ServerComponent и такой компонент будет бандлиться отдельно от клиентских компонентов, за что будут отвечать сами бандлеры. Серверные компоненты для роутинга смогут также определять лоадеры и экшены, как и клиентские компоненты. Ну и про серверные функции1 не забыли, они тоже будут работать. Интересной фичей будут миддлвары – их можно будет очень легко писать внутри роутов.
Проблемы кэширования и батчинга не обойдут стороной RSC, и автор предлагает обратить внимание на DataLoader от команды GraphQL, который позволяет уменьшить количество одинаковых запросов.
Сноски
Пример того, как может быть реализовано разделение между клиентскими компонентами и серверными функциями в статье Дэна Абрамова – Функциональный HTML. ↩