ReactJS *

Введение

Представьте, что вам нужно отрендерить в React-приложении таблицу с 100 000 объектов, которые непрерывно обновляются в реальном времени через WebSocket. Каждые 50 мс прилетает батч из 5000 дельт (изменений).

Стандартный подход с useState или классическим Redux (с Immer) убивает браузер за несколько секунд:

▎ Может он и быстр, только экосистема нулевая. Ну и ещё система модулей кастомная, что полностью убивает любые готовые инструменты. Так что $mol — по сути одной ногой в могиле.
▎ Был у меня сложный компонент, допустим weather_widget. И вот в 20 местах на него наложили оверрайды. А потом я пересобрал этот widget. Что произойдёт с оверрайдами, которые знают внутреннюю структуру зависимости? Правильно, всё пойдёт крахом.

▎ Вот вы реально готовы поставить свой доход на вот это?

На примере панели профиля вынесем логику и подготовку данных в useSetup[Component], а в компоненте оставим разметку. Затем отдельно проверим setup-хук, компонент через Shallowly и взаимодействие через React Testing Library. В конце — полный пример с Vitest, который можно забрать и запустить.

Если следить за React только по крупным релизам, легко пропустить момент, когда библиотека тихо меняет направление. React 19.3 — как раз такой случай. Сам релиз вышел 9 сентября 2026 года. И я хочу поделиться парой моментов из этого обновления. Рассмотрим пару хуков это ViewTransition и Fragment Refs. Еще, что я могу выделить, это новые возможности для SSR, Server Components и работы с браузерными API.

Зелёный тест на учебном стенде ещё ничего не гарантирует, на реальном проекте он может падать через раз.

Рассказываю о тренажёре, который начинается как обычный курс, а потом включает Hard Mode: надоедливые попапы, медленный бэкенд и промо, которое перекрывает экран в самый неудобный момент.

Что внутри: курс из 11 уроков, Hard Mode с воспроизводимыми флаками и Flake Score, который показывает, переживёт ли тест реальный проект.

Привет, Хабр! Меня зовут Егор Смирнов, я руководитель команды Backend for Frontend в VK. Одна из зон нашей ответственности — поддержка и развитие инфраструктуры для фронтенда ВКонтакте. 

Веб-версии ВКонтакте в 2026 году исполнилось 20 лет. За это время наш фронтенд прошёл путь от AJAX до современного веб-приложения. Раньше мы вручную манипулировали DOM, сборка иконок превращалась в приключение, а деплой и откат занимали по полчаса. К середине 2026 года мы выстроили масштабируемую архитектуру, в которой компоненты, сборка и деплой работают как единая система.

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

Карточка в каталоге обычно ведёт на detail page. Для прямого перехода нужен отдельный URL вроде /events/123. Для просмотра нескольких карточек подряд удобнее оставить список на экране и открыть detail поверх него. Если modal хранится только в useState, адрес страницы не меняется. Прямую ссылку на открытый объект получить нельзя. После reload остаётся список, а поисковый робот видит только исходную страницу.
App Router поддерживает другую схему. Один detail URL открывается как modal при client-side переходе из списка и как обычная страница при прямом запросе или reload. Для этого используются Parallel Routes и Intercepting Routes. Next.js описывает тот же паттерн для modal поверх gallery или другого списка. В учебном EventMap этот маршрут используется для событий.

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

Привет, Хабр. Расскажу про проект, который делал последние несколько месяцев. Это не очередная «убийца HH» и не «революция в рекрутинге». Это попытка решить одну конкретную проблему, которая бесит меня лично.

Живая ссылка: https://devraid.ru

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

Обеспечивает быструю первоначальную загрузку даже персонализированных страниц.

Делает клиентские переходы в приложениях с серверным рендерингом мгновенными.

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

Эта модель называется Cache Components, и в Next.js 17 она будет использоваться по умолчанию.

До этого релиза мы не рекомендовали её для всех без исключения приложений: в некоторых сценариях она не могла обеспечить те же гарантии по затратам и производительности, что и прежняя модель.

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

Начиная с Next.js 16.4, мы с уверенностью рекомендуем Cache Components как лучший выбор для любого приложения на Next.js.

Корпоративный сайт на пяти языках: около сотни страниц, блог, новости и 100–150 тысяч пользователей в месяц. Два года он жил на Webflow. Переезд на Next.js 15 и Payload CMS сейчас на финишной прямой, и шёл он без дня Х: страница за страницей, на одном домене со старым сайтом.

Разбираю, как это устроено. Счёт Webflow по строкам, Next.js под /app на Webflow Cloud и 301-редиректы с пятью локалями, перенос CMS-коллекций в Lexical, next-intl и проверки в CI, которые ловят то, что раньше находил только дизайнер через месяц.

Чтобы React летал как Vue 3, достаточно забрать у него тяжелые вычисления и переложить их на плоский реактивный граф зависимостей с умным планировщиком транзакций на уровне микрозадач.

Architecture Baseline определяет границы системы и ключевые архитектурные решения. Но настоящая проверка начинается тогда, когда эта архитектура превращается в работающий код.

В этой статье про переход к первой Full Stack вертикали Enterprise GenAI Platform: React, ASP.NET Core, EF Core и PostgreSQL, модуль Chats, границы frontend и backend, observability, автоматические проверки и End-to-End acceptance.

Главный вопрос “как перейти от архитектурной модели к реализации, не разрушив её преждевременным усложнением”.

Я делаю мобильное образовательное приложение. В какой‑то момент понадобилось объяснять пользователям сложные сценарии, где объекты двигаются по строгим формальным правилам, и объяснять не текстом, а видео. Любая неточная траектория или неверно анимированное действие на видео закладывает неверный паттерн. Я собрал для этого конвейер на Remotion и React Three Fiber.

Что будет, если production smoke-тесты начнут вести себя почти как настоящие пользователи? В статье рассказываю, зачем я запускаю автоматические проверки прямо в проде, как они проверяют реальные пользовательские сценарии и почему однажды из-за них статистика мессенджера внезапно оказалась слишком оптимистичной. Разберём synthetic traffic, soft delete, искажённые DAU/WAU/MAU и то, как отделять техническую активность от реальной, не отказываясь от production smoke.

Неделю назад я рассказывал про Klark + Klara: корпоративный мессенджер и таск‑менеджер, которые живут на нашем сервере. В той статье было про устройство: каналы, звонки, расшифровку голосовых, связку «задача из сообщения». Эта статья расскажет вам более подробно о том как продукт выглядит " сейчас " и что в дальнейшей перспективе мы планируем реализовать.

При разработке приложения ключевой фактор который мы преследовали - это удобная связка приложений для закрытия наших задач, но со временем мы начали апгрейдить его в самых разных частях, где-то стикеры кастомные добавили, где-то внедрили кастомную анимацию, и так далее. Я не знаю как простым языком описать то чувство, когда ты делаешь продукт и видишь то, что он на набросках визуально отличается от того что я рисовал на эскизах и представлял в голове, но это чувство не давало мне покоя, поэтому я собрался с мыслями и переделал интерфейс в то, как оно выглядит в моей голове. Новое оформление со стеклом и «жидкими» подсветками, панель эмодзи и стикеров, своя картинка фона и шапка профиля.Ну и традиционный раздел про то, что сломалось по дороге: самые глупые баги всё ещё живут дольше всех.

Если у вас несколько фронтенд-сервисов с одинаковыми компонентами (например, сайдбаром), вы либо уже страдаете, либо скоро начнете. Мы начали страдать на шестом.

Добавить новый пункт меню сайдбара. Казалось бы, пять минут. У нас это было как шесть кругов ада: шесть pull-request’ов, шесть ревью, шесть деплоев и бесчисленное количество запущенных CI-пайплайнов ради одной строчки в навигации.

Начали искать решение. Смотрели разные варианты, остановились на Module Federation. Написали прототип, попробовали пару плагинов, словили пару багов, починили, перенесли в код production-сервисов. С тех пор общий UI-каркас живет и деплоится отдельно от всех сервисов уже два года без каких-либо проблем.

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

Почему архитектура важнее выбора стейт-менеджера в React

Когда я только начинал свой путь разработчика мне было интересно изучать новые технологии. Учил все подряд. Все знал. Но что лучше или хуже и уже тем более почему — сказать не мог. Именно об этом — как писать код правильно — я собираюсь сейчас рассказать. И буду это делать через призму выбора стейт-менеджера в React.

Всем привет! Меня зовут Даниил Николаев и я frontend-разработчик в компании "Исходный Код"

На каждом kickoff нового проекта всплывает один и тот же сценарий: один разработчик топит за утилиты Tailwind, второй отстаивает чистоту и надежность CSS Modules, третий по привычке тянет проверенный CSS-in-JS, а кто-то просто молча открывает .scss и выходит из созвона.

В этой статье мы опустим споры о «красивом синтаксисе» и разберем инженерную сторону вопроса: кто на самом деле платит за динамику — сборка или браузер клиента.

Заглянем под капот ключевым подходам в мире React (для уровня middle и middle+): разберем классические CSS Modules, ушедший в maintenance mode styled-components, Emotion, современный Tailwind v4 на движке Oxide и перспективный zero-runtime (Linaria, Vanilla Extract). Посмотрим, что реально происходит с CSSOM, reflow и рендером в браузере, а в конце — соберем практическую матрицу выбора без фанатизма и хайпа месяца.

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