Оптимизация JavaScript для развлечения и ради прибыли

Обзор распространенных методов оптимизации JavaScript, которые могут быть полезны и для React приложений. Для каждого метода автор приводит бенчмарк для сравнения скорости выполнения. Кратко, о чем пишет автор:

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

- Избегайте сравнение строк. Для сравнения строк используется функция strcmp(a, b), сложность которой O(n). Если создаете enum, то лучше не использовать строки:

// Плохо
enum Position {
  TOP    = 'TOP',
  BOTTOM = 'BOTTOM',
}

// Лучше
enum Position {
  TOP,    // = 0
  BOTTOM, // = 1
}

- Избегайте разных форм. Используйте одинаковую форму объекта в одном массиве.

- Избегайте методов объекта/массива. Писать в функциональном стиле через цепочку методов дороже чем в императивном. Пример:

const result =
  [1.5, 3.5, 5.0]
    .map(n => Math.round(n))
    .filter(n => n % 2 === 0)
    .reduce((a, n) => a + n, 0)

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

- Используйте правильные структуры данных. Неправильно подобранная структура данных может ухудшить оптимизацию. Надо знать про существующие Map и Set, а также узнать о связанных списках, приоритетной очереди и деревьях. Например, использование Set.has гораздо быстрее чем Array.includes.

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

https://romgrk.com/posts/optimizing-javanoscript

Новый хук useActionState

В React появится новый хук useActionState, который заменит существующий ReactDOM хук useFormState. Этот хук призван исправить некоторую путаницу и ограничения хука useFormState.

Хук useFormState импортировался из ReactDOM и был предназначен только для отслеживания стейта action у формы. Однако не обязательно было использовать его для формы, его можно было использовать для отслеживания любой асинхронной функции.

Команда React переименовала хук useFormState в useActionState, добавила стейт pending в возвращаемый результат и переместила хук в пакет react.

Пример использования хука:

import { useActionState, useRef } from "react";

function Form({ someAction }) {
  const ref = useRef(null);
  const [state, action, isPending] = useActionState(someAction);

  async function handleSubmit() {
    await action({ email: ref.current.value });
  }

  return (
    <div>
      <input ref={ref} type="email" name="email" disabled={isPending} />
      <button onClick={handleSubmit} disabled={isPending}>
        Submit
      </button>
      {state.errorMessage && <p>{state.errorMessage}</p>}
    </div>
  );
}

Под капотом вызов action вызывает под собой startTransition, код обработчика можно заменить на такой:

const [state, setState] = useState(null);
const [isPending, setIsPending] = useTransition();

function handleSubmit() {
  startTransition(async () => {
 const response = await someAction({ email: ref.current.value });
 setState(response);
  });
}

https://github.com/facebook/react/pull/28491

Нестабильные тесты в React: обнаружение, предотвращение и инструменты

Нестабильные тесты в React – это тесты, которые в большинстве случаев проходят успешно, но иногда ломаются, и все это без изменений в коде или тесте — просто без причины.

Вот некоторые причины, по которым тесты могут быть нестабильными:

- Внешние зависимости. Например, компонент получает данные по API и отображает ответ. Если в API вернет не то, что ожидал компонент, то тест сломается.

- Проблемы со временем. Например, если тесту надо проверять UI элемент до или после анимации или CSS перехода, то такой тест нестабильный.

- Асинхронные операции. К этим операциям относится пользовательский ввод, обновление UI, получение данных из API. Если тест не ждет завершения операции перед утверждением, то такой тест может сломаться.

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

Для предотвращения нестабильных тестов, используйте следующие правила:

- Хорошо структурируйте тесты. Они должны быть независимыми, иметь осмысленное название, должны создавать собственный экземпляр компонента при запуске.

- Используйте моки. Заменяйте внешние зависимости на контролируемые моки. Это придает тесту более предсказуемое поведение.

- Используйте beforeEach и afterEach, чтобы каждый тест начинался с чистого листа.

- Если есть возможность проводить тестирование при помощи снимков, то используйте это.

test("Modal opens", async () => {
  render(<Modal />);
  fireEvent.click(screen.getByText("Open Modal"));

  await waitFor(() => expect(screen.getByTestId("modal")).toBeInTheDocument());
});

https://semaphoreci.com/blog/flaky-react

Более быстрый React.memo()

В React.memo используется общая функция shallowCompare, которую можно значительно оптимизировать с помощью специальной функции сравнения, которая предполагает, что объекты для сравнения – это React пропсы.

Автор блога romgrk сделал две версии функции проверки пропсов для React.memo(): безопасную и небезопасную. Небезопасная быстрее общей shallowCompare в два раза, вот ее код:

function fastCompareUnsafe(a, b) {
    var aLength = 0;
    var bLength = 0;
    for (var key in a) {
        aLength += 1;
        if (!Object.is(a[key], b[key])) {
            return false;
        }
    }
    for (var _ in b) {
        bLength += 1;
    }
    return aLength === bLength;
}

При сравнении объектов { a: 1, b: undefined }, { a: 1, c: undefined } эта функция вернет true, т.е. скажет что они равны. Для общего сравнения двух объектов данная функция не подходит, но для сравнения пропсов React такая функция будет работать.

https://romgrk.com/posts/react-fast-memo/

Создаем прогресс загрузки страницы с помощью Transition API

В Build UI рассказали, как можно создать прогресс загрузки страницы с помощью Transition API. В результате получился хук useProgress и компоненты прогресса с Framer Motion:

const { start, done, reset, state, value } = useProgress();

Чтобы показать прогресс загрузки страницы в Next.js, то необходимо использовать Transition API. Пример:

const router = useRouter();
const { start, done } = useProgress();

return (
  <Link
    onClick={(e) => {
      e.preventDefault(); 
      start();

      startTransition(() => { 
        router.push(href); 
        done();
      }); 
    }}
    href={href}
  >
    {children}
  </Link>
);

В Next.js router.push не возвращает промис, но использует Transition API. React вызывает все обновления стейта внутри startTransition одновременно в фоне. Если какое-то обновление будет приостановлено, в нашем случае так делает router.push, то React отложит отрисовку UI, пока все обновления не будут завершены.

Можно считать, что вызов startTransition создает форк текущего дерева и применяет все обновления на этом дереве. После того, как все обновления завершены, новое дерево отрисовывается в DOM.

https://buildui.com/posts/global-progress-in-nextjs

Предоставляйте API платформы вместо обертки

В блоге Джима Нильсена вышла критика в сторону Metadata API в Next.js.

Автор пишет, что предпочитает писать код как можно ближе к тому, как он будет запускаться, а это означает, что нужно оставаться как можно ближе к API платформы. API платформы стандартизировано и при его использовании позволяет легко переключаться с одного фреймворка на другой. Помимо написания кода, ты его запускаешь и дебажишь. Проще дебажить код, который выглядит 1:1 как ты написал.

Metadata API в Next.js – это обертка для генерации meta-тегов. Под капотом у нее много логики, поэтому ее не так просто дебажить:

export const metadata = {
  authors: [
    { name: 'Seb' },
    { name: 'Josh', url: 'https://nextjs.org' }
  ],
}

// Результат:

<meta name="author" content="Seb" />
<meta name="author" content="Josh" />
<link rel="author" href="https://nextjs.org" />

Как видно из примера, Metadata API не только генерирует мета-теги, но и генерирует link-теги.

Еще одно противоречие в том, что для генерации мета-тега viewport используется свое API:

export const viewport = {
  width: 'device-width',
  initialScale: 1,
  maximumScale: 1,
  userScalable: false,
}

// Результат 

<meta
  name="viewport"
  content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no"
/>

https://blog.jim-nielsen.com/2024/expose-platform-apis-over-wrapping-them/

В Waku появился pages router

В Waku появился файловый роутер страниц. Можно создавать новые страницы просто создав файл в ./src/pages. Поддерживаются сегментированные параметры blog/[slug].tsx и шаблоны _layout.tsx для оборачивания дочерних роутов.

Новая страница создается через создание файла с двумя экспортами: дефолтный для компонента и именованный getConfig для функции, которая возвращает объект настройки. В getConfig можно определить метод рендера страницы: динамический SSR и статический SSG.

Если роут с сегментированными параметрами и с статическим методом рендера, то надо заранее определить staticPaths:

// ./src/pages/blog/[slug].tsx

export default async function BlogArticlePage({ slug }) {
  // --snip--
}

const getData = async (slug) => {
  // --snip--
};

export const getConfig = async () => {
  return {
    render: 'static',
    staticPaths: ['introducing-waku', 'introducing-pages-router'],
  };
}; 

Статический рендер происходит во время сборки и его можно использовать в шаблонных роутах_layout.tsx, а дочерние роуты рендерить динамически.

https://waku.gg/blog/introducing-pages-router

onCaughtError и onUncaughtError для обработки ошибок

В React 19 добавятся новые способы обработки ошибок. Это касается новых колбеков для React Root (createRoot и hydrateRoot):

- onCaughtError сообщает об ошибках, обнаруженных Error Boundary
- onUncaughtError сообщает о необнаруженных ошибках
- onRecoverableError теперь использует ES Error Cause, чтобы сообщить об исходной причине ошибок

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

const root = createRoot(container, {
  onUncaughtError: (error, errorInfo) => {
    if (error.message !== 'Known error') {
      reportUncaughtError({
        error,
        componentStack: errorInfo.componentStack
      });
    }
  }
});
root.render(<App />);

Если использовать onRecoverableError в hydrateRoot, то можно узнать причину ошибки гидратации, пример такого сообщения:

Hydration failed because the server rendered HTML didn't match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used:

…

  <App>
    <span>
+     Client
-     Server

https://github.com/reactjs/react.dev/pull/6742

Использование Suspense с React Query

Хук useQuery в React Query возвращает опциональный объект data, он может быть или не быть, зависит от результата загрузки. Если использовать хук useSuspenseQuery, который работает с Suspense, то data будет всегда. Пример использования:

function Example() {
  const { data } = useSuspenseQuery({
    queryKey: ["todos"],
    queryFn: fetchTodos,
  });

  return (
    <ul>
      {data.map((todo) => (
        <li key={todo.id}>{todo.noscript}</li>
      ))}
    </ul>
  );
}

import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

function Parent() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <ErrorBoundary fallback={<div>Something went wrong!</div>}>
        <Example />
      </ErrorBoundary>
    </Suspense>
  );
}

В примере Suspense ответственен за отображение индикатора загрузки. Если запрос закончится неуспешно, то ErrorBoundary отобразит ошибку.

В этом подходе есть ограничения. Например, если изменится queryKey, то Suspense заново отобразит индикатор загрузки. Если надо чтобы компонент Example продолжал отображаться во время повторной загрузки, то придется дополнительно использовать useTransition или useDeferredValue.

Пример с useTransition:

import { useTransition, useState } from "react";
import { useSuspenseQuery } from "@tanstack/react-query";

function Example() {
  const [page, setPage] = useState(1);
  const [isPending, startTransition] = useTransition();

  const { data } = useSuspenseQuery({
    queryKey: ["todos", page],
    queryFn: () => fetchTodos({ page }),
  });

  function handleNextPage() {
    startTransition(() => {
      setPage((prev) => prev + 1);
    });
  }

  return (
    <div>
      {isPending && <p>Fetching...</p>}

      <ul>{/* ...render todos... */}</ul>
      <button onClick={handleNextPage}>Next</button>
    </div>
  );
}

https://www.teemutaskula.com/blog/exploring-query-suspense

CSS в React Server Components

В блоге Джошуа Комо вышла статья про использование CSS-in-JS библиотек в React Server Components. Если вы используете CSS-in-JS библиотеки, то эта статья даст вам полезную информацию о том, какие есть варианты использования в RSC. Если не используете CSS-in-JS библиотеки, то сможете лучше разобраться как устроен RSC.

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

CSS-in-JS библиотеки, которые выполняются в runtime, используют контекст и динамически генерируют стили компонентов, помещая их в тег <style>. Эти стили могут обновляться, если обновляется компонент. В парадигме RSC такой подход не будет работать.

Для того чтобы использовать CSS-in-JS библиотеки в RSC, стоит использовать zero-runtime CSS-in-JS библиотеки, которые генерируют стили во время сборки приложения. Пример таких библиотек: Panda CSS и Pigment CSS. Пример Panda CSS:

import { styled } from '../styled-system/jsx'
export default function Homepage() {
  return (
    <BigRedButton>
      Click me!
    </BigRedButton>
  );
}
const BigRedButton = styled.button`
  font-size: 2rem;
  color: red;
`;

Компилируется в:

/* /styles.css */
.font-size_2rem {
  font-size: 2rem;
}
.color_red {
  color: red;
}

/* /components/Home.js */
export default function Homepage() {
  return (
    <button className="font-size_2rem color_red">
      Click me!
    </button>
  );
}

https://www.joshwcomeau.com/react/css-in-rsc/

Next.js 14.2

Вышел релиз Next.js 14.2. Что нового:

- Улучшение производительности локальной разработки с Turbopack. Интегрировали Lightning CSS – быстрый CSS бандл и минификатор, написанный на Rust. Пока еще Turbopack нельзя использовать для прод сборки.

- Оптимизация сборки:
* Улучшен Tree-shaking. Например, импорт одной иконки из файла с "use client" больше не включает в бандл все остальные иконки.
* Уменьшено потребление памяти для прод сборки.
* Улучшена сборка CSS для предотвращения конфликтов стилей.

- Появилась возможность изменить время жизни кэша страницы.

- Улучшен DX ошибок. Например, при ошибке гидратации сообщается, где и как отличается разметка.

- Поддержка новых фич из React 19, например Server Action и связанные с ним хуки.

https://nextjs.org/blog/next-14-2

React 18.3

Команда React планирует минорный релиз React 18.3. В нем не будет никаких изменений в API, только появятся новые предупреждения об устаревших функциях, чтобы помочь перейти на React 19. Например, React будет предупреждать, если будут использоваться строковые рефы, defaultProps вместе с FC/memo компонентами и при спреде пропа key в элемент.

https://github.com/facebook/react/pull/28843

Как изменится API в React 19

Эндрю Кларк, один из разработчиков React, поделился как изменится API в React 19. О чем он пишет:

- Хуки useMemo, useCallback и мемоизация будут обрабатываться с помощью автоматической оптимизации React Compiler.

- forwardRef станет устаревшим, поскольку ref станет пропом.

- Вместо React.lazy импорта будут использоваться серверные компоненты.

- Хук useContext будет заменен на хук use, который более гибкий и позволяет читать значения Promise и Context.

- Context.Provider будет заменен более простой записью Context.

https://thoughtbot.com/blog/get-your-codebase-ready-for-react-19

HTML атрибуты и DOM свойства

В своем блоге Джейк Арчибальд написал статью о DOM свойствах и HTML атрибутах, в том числе как React с ними работает. Также написал, как React 19 улучшит поддержку веб-компонентов.

Атрибуты и свойства элемента фундаментально разные вещи. Можно иметь атрибут и свойство одинакового имени и разного значения. Например:

<div foo="bar">…</div>
<noscript>
  const div = document.querySelector('div[foo=bar]');

  console.log(div.getAttribute('foo')); // 'bar'
  console.log(div.foo); // undefined

  div.foo = 'hello world';

  console.log(div.getAttribute('foo')); // 'bar'
  console.log(div.foo); // 'hello world'
</noscript>

Чаще всего это различие не важно. Но если надо углубиться в HTML, то хорошо знать в чем разница. Основные различия:

- Атрибуты сериализуются в HTML через свойство outerHTML.
- Атрибуты всегда типа string, когда свойства могут быть любыми типами.
- Атрибуты не чувствительны к регистру, тогда как свойства чувствительны к регистру.

Также стоит знать про рефлексию атрибутов и свойств. Например, в поле ввода input есть свойство input и атрибут input. Свойство инпут не рефлексирует атрибуту value. Вместо этого свойство defaultValue рефлексирует атрибуту value. Пример:

<input type="text" value="default" />
<noscript>
  const input = document.querySelector('input');

  console.log(input.getAttribute('value')); // 'default'
  console.log(input.value); // 'default'
  console.log(input.defaultValue); // 'default'

  input.defaultValue = 'new default';

  console.log(input.getAttribute('value')); // 'new default'
  console.log(input.value); // 'new default'
  console.log(input.defaultValue); // 'new default'

  // Here comes the mode switch:
  input.value = 'hello!';

  console.log(input.getAttribute('value')); // 'new default'
  console.log(input.value); // 'hello!'
  console.log(input.defaultValue); // 'new default'

  input.setAttribute('value', 'another new default');

  console.log(input.getAttribute('value')); // 'another new default'
  console.log(input.value); // 'hello!'
  console.log(input.defaultValue); // 'another new default'
</noscript>

По мнению автора, это правильная логика. Атрибуты предназначены для настройки, тогда как свойства уже могут иметь состояние.

https://jakearchibald.com/2024/attributes-vs-properties/

React 19 Beta

Вышел релиз React 19 Beta.

Что нового:

- Новый хук useActionState (вместо useFormState) для выполнения действий. Может использовать для выполнения асинхронных действий, также его можно передавать в action у тега form. Пример:

function ChangeName({ name, setName }) {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const error = await updateName(formData.get("name"));
      if (error) {
        return error;
      }
      redirect("/path");
      return null;
    },
    null,
  );

  return (
    <form action={submitAction}>
      {/* --snip-- */}
    </form>
  );
}

- Новый хук useFormStatus для получения статуса формы, в которой он находится. Хук получает статус родительской формы, как если бы форма была провайдером контекста.

- Новый хук useOptimistic для реализации оптимистичного UI. Пример:

const [optimisticName, setOptimisticName] = useOptimistic(currentName);

const submitAction = async formData => {
  const newName = formData.get("name");
  setOptimisticName(newName);
  const updatedName = await updateName(newName);
  onUpdateName(updatedName);
};

Хук useOptimistic вернет optimisticName, пока выполняется запрос updateName. Когда запрос завершится или произойдет ошибка, React переключится обратно на значение currentName.

- Новый хук use для чтения промисов.


Улучшения:

- Теперь ref передается как проп в функциональных компонентах. Функция forwardRef будет не нужна и станет deprecated.

- Показ diff для ошибок гидратации.

- Контекст как провайдер, т.е. <Context> вместо <Context.Provider>.

- В колбеке ref можно вернуть функцию очистки, которая будет вызываться при размонтировании компонента. Раньше React при размонтировании вызывал ref повторно с null. Если ref возвращает функцию очистки, то React пропускает повторный вызов ref с null при размонтировании.

- Появилась поддержка предварительной загрузки ресурсов. Новое API в React DOM для предзагрузки:

import { prefetchDNS, preconnect, preload, preinit } from 'react-dom'
function MyComponent() {
  preinit('https://.../path/to/some/noscript.js', {as: 'noscript' }) // loads and executes this noscript eagerly
  preload('https://.../path/to/font.woff', { as: 'font' }) // preloads this font
  preload('https://.../path/to/stylesheet.css', { as: 'style' }) // preloads this stylesheet
  prefetchDNS('https://...') // when you may not actually request anything from this host
  preconnect('https://...') // when you will request something but aren't sure what
}

https://react.dev/blog/2024/04/25/react-19

Получение текущего URL в серверных компонентах в Next.js

В серверных компонентах нельзя использовать хуки. Поэтому, чтобы получить текущий URL, надо использовать middleware, который запишет текущий URL в headers:

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  // Добавляем новый заголовок x-current-path, который получим в компоненте
  const headers = new Headers(request.headers);
  headers.set("x-current-path", request.nextUrl.pathname);
  return NextResponse.next({ headers });
}

export const config = {
  matcher: [
    // Сопоставим со всеми маршрутами кроме статических файлов и API
    "/((?!api|_next/static|_next/image|favicon.ico).*)",
  ],
};

Пример компонента, который получает объект с заголовками через функцию headers:

import { headers } from "next/headers";
 
export default async function Sidebar() {
  const headerList = headers();
  const pathname = headerList.get("x-current-path");

  // ...etc
}

https://www.propelauth.com/post/getting-url-in-next-server-components

Частичный пре-рендер с помощью Bun

Bun представил идею макросов в JavaScript. Макрос в Bun – это механизм запуска JS функций во время сборки. Значение, возвращаемое этими функциями, напрямую встраивается в бандл.

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

Автор предлагает использовать Bun плагин prerender-macro. Пример кода, который использует макросы:

import StaticComponent from "@/static-component" with { type: "prerender" };
import DynamicComponent from "@/dynamic-component";

return (
  <>
    <StaticComponent foo="bar" />
    <DynamicComponent />
  </>
);

С помощью плагина код выше преобразуется в следующий промежуточный код:

import { prerender } from "prerender-macro/prerender" with { "type": "macro" };
import DynamicComponent from "@/dynamic-component";

// ...
return (
  <>
    {prerender({
      componentPath: "@/static-component",
      componentModuleName: "default",
      componentProps: { foo: "bar" },
    })}
    <DynamicComponent />
  </>
);

После чего этот код возвращается в Bun для транспиляции и запуска макросов, которые преобразуют статический компонент в HTML строку во время сборки.

Автор обещает, что при использовании частичного пре-рендера компонентов будет меньше размер бандла и более быстрый runtime рендер страницы.

https://aralroca.com/blog/partial-prerendering

Headless 2.0

Headless – это библиотека компонентов без стилей, но с хорошей поддержкой доступности. Разрабатывается командой Tailwind CSS.

Вышел релиз мажорной версии Headless 2.0. Что нового:

- Интеграция Floating UI для правильного позиционирования якоря дропдауна.

- Новый компонент checkbox.

- Обертки над нативными элементами формы: Fieldset, Field, Label, Input, Select и другие. Внутри них связываются лейбл и поле через ID, добавляются aria-* атрибуты и т.д. Пример использования:

import { Denoscription, Field, Input, Label } from '@headlessui/react'

function Example({ disabled }) {
  return (
    <Field disabled={disabled}>
      <Label>Name</Label>
      <Input name="your_name" />
      <Denoscription>Use your real name so people will recognize you.</Denoscription>
    </Field>
  )
}

- Добавили data атрибуты к элементам для hover, active, focus состояний. Под капотом используются хуки из React Aria. Может пригодиться для стилизации элементов.

- Интеграция TanStack Virtual для виртуализации списка в Combobox.

- Новый сайт и улучшенная документация.

https://tailwindcss.com/blog/headless-ui-v2

Почему глобальный патчинг вреден

В блоге Артема Захарченко вышла статья про вред глобального патчинга API, при котором меняется его поведение. В качестве примера автор приводит fetch в Next.js и Bun:

// Next.js добавил кэширование и возможность сброса кэша
fetch('https://kettanaito.com', {
  next: { revalidate: 10 },
})

// Bun добавил возможность проксировать запрос
fetch('https://redd.one', {
  proxy: 'https://kettanaito.com',
})

В обоих случаях меняется стандартное поведение функции fetch глобально. Глобальный патчинг API не только влечет за собой затраты, которые влияют как на пользователей, так и на мейнтенеров, но и вредит другим API и даже самому языку. Как вредит глобальный патчинг:

- Поддержка. Когда вы что-то меняете глобально, вы изменяете то, чем не владеете. Поддержка того, чем ты не владеешь, сложно. Например, вы изменили глобально fetch, чтобы он умел дедуплицировать запросы. Что будет, если вы будете использовать сторонний модуль, в который также встроен механизм дедупликации. Эти два поведения будут конфликтовать, вызывая проблемы, которые сложно отладить.

- Предсказуемость. Для того, чтобы CSS одинаково работал во всех браузерах были созданы стандарты стилей. Существуют стандарты Web API для кросс-браузерной совместимости. Также Node.js хорошо поддерживает Web API, предоставляя fetch, ReadableStream, WebSocket и т.д. Таким образом, использование одного API в разных средах предсказуемо. Поэтому изменение поведения fetch в Next.js вредит предсказуемости, потому что это поведение будет работать только в Next.js.

- Обучение. Хорошее API должно обучать. Оно должно быть приближено к существующим стандартам.

Взамен существующему глобальному патчингу в bun, можно использовать существующий API fetch и Request и создать отдельную функцию проксирования:

import { proxy } from 'bun'

const proxiedRequest = proxy(proxyUrl, new Request(url, options))
await fetch(proxiedRequest)

Как можно сделать в Next.js:

import { withCache } from 'next'

const request = new Request('https://kettanaito.com')
fetch(withCache(request, { revalidate: 10 }))

Тем не менее, Next.js идет в сторону отдельной функции для кэширования запросов unstable_cache вместо глобального патчинга fetch.

https://kettanaito.com/blog/why-patching-globals-is-harmful

Гайд по SolidJS для React разработчиков

Код на Solid очень похож на React, т.к. оба используют JSX. Однако Solid работает по-другому и важно знать эти отличия. Автор в своей статье написал об отличиях Solid и React:

- Компонент и рендеринг. В React компонент - это функция, которая является частью цикла рендеринга. Компонент возвращает объект, который описывает что должно быть отрендерено. Компонент в Solid - это функция, которая вызывается один раз для создания DOM узла. Можно сказать, что в функция возвращается шаблон.

- Реактивность. В React для реактивности используется useState и контекст, изменение которых вызывает ре-рендер всего компонента. В Solid для реактивности используется createSignal и при изменении значения сигнала ре-рендерится DOM узел, использующий сигнал.

Также автор привел популярные ошибки, с которыми сталкиваются при переходе на Solid. Например, в Solid при деструктуризации пропсов теряется реактивность:

function Message(props) {
    const { text } = props;
    return <div>{ text }</div>
}

Связано это с тем, что Solid использует Proxy для передачи пропсов. Далее, в тех местах где используется проп через . или [], используется get функция объекта Proxy, в котором возвращается сигнал.

https://www.stashpad.com/blog/react-developer-guide-to-solid-js

Как работает RSC

В блоге Smashing Magazine автор Лазарь Николов написал подробную статью о том, как работает React Server Components и как это отражается на загрузке страницы. Перед погружением в RSC автор напомнил, как работают CSR, SSR, SSG и ISR, какие у них преимущества и недостатки.

Автор рассказал как теорию, так и показал на практике, как работает RSC. О чем пишет автор:
- жизненный цикл рендеринга RSC в Next.js;
- что такое RSC payload и как его читать;
- как происходит стриминг HTML по чанкам;
- как в HTML вставляется фолбек Suspense и происходит его замена на отрендеренный компонент.

https://www.smashingmagazine.com/2024/05/forensics-react-server-components/