#инструмент дня

Серверные компоненты React в Parcel.js уже здесь!

Недавно я писал новость о выходе Parcel 2.14.0, который бросает вызов (нет) Next.js и внедряет у себя поддержку серверных компонентов!

И вот, мы дождались примеров!

Тут: https://github.com/parcel-bundler/rsc-examples

1. С сервером
2. Генерация статики — это, пожалуй, моя любимая и довольно недооценённая возможность
3. Клиентские, когда серверные компоненты рендерятся как обычные, интегрируясь в уже сущестующее приложение.

В общем, наконец-то можно нормально пощупать без того, чтобы тянуть весь Next.js. Я очень рад.

#parcel #rsc #react

#инструмент дня

Мой самый любимый виджет из всех — Modal Bottom Sheet. Это как в построении маршрута на Google Maps. Шторка, по-нашему. Дёргаешь её туда-сюда, забавно.

Так вот, в мобильных фреймворках вроде того же Flutter и SwiftUI шторка реализована из коробки, а для веба — приходится изгаляться.

Хотя у шторки на мобильных устройствах очень много на самом деле общего со множеством других виджетов: модалка, тост, боковое меню, лайтбокс, стек (как в Tinder). Просто потому что их очень интуитивно можно смахнуть или развернуть жестами.

Так вот, собственно, к чему это я: https://silkhq.co/

Прекрасная библиотека, реализующая шторку и ей подобные виджеты, их анимации и взаимодействия на разных устройствах.

Множество примеров, нативные анимации, жесты. Одна проблема: платная для коммерческого использования. И не открытая.

Две, получается, проблемы :(

P. S. В комментариях пишут, что так-то три проблемы. Третья — React. Штош.

#react #sheet #widget

#инструмент дня

Охренеть какая штука!

https://react-explorer.com/

Это обозреватель зависимостей. Я бы даже сказал, созвездия завимимостей и сейчас вы поймёте, почему.

Потому что помимо простого дерева, которое в целом умеет строить кто угодно, тут имеется мини-карта!

Перемещаешься по карте — смотришь подсвеченные созвездия. Инспектор работает на любом реакт-сайте без отдельной установки, потому что построен по принципу React Scan — инджектит React DevTools на страницу.

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

Проект пока не открыт, но находится в открытом тестировании.

#react #analyze #dependencies

#заметка дня

Не знаю, как вас, но меня очень раздражает то, что в React Router состоянием скролла надо управлять самостоятельно.

Перемещаешься по роутам, а скролл на месте остаётся. Ну типа, што.

К счастью, решение что для v5 React Router, что для v6 одинаковое:

function ScrollToTop() {
    const { pathname } = useLocation();

    useLayoutEffect(() => {
        document.documentElement.scrollTo(0, 0);
    }, [pathname]);

    return null;
}

И потом вставляете его в контекст роутинга:

<BrowserRouter>
    <Routes>
         ...
    </Routes>
    <ScrollToTop/>
</BrowserRouter>

Но вот я это всё по привычке написал и решил всё-таки посмотреть документацию. Ну бывает. И вот что там: https://reactrouter.com/en/main/components/scroll-restoration

Восстановление скролла теперь поставляется из коробки! И умеет гораздо больше, чем просто скроллить наверх. Правда, требует изменения корневого роутера. Благо, это несложно.

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

По-моему, очень круто. И хорошо, что решение официальное.

#react #router #бородач

#инструмент дня

Вы только посмотрите на эту красоту!

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

И не только для React! Vue и Svelte тоже там.

Итак, встречайте: NumberFlow от Максвелла Барвиана.

GitHub: https://github.com/barvian/number-flow
Документация и демо: https://number-flow.barvian.me/

Настраивается формат чисел, параметры анимированных переходов. И, собственно, никаких скрытых зависимостей.

Прекрасное.

#react #number #transition #бородач

Дэн «наше всё» Абрамов разродился статьёй!

React for Two Computers

— Почему мой компонент работает в браузере, но не на сервере?
— Потому что у тебя теперь два компьютера. Привыкай.

💥 Что вообще происходит?

Раньше React жил в браузере и радовался жизни: всё происходило на клиенте, стейт в useState, кликнули — перерендерили.

А теперь у нас появился второй «компьютер» — сервер. С серверными компонентами, приватными API, тяжёлыми вычислениями и всем остальным. И теперь React — это не просто `f(state)`, а f(data, state), где:

- data — с сервера, рендерится один раз
- state — в браузере, реагирует на действия пользователя

🧠 React теперь работает в двух мирах:

- Сервер — отвечает за данные, безопасность и тяжёлую работу
- Клиент — за мгновенные отклики, интерактив и состояние

Они живут в разных средах, но должны строить один интерфейс. И вот тут начинается веселье.

🧩 Но в чём подвох?

Абрамов говорит прямо: разделение компонентов на клиентские и серверные — это боль.

- Хочешь использовать хук? Прости, сервер не умеет
- Хочешь загрузить данные? Сервер умеет, но клиент не должен знать как
- Хочешь просто написать код? Удачи с этими use client, use server, границами, пропами и тайпингом

🧠 Примеры из статьи

- <Counter /> — типичный клиентский компонент. Быстрый отклик, стейт, интерактив
- <PostPreview /> — серверный. Может грузить пост из базы и вообще не попадать в бандл клиента

И вдруг возникает челлендж: а как показать список <PostPreview />, а рядом <Counter /> для лайков? Как они будут жить вместе?

Ответ: через пропсы, границы, и много боли.

📦 React как Lego из серверных и клиентских кусочков

Абрамов не просто жалуется — он исследует. Он пытается найти модель мышления, при которой:

- Ты не дублируешь код
- UI остаётся отзывчивым
- Компоненты переиспользуемы
- И при этом ты не хочешь сжечь проект через неделю

Он говорит: возможно, будущее React — это когда мы думаем не в терминах "компоненты", а в терминах "где этот кусок должен жить?"

🎥 Есть и видео!

Если лень читать или хочется живого контекста — Дэн рассказал всё это на конференции React Conf 2024.
Там много примеров и визуальных пояснений.

🧨 Финалим

«React теперь не просто библиотека для UI. Это **координация между двумя средами исполнения**. Между клиентом и сервером. И это сложно. Но в этом сила.»

Пока что — это боль.
Но если мы научимся думать в этой модели — React станет по-настоящему мощным инструментом для приложений нового поколения.

🔗 Читать статью целиком

📺 Смотреть видео React Conf 2024

#react #frontend #абрамов #servercomponents

#инструмент дня

Так вышло, что в своей карьере я умудрился поработать в компании, которая хотела сделать стримы на веб-сайте своей основной фишкой. С тех пор HLS, RTP и nginx-rtmp-plugin были моими друзьями.

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

Но сегодня я наткнулся на нечто прекрасное: https://compositor.live/

Это набор React-компонентов и медиасервер, который позволяет стримить видео и микшировать несколько потоков, управляя ими как обычными компонентами и элементами страницы!

Можно построить нечто аналогичное Google Meet за считанные дни.

Вырезать зелёный экран, добавить текст, поменять видео местами, наложить блупер — всё на месте. Напоминает react-three-fiber по своей сути.

#react #video #mixer #media #stream #бородач

#статья дня

Дэн наше всё Абрамов недавно написал статью о новом способе передачи данных с сервера — Progressive JSON. Это не просто использование курсоров для пагинации, как в том же JSON:API, а настоящий поток данных, где структура JSON передаётся частями, по мере её готовности.

Вообще, много пишет последнее время. Это хорошо!

Зачем нужно? Собственно, для работы React Server Components в том числа!

Пример такого потока:

{
  "header": "Welcome to my blog",
  "post": "$1",
  "footer": "Hope you like it"
}

Видите заглушку $1? Позже — в том же потоке! — приходит следующий кусок:

/* $1 */
{
  "content": "This is my article",
  "comments": "$2"
}

На стороне клиента это будет выглядеть как:

{
  "header": "Welcome to my blog",
  "post": {
    "content": "This is my article",
    "comments": new Promise(/* ... not yet resolved ... */),
  },
  "footer": "Hope you like it"
}

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

Если вам интересна тема оптимизации загрузки данных, стоит прочитать статью Дэна: Progressive JSON.

А, или посмотреть в формате видеоподкаста! Тут: https://www.youtube.com/watch?v=MaMQLNBZz64

#react #json #rsc

#статья дня

Можно ли заменить стейт-менеджеры — простым localStorage?

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

Давайте подумаем:

> Не всё должно быть постоянным. Допустим, у тебя открыто модальное окно. Перезагрузил страницу — и оно снова открыто, потому что значение сохранилось в localStorage. Абсурдный UX.

> Нет реактивности. Если просто читать из localStorage, React не узнает, что данные изменились, и не перерендерит компонент. Придётся вручную дёргать setState.

> Событие storage работает не так. Оно срабатывает только в других вкладках, а не в той, где ты вызвал localStorage.setItem(). То есть синхронизацию внутри приложения оно не решает.

> Ограничения. Только строки, лимит около 5 МБ, возможные ошибки при парсинге JSON, коллизии ключей. Всё это требует дополнительных костылей.

> SSR недоступен. На сервере localStorage просто не существует, и код падает с ошибкой.

localStorage и, частично, sessionStorage отлично подходят для мелочей:

> выбор темы,
> сохранение введённых данных формы,
> открытая вкладка меню,

Но как только речь заходит о данных, которые должны синхронно обновляться в разных компонентах и вызывать ререндер — нужен Context или полноценный state-менеджер.

Итак: localStorage — это удобное дополнение к Context/Redux/Zustand, но не замена. Он решает задачу «сохранить между сессиями», а не «синхронизировать состояние внутри React».

А если хотите подробностей — собственно, статья от Нади Макаревич: https://www.developerway.com/posts/local-storage-instead-of-context

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

#react #localstorage

#фишка дня

И #тред дня, и #статья дня... Сегодня всё и сразу от Джоша Комо.

И речь пойдёт о недооценённом хуке в React: useDeferredValue.

Итак, некоторое время назад Джош выпустил свой инструмент для создания красиво выглядящих теней (да-да, drop-shadow просто уже недостаточно). И одной из проблем инструмента стала... дёрганая реакция на движение ползунков. Как будто мало FPS.

Начав разбирать проблему, Джош понял, что событие onChange происходит очень часто, за это время надо успеть сгенерировать тень, потом отрисовать её, потом вставить код в редактор для копирования. А редактор, естественно, ещё пытается этот самый код подсветить.

Но что нам нужно? Нам ведь сначала нужен результат, а уже потом — код. Так почему бы не заполнить код чуть позже, не нагружая систему?

И именно для этого и нужен хук useDeferredValue. Данные молучим только когда основной процесс рендеринга завершится. Буквально ленивое выполнение.

Собственно, тред и статья если кто предпочитает подробности. Там, как всегда, шикарно.

Будьте разумно ленивыми, котаны!

#react #hook #бородач