В техническом блоге Facebook была опубликована статья про подходы улучшения доступности, которые были использованы на новом сайте социальной сети, — "Making Facebook.com accessible to as many people as possible".

Основные пункты статьи. Чтобы не допускать распространённых ошибок доступности, используют eslint-плагин eslint-plugin-jsx-a11y. Для работы с фокусом используют специальные компоненты, которые также упрощают добавление навигации с клавиатуры. Для улучшения читабельности текста на этапе сборки конвертируют размер шрифта в rem. Иерархия заголовков в документе поддерживается автоматически с помощью специального API. Улучшили работу горячих клавиш с помощью API на базе React контекста. Для валидации разметки используют самописный инструмент, который подсвечивает красным оверлеем все элементы с проблемами a11y.

Хорошая статья. Рекомендую почитать всем, кто интересуется темой доступности.

#a11y #react #facebook

https://engineering.fb.com/web/facebook-com-accessibility/

Джереми Вагнер проанализировал производительность React и Preact и альтернативный подход использования библиотек с серверным рендерингом в разных окружениях — "radEventListener: a Tale of Client-side Framework Performance".

В статье исследуется время инициализации JS-кода, время гидрации и время открытия меню на тестовом сайте. В исследование был добавлен подход с серверным рендерингом и управлением обработкой событий с помощью addEventListener. Эксперименты проводились на разных устройствах: ноутбук 2013-го года, iPhone SE, iPhone SE (2020), Nokia 2.

Из интересного. Инициализация JS-кода на ноутбуке с i5 (Ivy Bridge) было медленнее чем на iPhone SE первого поколения. Также тесты на iPhone SE показывают преимущество над бюджетным Nokia 2, который вышел на два года позже. Во всех тестах на гидрацию преимущество у Preact. Подход с серверным рендерингом и управлением обработкой событий с помощью addEventListener ожидаемо выиграл во всех тестах.

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

#performance #react

https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance/

Себастиен Лорбер из Facebook написал статью про то, какие преимущества даёт пропозал Records & Tuples для React-приложений — "Records & Tuples for React".

Предложение Records & Tuples добавляет новые иммутабельные структуры данных в JS. Записи и кортежи особенно полезны для React, так как много проблем с производительностью и поведением библиотеки связано с устойчивостью ссылок на объекты (object identities). Некорректное использование литералов объектов в пропсах может привести не только к проблемам с производительностью, но и в некоторых случаях к бесконечным загрузкам данных.

В статье разбирается очень много случаев того, как новый пропозал позволяет упростить React-код. Есть немного размышлений по поводу того, как кортежи и записи могут быть использованы вместе с TypeScript.

Очень полезная статья. Рекомендую почитать всем, кто использует React и кто интересуется темой производительности.

#react #proposal #performance

https://sebastienlorber.com/records-and-tuples-for-react

Натан Себастиан собрал подборку советов для создания расширяемых React-приложений — "6 Tips and Best Practices for a Scalable React Project".

В статье есть советы по разделению локального и глобального состояния. Есть раздел, затрагивающий тестирование. Там говорится о том, что тестирование следует добавлять с самого начала жизни проекта, так как ручная проверка усложняется с развитием проекта. Есть рекомендация внедрять нужные инструменты только тогда, когда они действительно нужны. Большое количество библиотек и инструментов увеличивают сложность поддержки проекта.

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

#react

https://blog.bitsrc.io/best-practices-and-tips-for-a-scalable-react-application-db708ae49227

Примерно месяц назад вышел первый релиз кандидат React 17, в котором нет новых значимых фич. Но в новой версии появится поддержка нового типа преобразования JSX (JSX transform), благодаря которому больше не нужно постоянно импортировать React. Луна Руан в блоге React написала про это статью — "Introducing the New JSX Transform".

Babel и TypeScript преобразуют JSX в вызовы функций React.createElement, поэтому нужно импортировать React в текущий скоуп. Это неинтутивно. Также использование React.createElement влечёт за собой дополнительные накладные расходы. Для решения этих проблем был разработан новый тип преобразований JSX.

React 17 RC включает в себя две новые функции jsx и jsxs, которые должны использоваться только транспиляторами. Транспиляторы импортируют их в код компонентов автоматически при преобразовании JSX.

Поддержка нового преобразования уже есть в Babel 7.9 и TypeScript v4.1 beta. Для его включения в babel 7.9 нужно указать опцию {"runtime": "automatic"}. В babel 8 он будет включаться по умолчанию.

Новый JSX transform будет бэкпортирован в React 16.x, React 15.x и React 0.14.x.

#react #jsframeworks

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

Марк Эриксон рассказал о том, в каких случаях Redux не самое лучшее решение — "When (and when not) to reach for Redux".

Redux появился в 2015 году и был очень популярен несколько лет, но сейчас это не самый лучший инструмент. Вопрос кэширования данных взяли на себя библиотеки swr, React Query, Apollo. Проблемы с явной передачей пропсов от корня к дочерним компонентам (props drilling) решается в React из коробки, начиная с версии 16.3, благодаря стабилизировавшемуся Context API. Также Марк говорит о том, что Redux неоптимален для работы со стейтом, но не приводит альтернатив, поэтому позволю себе наглость добавить их от себя: Mobx, Reatom, Effector.

Несмотря на свой статус основного мейнтейнера Redux Марк довольно трезво оценивает текущую ситуацию с Redux и говорит о том, что серебряной пули нет, инструменты нужно выбирать в зависимости от ситуации. В некоторых случаях подходящим решением может быть Redux.

#react #statemanagement

https://changelog.com/posts/when-and-when-not-to-reach-for-redux

Доминик Тобиас написал статью о подходах к улучшению производительности CSS-in-JS — "How to increase CSS-in-JS performance by 175x".

Заголовок у статьи, конечно, кликбейтный, но написано там всё по делу. В прошлом году на perfplanet было опубликовано исследование с печальными результатами — популярные CSS-in-JS библиотеки, которые в рантайме внедряют на страницу стили (Styled Components, Emotion), могут очень негативно влиять на производительность сложных страниц.

Для улучшения производительности Доминик предлагает использовать CSS-in-JS библиотеки, которые могут извлекать стили из JS на этапе компиляции, также предлагает использовать CSS-переменные для темизации и рекомендует (по возможности) отказаться от динамики в стилях.

Полезная статья. Рекомендую почитать всем, кто использует Styled Components, Emotion и другие подобные библиотеки.

#react #cssinjs #performance

https://dominictobias.medium.com/how-to-increase-css-in-js-performance-by-175x-f30ddeac6bce

Сегодня разработчики React представили новую фичу библиотеки — серверные компоненты.

Серверный компонент — это неинтерактивный React-компонент с расширением .server.js. Он полностью работает на стороне сервера, что позволяет внутри кода компонента сделать запрос к базе данных или прочитать файл с файловой системы сервера. Благодаря комбинированию клиентских (обычных) и серверных компонентов можно улучшить производительности приложения и улучшить UX. Ещё одна важная особенность серверных компонентов — их код не попадает в клиентский бандл приложения. Они не предназначены для замены обычных компонентов — решение об их использовании остаётся на усмотрение разработчиков приложений.

Серверные компоненты — это экспериментальная фича, которая находится в стадии активной разработки, но её уже можно пощупать и поделиться своим фидбэком в RFC.

#jsframeworks #react #experimental

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

Марк Эриксон — майнтейнер Redux — написал статью с подробным объяснением, почему Context в React не может заменить стейт-менеджеры — "Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)".

React Context — это механизм, который упрощает передачу значений от родительского компонента дочерним компонентам вне зависимости от уровня вложенности. Context используют вместе с хуком useReducer в качестве альтернативы стейт-менеджерам. Но в отличие от традиционных стейт-менеджеров такой подход не позволяет эффективно решить все вопросы управления данными приложения. Context может подойти для управления состоянием маленького приложения, но его сложно использовать в большом приложении, над которым работает команда разработчиков. Также современные стейт-менеджеры берут на себя вопросы с лишними ререндерами компонентов.

Хорошая статья. Рекомендую почитать, если работаете с React.

#react #statemanagement

https://blog.isquaredsoftware.com/2021/01/context-redux-differences/

Дейв Седдиа написал статью про современную экосистему React — "State of the React Ecosystem in 2021".

Этот обзор был вдохновлён вопросом на reddit, где участник задал вопрос про актуальность подходов, которые были популярны в 2016 году. За пять лет в мире React произошло много изменений. Появились хуки, стабилизировался Context API, появилась экспериментальная поддержка Suspense и Server Components. Redux остаётся популярным решением для работы с состоянием, но очень сильно сдаёт свои позиции. Для загрузки данных набирают популярность библиотеки react-query и swr. Для описания сложной логики используют библиотеку XState.

Рекомендую почитать статью, если хотите познакомиться с современными инструментами и библиотеками экосистемы React.

#react

https://daveceddia.com/react-ecosystem-overview/

Дэн Абрамов рассказал о простом, но неочевидном подходе для уменьшения лишних ререндеров React-компонентов — "Before You memo()".

Перед тем как использовать memo и useMemo для предотвращения ререндеров, имеет смысл попробовать разбить компонент на stateful- и stateless-части (поднять вверх стейт). Также можно передать stateless-компонент через пропс в stateful-компонент (поднять вверх контент). При ререндере stateful-компонента переданный через пропс компонент не будет ререндериться. Использование такого подхода откроет в будущем новые возможности для оптимизаций, например, для предотвращения ререндеринга серверных компонентов.

Полезная статья. Очень рекомендую почитать всем, кто работает с React.

#react #performance

https://overreacted.io/before-you-memo/

Алекс Котлярский из Facebook рассказал про историю развития React API — "React API evolution".

Прошло уже почти восемь лет с момента релиза первой публичной версии React. За этот период подход к написанию компонентов поменялся несколько раз. Сначала компоненты создавались с помощью React.createClass причём в версии 0.3.0 нужно было самостоятельно биндить методы, использующие this, с помощью React.autoBind. В 0.4.0 автобиндинг был включён по умолчанию. Затем официальным механизмом для создания компонентов стали ECMAScript классы и функциональные компоненты. По ходу дела разработчики стали использовать High Order Components (HOC) для композиции поведения компонентов. HOC не были идеальным решением для работы с поведением, поэтому в 2019 году ребята из команды React представили хуки.

Интересная статья. Рекомендую почитать в первую очередь всем, кто недавно начал работать с React.

#react #history

https://frantic.im/react-api-evolution

Диего Хаз — автор библиотеки компонентов Reakit — рассказал о принципе разработки базовых компонентов — "Introducing the Single Element Pattern".

При разработке приложений Диего выделяет понятие "базовый компонент" — фундаментальную часть приложения, следующую определённым правилам, благодаря которым кодовая база проекта легко масштабируется и не усложняется в поддержке (принцип Singel). Правила:

— Компонент рендерит только один элемент (в редких случаях несколько)
— Компонент не должен ломать приложение при возникновении исключений
— Рендерит все HTML-атрибуты, переданные как пропсы
— Мёржит стили, передаваемые как пропсы
— Добавляет все обработчики событий, передаваемые как пропсы

В первую очередь советы из статьи полезны при разработке библиотеки компонентов, но их можно использовать при разработке обычных компонентов. Также эти принципы можно использовать не только с React, но и с любым другим компонентным фреймворком.

#react #vue #angular #svelte

https://www.freecodecamp.org/news/introducing-the-single-element-pattern-dfbd2c295c5d/

Команда React поделилась планами разработки следующей мажорной версии библиотеки — "The Plan for React 18".

В React 18 будет добавлен автоматический батчинг обновлений стейта компонентов, новые API (например, startTransition) и стриминговый серверный рендерер с поддержкой React.lazy. Изменится работа с конкурентным режимом. Он будет включаться автоматически при использовании новых фич, которые требуют этот режим. Такая стратегия упростит миграцию приложений на React 18.

С этой версии команда React начинает больше работать с сообществом. Для этого была организована специальная рабочая группа из экспертов, разработчиков, авторов библиотек и образовательных программ.

Также была опубликована альфа-версия React 18. Команда React призывает авторов библиотек поэкспериментировать с ней и поделиться фидбеком.

#react

https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html

Джек Франклин — участвует в разработке Chrome DevTools — реализовал на React и Svelte небольшое приложение для трекинга времени с сохранением данных в Firebase и рассказал о своём опыте в статье "Comparing Svelte and React".

В статье сравнивается простота интеграции с аутентификацией Firebase, работа с веб-воркерами, условный рендеринг, реактивность, композиция компонентов, стилизация. По результатам сравнения победил Svelte, так как в нём проще работать с сайд-эффектами. Кодовая база Svelte в целом также оказалась проще. Из коробки идут средства для работы со стилями. Как бы то ни было Джек пишет, что ему нравится работать и с React, и со Svelte.

Немного субъективная статья, но всё равно интересная. Рекомендую заглянуть.

#jsframeworks #react #svelte

https://www.jackfranklin.co.uk/blog/comparing-svelte-and-react-javascript/

Релиз Next.js 12

Три дня назад была представлена новая мажорная версия Next.js — "Next.js 12".

Next.js 12 по умолчанию использует swc для транспиляции JavaScript- и TypeScript-файлов. Swc — это очень быстрый аналог Babel, написанный на Rust. Благодаря ему время production-сборки стало в пять раз меньше. В три раза уменьшилось время обновления страницы при локальной разработке.

Была добавлена поддержка миддлвар для гибкой модификации HTTP-ответа. В зависимости от входящего запроса можно изменить ответ, добавить новые HTTP-заголовки, сделать редирект и т.п. Миддлвары могут работать на edge-серверах Vercel, улучшая отзывчивость приложения.

Была проведена работа для подготовки к переходу на React 18. В экспериментальном режиме доступны серверные компоненты и новый поточный серверный рендерер с поддержкой Suspense.

Теперь по умолчанию в Next.js используется ESM с поддержкой импорта CommonJS-модулей. Добавлена экспериментальная поддержка импорта модулей по URL.

В компоненте <Image> появилась поддержка формата изображений AVIF. Также компонент автоматически определяет основное изображение страницы, которому нужно передать пропс priority для улучшения метрики LCP.

В рамках нового релиза была опубликована библиотека @vercel/nft (Node File Tracer). Она используются для генерации облегчённых standalone-сборок Next.js-приложений для serverless-окружений и контейнеризации.

В Next.js 12 поисковым ботам будут отдаваться полностью отрендеренные страницы, использующие Incremental Static Regeneration. Обычные пользователи будут видеть интерфейс загрузки страницы.

В ломающих изменениях отказ от Webpack 4, деприкейт опции target, использование <span> вместо <div> в next/image, увеличение минимальной поддерживаемой версии Node.js с 12.0.0 до 12.22.0

#release #jsframeworks #react

https://nextjs.org/blog/next-12

Открытие исходного кода фреймворка Remix

Райан Флоуренс и Майкл Джексон — авторы React Router и Reach UI — полгода назад представили новый проект Remix — фреймворк для разработки приложений с серверным рендерингом на базе React. Всё это время он распространялся платно. После привлечения трёх миллионов долларов в качестве инвестиций они открыли исходный код проекта под лицензией MIT.

По сути Remix — это конкурент Next.js. Райан и Майкл в презентации дипломатично ушли от сравнения с Next.js. Говорят, что друзья с создателем Next.js и хотят жить в мире, но по лендингу проекта видно, что Remix претендует на свой кусок пирога. Более того они поделились планами по монентизации проекта. Они планируют создавать платные сервисы вокруг фреймворка, как это сделал Vercel с Next.js.

Основные отличия от Next.js. В Remix серверный код можно размещать внутри React-компонентов. Кастомный транспилятор удаляет этот код при создании бандла для клиента, и оставляет в серверной сборке. То есть это что-то похожее на серверные компоненты из React 18. Ещё очень большой упор в презентации был сделан на эргономику работы с формами — выглядит всё, действительно, очень удобно и привычно. На сайте проекта также говорится про улучшение флоу загрузки приложения, но над этой фичей работает core-команда React, а не Remix, и она появится в Next.js (или уже появилась?).

В общем, меня лично проект не сильно впечатлил. Однако за проектом стоят известные разработчики в React-сообществе и есть инвестиции, поэтому проект будет развиваться. В конце концов здоровая конкуренция это всегда хорошо.

#announcement #react #jsframeworks

https://remix.run/ (сайт проекта)
https://www.youtube.com/watch?v=wsJaUjd1rUo (презентация Remix)

Адаптация Relay для большой кодовой базы

На прошедшем React Conf 2021 был представлен новый компилятор Relay для оптимизации GraphQL-запросов — "Introducing the new Relay compiler".

Relay — это фреймворк для работы с GraphQL в React-приложениях. При использовании Relay компоненты декларативно описывают необходимые им данные с помощью GraphQL-фрагментов. Компилятор Relay на этапе сборки приложения обходит компоненты и подготавливает оптимизированный GraphQL-запрос на базе этих фрагментов.

Скорость компилятора с ростом кодовой базы Facebook постепенно ухудшалась, поэтому его переписали c JavaScript на Rust. Скорость работы компилятора улучшилась в пять-семь раз. Кроме улучшения производительности новый компилятор подготовил платформу для дальнейшего развития Relay. Например, благодаря ему в Relay появилась поддержка новой директивы @required для упрощения работы с данными. Также этот компилятор лежит в основе расширения для VSCode для поддержки автодополнения имён полей в GraphQL-фрагментах. Расширение на данный момент недоступно для внешних пользователей, так как над ним ещё ведётся работа.

#react #graphql #rust

https://relay.dev/blog/2021/12/08/introducing-the-new-relay-compiler/

Тюнинг производительности Next.js-приложений

Бен Шварц поделился рекомендациями по улучшению производительности Next.js-приложений — "Next.js Performance: Making a Fast Framework Even Faster".

Для загрузки сторонних скриптов рекомендуется использовать компонент next/script со стратегией lazyOnload, чтобы код начинал грузиться тогда, когда завершается загрузка основного кода приложения. Для вставки изображений рекомендуется использовать компонент next/image. Он берёт на себя конвертацию изображений, генерацию плейсхолдеров и поддержку ленивой загрузки. Для уменьшения размера основного бандла приложения можно использовать динамическую загрузку кода с помощью import(). Для динамической загрузки React-компонентов — хелпер next/dynamic.

Полезная статья. Рекомендую почитать, если работаете с Next.js.

#jsframeworks #performance #react

https://calibreapp.com/blog/nextjs-performance

React server components под капотом

Чан Ву рассказал про внутреннее устройство React server components (RSC) — "How React server components work: an in-depth guide".

Серверные компоненты — это экспериментальный тип React-компонентов, которые не попадают в клиентский бандл и позволяют бесшовно выносить на сервер часть логики приложения. Результатом выполнения серверных компонентов является представление дерева React-компонентов в формате, подходящем для стриминга. В статье подробно разбирается принцип работы RSC, их ограничения и внутреннее устройство.

Статья хорошая. Рекомендую почитать всем, кто хочет разобраться в устройстве серверных компонентов.

#react #internals

https://blog.plasmic.app/posts/how-react-server-components-work/