ReactJS *

Задумывались ли вы когда-нибудь о том, что на самом деле происходит под капотом, когда вы рендерите приложение React? Мы знаем, что React строит дерево DOM и отображает UI на экране, но как React конструирует это дерево и как он эффективно обновляет его при изменении состояния?

В этой статье мы рассмотрим React Fiber — основной движок согласования (reconciliation) React. Мы рассмотрим, как React строил DOM до v15, недостатки этой ранней стековой (stack) модели с точки зрения производительности и то, как асинхронная архитектура Fiber решает эти проблемы, начиная с React v16 и до React v19.

Очередная история про AI и разработку, но с конкретикой. Mattermost на Team Edition, три ежедневные боли: нельзя нормально ответить на сообщение в канале, не видно прочитал ли коллега, для созвона кидаешь ссылку на локальный Jitsi с отдельной авторизацией.

За день собрал три плагина в Cursor: reply с цитатой, галочки доставлено/прочитано, голосовые комнаты на Pion прямо в server‑плагине. Личная инициатива, не тикет в бэклог. Коллегам понравилось, мне в копилку.

Рассказываю, почему не переезжали на другой мессенджер, как задавал рамки AI (опыт с медиа помог), и где плагины не работают: спойлер, нативные приложения.

P. S. про обложку. Превью для Habr тоже сгенерировал AI. Оно, конечно, вообще не похоже на настоящий Mattermost: другие цвета, другой UI, будто мессенджер из параллельной вселенной. Но мне так понравилось, что решил оставить. Пусть будет из разряда «ожидание vs реальность» или «Mattermost, который мы заслуживаем».

Чем больше автономии я даю ИИ-агентам, тем больше требований к коду превращаю в механические проверки. Когда eslint-plugin-react сломался на ESLint 10, я собрал продолжение для React 19: сократил 102 активных правила до 11 и исправил ошибки, которые проявились только в реальных проектах.

Затеял ремонт в ванной, дошёл до плитки — и тут понеслось. Санузел у меня Г‑образный, в углу венткороб, раскладку хочу диагональную, а «раздели площадь на плитку» вообще не работает, я это понял когда мои циферки не сошлись с тем что плиточник насчитал — разница набежала непонятно откуда.

Плиточник говорит — берите пятнадцать процентов запаса и всё. Пятнадцать процентов от плитки по 2000 с лишним за метр это уже сумма, я в столбик посчитал и решил что нет, надо по‑другому. Калькуляторы онлайн — площадь на цену умножают, я и сам умею. В CAD полез — там сначала модель строй, а мне не чертежи нужны были.

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

Современные веб-приложения содержат сложную бизнес-логику, которая ранее традиционно располагалась на бэкенде. С ростом сложности возникает необходимость в эффективном управлении зависимостями для поддержания тестируемости, модульности и слабого зацепления этих модулей в приложении. Принцип Инверсии зависимостей (Dependency Inversion, DIP) и его реализация в лице механизма Внедрения зависимостей (Dependency Injection, DI) становится ключевым инструментом для решения этих задач.

Тема хранения токенов — одна из самых больных в авторизации. Многие, не до конца понимая, как авторизация должна работать, кладут оба токена в cookie или — что ещё хуже — в localStorage. В этой статье мы соберём схему, в которой access‑token живёт в памяти приложения, refresh‑token — в HttpOnly‑cookie, а фронтенд сам восстанавливает сессию после перезагрузки страницы и незаметно обновляет протухший access.

Бекенд — на Go, фронтенд — на Vue 3 (Vuex + vue‑router + axios), но концепция так же применима к React и Next.js. Верстку и стили оставляю за кадром — в статье только логика авторизации.

Стейт-менеджеров в JavaScript уже столько, что идея написать ещё один выглядит немного сомнительно. Есть Redux Toolkit, Zustand, MobX, Jotai, XState и десятки менее известных библиотек. Почти для любого способа хранить состояние уже существует готовое решение. Но все же в качестве эксперимента, решил реализовать свою идею.

Я разозлился на то, что Lens стал платным, и написал свой платный Kubernetes-клиент: закрытый репозиторий, биллинг, версии до 1.7.12. Потом схлопнул историю в один коммит, выкинул платёжный код и выложил всё под MIT. Ирония дошла до меня чуть позже, чем следовало.

Под катом — как правило «не утверждать того, чего не можешь подтвердить» превращается в конкретные баги: под в Running с мёртвым контейнером внутри, Service с исправным селектором и нулём трафика, истёкший токен GKE, который выглядит как пустой кластер. Почему запрет на refetchInterval в линтере сэкономил 77% запросов к API-серверу. Как я трижды поймал одну и ту же гонку с Tauri-событиями. Как пришёл друг и переписал три четверти фронтенда, а я посчитал git blame, чтобы понять, что от меня осталось. И что я узнал, когда скачал собственный релиз, а macOS сообщила, что он повреждён.

Бывает так: есть фулстек проект, и в нём всё хорошо. Откуда-то есть сквозные типы (tRPC, генерация из OpenAPI), есть авторизация, есть основной функционал. А потом вы решаете добавить реалтайм: уведомление о новом посте в ленте, чат между пользователями, интерактивную доску. И появляется целый новый слой абстракций, в котором надо заново изобрести всё, что в проекте уже есть, только на новый лад. И дальше поддерживать две разные системы.

В своём фреймворке Point0 я добавил четыре новых реалтайм-поинта (структурные единицы наравне со страницами, лэйаутами, квери, мутациями): канал, спейс, клиентский хэндлер, серверный хэндлер. На них собирается практически любая реалтайм-функциональность, кода получается мало, и читается он интуитивно. Эти поинты несут те же свойства, что и все остальные:

код сервера и клиента живут в одном файле, компилятор вырезает клиентский код из серверной сборки, а серверный из клиентской

типизация сквозная и выводится из дженериков самого фреймворка, без генерации типов

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

Разработчик интерфейсов уверен, что выбранный им фреймворк автоматически решает за него вопросы структуры и организации кода. Он искренне верит, что если взять React, Angular, Vue, да тысячи их, то получает в руки серебряную пулю, которая закроет все проблемы разработки. Достаточно следовать документации фреймворка, и с проектом все будет хорошо в долгосрочной перспективе. И я сам долгое время рассуждал точно так же, я воспринимал только Angular, потому что там есть хоть какой-то структурный подход. На практике это оказывается большим заблуждением.

Книжный тир-лист, SPA, боты и 55 запросов в месяц. Честная история пет-проекта: от «все обнимут меня» до пререндера и коллабораций с блогерами.

В этой статье последовательно разобран полный цикл обновления React: от Virtual DOM до внутреннего устройства Fiber Reconciler.

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

Мой принцип был "работает и ладно", но принципы нормального фронтенда явно отличались. Шишек я набила знатных с точки зрения чистоты и логики кода.

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

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

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

Optimistic update меняет клиентское состояние до ответа сервера. Autosave отправляет новую версию после паузы во вводе. До завершения action в приложении одновременно существуют локальные данные, запрос в работе и последняя подтверждённая версия на сервере.

При optimistic create клиент может показать сущность с временным id, а сервер вернуть другой id. Ошибка после частичной записи оставляет сущность на сервере и запускает локальный rollback. При autosave ответы приходят не в порядке отправки. Старый ответ меняет статус уже после сохранения новой версии. updatedAt может перейти вперёд до завершения записи.

В учебном проекте Workbench optimistic create использует clientId для одинакового id на клиенте и сервере. Autosave-демо передаёт requestId в каждый запрос. Редактор хранит статусы saving, saved и error отдельно от текста заметки.

localStorage существует только в браузере. App Router может подготовить HTML на сервере и для Client Component. Код с директивой use client получает состояние, эффекты и обработчики событий, но первый рендер всё ещё может пройти без window и localStorage. И возникают два сбоя. Прямое чтение localStorage падает на сервере. Проверка через typeof window возвращает разные данные на сервере и в браузере. Сервер строит пустое избранное, браузер видит сохранённые id, React получает разные деревья при hydration.

Поиск в Next.js App Router связывает несколько механизмов — Server Components, dynamic routes, searchParams, metadata и клиентские фильтры. Если в проекте одна форма и несколько результатов, состояние можно держать в useState. В каталоге или агрегаторе каждый фильтр меняет URL, набор данных и правила индексации.

В статье на примере учебного проекта EventMap — агрегатора событий, разберем, как спроектировать систему фильтрации, которая генерирует чистые, индексируемые URL для поисковых роботов и обновляет выдачу при изменении фильтров. Страницы вроде «Концерты в Москве» или «Выставки в Петербурге» могут работать как отдельные landing pages. Для них нужны серверный HTML, постоянный URL, свой title, description, h1, canonical и отдельная политика index или noindex. Произвольные запросы, сортировки и глубокая пагинация остаются частью поиска и не попадают автоматически в индекс. Поиск построен через App Router, optional catch‑all route, серверный рендер результатов и общий набор функций для URL, metadata, canonical и sitemap.

Поиск по каталогу создаёт отдельное состояние для каждой комбинации фильтров. Категория, город, дата, сортировка, поисковая строка и номер страницы попадают в URL. При десяти категориях, пятидесяти городах и пяти вариантах сортировки получается 2500 комбинаций без учёта пагинации и свободного текста. Интерфейс должен обработать все допустимые комбинации. В поисковый индекс обычно попадает только часть из них. Страница категории music, страница города london и сочетание music/london могут содержать устойчивую подборку. Запрос ?q=free+jazz+tonight, сортировка по цене и восьмая страница выдачи относятся к текущему действию пользователя. Фильтры без отдельной политики создают большое пространство URL. Google описывает эту проблему в документации по faceted navigation. Изменение каждого параметра создаёт новый адрес, краулер тратит запросы на многочисленные комбинации и позже обнаруживает, что многие из них не содержат самостоятельного материала. (Google for Developers)

Когда Atlassian объявила о завершении продаж Opsgenie, я сначала отреагировал как нормальный инженер: решил ничего не переписывать. Потом календарь напомнил, что нормальность имеет срок действия. Продажи Opsgenie прекратились 4 июня 2025 года, а поддержка завершится 5 апреля 2027 года. После этого сервис станет недоступен, а немигрированные данные будут удалены. Это не слух из рабочего чата, а официальная позиция Atlassian (условия и даты завершения Opsgenie).

Предлагаемый путь ведёт прежде всего в Jira Service Management, причём Atlassian описывает автоматизированную миграцию данных и конфигурации (официальная страница миграции). Для многих компаний это разумный маршрут. В моём случае требование было другим: сохранить существующую self-hosted Jira, не превращать замену on-call инструмента в миграцию всей сервисной модели и получить контроль над данными, интеграциями и deployment.

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages (официальный сайт OpsKnight). На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

Каждые пять лет я слышу одно и то же: фронтенд больше не нужен, ему остался последний год. Сначала говорили про визуальные конструкторы - Wix, Tilda, все дела. Потом, когда ИИ выстрелил, начали хоронить разработчиков под флагом «AI напишет тебе кнопку за секунду». А сейчас новая мода - фулстекеры. Приходят такие ребята и говорят: «Да зачем нам отдельный фронт, я сам и бэк, и фронт на коленке соберу, проект сэкономит, все будут счастливы».

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

На планировании оценивают задачу: «добавить бейдж VIP на карточку клиента». Разработчик открывает CustomerCard.tsx, молчит и говорит: «Дня три». Никто не смеётся — все открывали этот файл. В нём почти семьсот строк, и он умеет всё: грузит клиента и его заказы, кэширует, валидирует форму, различает три роли, экспортирует CSV и не падает. Сцена собирательная, но файл — нет: для этой статьи я вырастил его сам, шаг за шагом, и каждый шаг сохранил.

Вопрос к такому файлу — не «почему он большой?». Вопрос — «сколько у него причин измениться и кто их считает, кроме ревьюера?»

За годы code review я много раз наблюдал рождение комбайна и ни разу — конкретный момент, когда обычный компонент становится неуправляемым. Такого момента нет: каждое отдельное изменение выглядит разумным, укладывается в дедлайн и проходит ревью. Поэтому статья устроена как хроника: один компонент, пятнадцать вредных советов, и после каждого — счёт, который выставляет машина.

Неуправляемость не измеряется строками — строки лишь симптом. Болезнь — число причин изменения, собранных в одном файле. Пока их никто не считает, комбайн растёт легально: каждый его шаг проходит code review.