Марк Эриксон рассказал о том, в каких случаях 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/