You Might Not Need React Query

Возможно вам не нужен React Query. Статья является ответом на горячие споры в интернете о том, что серверный компоненты react делают React Query ненужным.

Не смотря на то, что React предоставляет удобный способ делать асинхронную загрузку данных прямо в серверном компоненте, React все еще остается очень гибким решением, которое не форсит какой-то один способ как делать что-то "правильно". Для определенных приложений (например, которые сразу пишутся по определенной архитектуре, в которой серверные компоненты хорошо встроены), React Query действительно может быть не нужен.

Однако для многих приложений придется использовать гибридный подход (и серверный компоненты и React Query) из-за ограничений архитектуры, плавных миграций или каких-то плюшек React Query. Либо же останутся проекты, которые не будут использовать серверные компоненты.

https://tkdodo.eu/blog/you-might-not-need-react-query

#development #react #reactQuery #reactServerComponents

Speeding up the dbt™ docs by 20x with React Server Components | Dagster Blog

Статья про ускорение сайта в 20 раз с применением серверных компонентов React.

Начальная позиция: сайт с документацией на angular.js, у которого LCP - 47 секунд. Конечная позиция: сайт с React Server components, у которого LCP 0.7 секунд. В принципе, конечно, ничего удивительного - 47 секунд LCP это значит что что-то было сделано феноменально плохо и перевод на серверный рендеринг естественно может ускорить сайт в любое количество раз. Однако статья все равно интересная т.к. рассказано о проблемах, с которыми столкнулась команда разработки

Из интересного:
1. Вместо бандлинга JSON в статику, отдают JSON через API
2. Сделали фикс бага в Next.js

https://dagster.io/blog/dbt-docs-on-react

#development #react #reactServerComponents

We migrated 50,000 lines of code to React Server Components

Статья про опыт переезда приложения на 50к строчек на React Server Components.

Автор рассказывает, как проводить миграцию инкрементально, какие проблемы есть у серверных компонентов и как их обойти.

Для чего подходят RSC:

1. Позволяют четко определить, где код будет запускаться. Что позволяет, например, оптимизировать загрузку статики
2. Позволяют загружать данные прямо в компоненте, что в целом упрощает флоу данных в коде

Какие проблемы есть у RSC:

1. CSS-in-JS не работает в RSC
2. React Context работает только в клиентских компонентах. Это достаточно жесткое ограничение, мешающее мигрировать существующий код или использовать внешние решения (например, вы используете либку, которая как API предоставляет контекст - значит вы не сможете воспользоваться ей в RSC)
3. Сложность (Complexity). React и так не простой, а с RSC разработчик теперь должен будет всегда помнить, что есть 2 вида компонентов и они работают по-разному и к ним нужны разные подходы

Также автор описывает алгоритм для миграции на RSC. Миграция идет сверху-вниз, т.е. от App до конечных компонентов. Наша цель - ставить директиву use client при проходе сверху вниз по дереву компонентов, определяя, что мы можем унести на сервер, а что не можем. Также автор описывает паттерны комбинации двух видов компонентов.

Рекомендую к прочтению React разработчикам

https://www.mux.com/blog/what-are-react-server-components

#development #react #reactServerComponents #recommended

Storybook for React Server Components

Storybook добавили экспериментальную поддержку React Server Components в Storybook 8.0 alpha. Так как серверные компоненты могут полагаться на то, что доступен весь API node.js, то у команды Storybook было 2 стула:
- поменять архитектуру Storybook, чтобы там появилась серверная часть
- Сделать все на стороне клиента, но придумать как обойти ограничения

Естественно, выбрали сесть на второй. Реализация сделана на основе Next.js версии React. И если с рендером все более менее понятно, то непонятно что делать с зависимостями. Например, компонент ходит в БД. Для этого Storybook предлагает выделять такие операции в отдельные модули, которые затем в истории можно замокировать черезstorybook-addom-module-mock или через другие решения

export const Success {
  args: { id: 1 },
  parameters: {
    moduleMock: {
      mock: () => {
        const mock = createMock(db, 'findById');
        mock.mockReturnValue(Promise.resolve({
          name: 'Beyonce',
          img: 'https://blackhistorywall.files.wordpress.com/2010/02/picture-device-independent-bitmap-119.jpg',
          tel: '+123 456 789',
          email: 'b@beyonce.com'
        }))
        return [mock];
      },
    },
  },
}

https://storybook.js.org/blog/storybook-react-server-components/

#development #javascript #storybook #reactServerComponents

Delicious Donut Components

Статья про композицию клиентских и серверных компонентов в React. Статья, в основном, фокусируется вокруг паттерна Donut Components (Пончиковые Компоненты). Серверные компоненты не могут импортироваться и использоваться в клиентских компонентах. Но можно прокидывать серверный компонент как child для клиентского. Это и есть паттерн пончика (извините, не могу удержаться от использования этого словосочетания на русском языке)

Статья содержит наглядные интерактивные примеры паттернов композиции компонентов, объясняет про проблемы передачи данных между серверными и клиентскими компонентами. Отдельно отмечу, что некоторые паттерны достаточно интересные. Например, прокидывание серверного экшна (могу ошибиться т.к. не до конца разбираюсь в терминологии Nextjs) в рендер-проп клиентского компонента.

https://frontendatscale.com/blog/donut-components/

#development #react #reactServerComponents

Why React Server Components Are Breaking Builds to Win Tomorrow

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

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

https://www.builder.io/blog/why-react-server-components

#development #javascript #react #reactServerComponents #recommended

React 19 lets you write impossible components

Статья про преимущества от использования новых фичей в React19. Как я понял, команда Mux активно использует фичи, связанные с серверными компонентами React, и очень довольна ими. Основные преимущества связаны с улучшением DX и уменьшением бандла приложения.

Использование серверных компонентов позволило уменьшить на 20-90% размер бандлов разных страниц. В основном, за счет того, что у Mux очень статичные страницы - документация и маркетинговые лендинги. Большую часть контента достаточно отрендерить только на сервере.

Гораздо интереснее история с серверными компонентами.

Один из основных плюсов с точки зрения DX, это то, что теперь не нужно создавать API-ендпоинты. Т.е. если компоненту нужны данные - он просто их запрашивает (например из базы), а фреймворк уже сам разберется, как сделать так, чтобы данные попали в браузер. Плюсом к этом идет нативная интеграция с Suspense, которая позволяет описать загрузку данных и не думать о том, что это негативно повлияет на пользовательский опыт.

Также команда Mux очень сильно полюбила серверные экшны и, опять же, за очень хороший DX - достаточно просто писать React-код и не думать о бойлерплейте. Например, есть маркетинговый лендинг с формой. Раньше, чтобы отправить заполненную форму, необходимо было создать API-ендпоинт, который бы принимал данные, а к этому API-ендпоинту необходимо было бы обращаться POST-запросом. Теперь же достаточно сделать серверный form action, а все сетевое взаимодействие заберет на себя фреймворк.

Действительно, с точки зрения DX, звучит очень круто. С другой стороны, это уже было в нулевых во всяких .Net MVC и это выглядит как небольшая магия.

Статья интересная, рекомендую к прочтению. Она неплохо так вдохновляет попробовать RSC даже такого скептика, как я.

https://www.mux.com/blog/react-19-server-components-and-actions

#development #javascript #react #reactServerComponents

Impossible Components

Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.

Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.

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

Строго рекомендую к прочтению

https://overreacted.io/impossible-components/

#development #javascript #react #reactServerComponents #danAbramov

What Does "use client" Do?

Пост в блоге Дэна Абрамова про серверные компоненты. Точнее пост про концепцию use client и use server, но по факту это про концепцию серверных компонентов.

В посте Дэн рассказывает, какая идея вложена в use client и use server. Когда мы делаем приложение, которое имеет и бэк и фронт, то для взаимодействия между фронтом и беком необходимо использовать особые способы коммуникации, вместо простого вызова функции. Чтобы вызвать бэк с фронта - надо делать сетевой запрос, а чтобы бэку что-то сообщить для фронта - надо как-то передавать данные для рендера.

Намного круче было бы использовать функции напрямую. Именно это и позволяют делать директивы use client и use server. Они как бы обозначают для сборщика, что экспорты этого файла надо адаптировать для вызова в "другом" мире.

Статья интересная, с хорошими примерами кода и хорошими объяснениями.


https://overreacted.io/what-does-use-client-do/

#development #javascript #react #reactServerComponents #danAbramov

You can serialize a promise in React

Еще одна статья, связанная с серверными компонентами. Но на этот раз идеи из нее можно использовать и вне React. Легко передать данные между беком и фронтом, если они легко конвертируются в JSON. Но как передать Promise? Ведь он не сериализуется

const promise = new Promise((resolve) => {
  setTimeout(() => resolve("Hello!"), 1_000);
});

const json = JSON.stringify(promise); // => '{}'

Чтобы сериализовать Promise нужно придумать какой-то свой протокол передачи его состояния и значения.

Один из способов - использовать Stream. При создании промиса отправляем в поток сообщение promise:create, при резолве промиса отправляем в поток текстовое сообщение, содержащее результат промиса

function serializePromise(promise) {
  const stream = new ReadableStream({
    async start(controller) {
      controller.enqueue("promise:create");

      const value = await promise;
      controller.enqueue(`promise:resolve:${value}`);
      controller.close();
    },
  });

  return stream;
}

Теперь надо сделать функцию, которая будет считывать этот поток и преобразовывать его в Promise на принимающей стороне

function deserializePromise(stream) {
  const reader = stream.getReader();

  let promise;
  let resolver;
  let unlock;

  let didUnlock = false;
  const lockUntilReady = new Promise((resolve) => {
    unlock = (arg) => {
      resolve({ promise: arg });
      didUnlock = true;
    };
  });

  async function readStream() {
    const { done, value } = await reader.read();

    if (done) {
      if (!didUnlock) {
        unlock();
      }
      return;
    }

    if (value === "promise:create") {
      promise = new Promise((resolve) => {
        resolver = resolve;
      });
      unlock(promise);
    } else if (value.startsWith("promise:resolve:")) {
      const result = value.split(":")[2];
      resolver(result);
    }

    readStream();
  }

  readStream();

  return lockUntilReady;
}

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

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


https://twofoldframework.com/blog/you-can-serialize-a-promise-in-react

#development #javascript #react #reactServerComponents #Promise

How to test React Server Component

Удивительно, столько движа вокруг серверных компонентов React. Но при этом нет никаких официальных туториалов как тестировать эти компоненты (по крайней мере я не видел таких туториалов и в статье говорят что их нет)

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


https://www.nico.fyi/blog/how-to-test-react-server-component

#development #javascript #react #reactServerComponents #testing