ReactJS *

Что поисковики и ИИ предлагают учить перед собеседованиями? Чаще всего — что-то в духе списка вопросов с гитхаба.

И как это учить? Тупо нажимать на каждый ответ и заучивать разницу в синтаксисе?

А на собесе потом:

410 вариантов писем, сотня микросервисов и до 15 файлов, которые приходилось править ради одной нотификации. Добавление письма превратилось в квест: создай компонент, подключи, опиши параметры, зарегистрируй — и молись, что ничего не забыл.

Мы устали и автоматизировали это. Теперь описываем контракт письма в OpenAPI, а CLI генерирует весь boilerplate — от NestJS-артефактов до React-компонента с типизированными пропсами. Часы работы сжались до минут.

Меня зовут Денис, я фронтенд-разработчик в ЮMoney. В этой статье расскажу, почему мы пришли к кодогенерации, как устроили процесс и что в нём изменилось для разработчиков, дизайнеров и тестировщиков. Материал будет полезен тем, кто работает с React, NestJS или TypeScript и хочет перестать писать однотипный код вручную. Особенно если поддержка UI-компонентов и API-слоя отнимает время, которое лучше потратить на реальную логику.

Банальный пример — когда печатаешь в input, а интерфейс начинает лагать на большом списке: классическая боль старого React. Я решил разобраться, как и почему React переписал свою архитектуру: отказался от рекурсивного обхода дерева, изобрел новую структуру данных и научился прерывать рендер ради нашего ввода.

В статье рассмотрю проблемы синхронной отрисовки и переход к новой архитектуре,  почему пришлось отказаться от методов жизненного цикла с приставкой *will, что такое Fiber, почему первый вариант приоритизации с ExpirationTime не сработал и как пришли к React Lanes.

Геогессеры обычно строятся на панорамах улиц: вид с земли, а вы ищете вывески, дорожные знаки, номера машин. Работает, но угадываете вы в итоге по надписям.

Я сделал Location King — игру на спутниковых снимках. Показывается участок съёмки сверху, без подписей, границ и координат. Надо понять, где это, и поставить точку на карте мира. Чем ближе к цели, тем больше очков, максимум пять тысяч за раунд.

Меня зовут Илья Краснопольский, я занимаюсь разработкой в области геоинформатики и градостроительства. Идея простая: сверху местность опознаётся не хуже, чем с земли, просто признаки другие.

Каждый день мы пишем JSX, используем хуки и стараемся не нарушать их строгие правила. Но как вся эта «магия» работает под капотом? Почему условный рендер ломает useState, а индексы массива в key приводят к багам? Зачем React перешел на архитектуру Fiber и как алгоритм обходит дерево элементов, не блокируя браузер?

Чтобы перестать воспринимать React как черный ящик, лучший способ — написать его с нуля.

В этой статье мы шаг за шагом воссоздадим собственный движок React. Мы реализуем функцию createElement, разберем Fiber-архитектуру с асинхронным рендерингом, напишем алгоритм Reconciliation и создадим систему хуков, разобравшись в логике их работы.

Прошлый раз я рассказал, как написал свой калькулятор раскладки плитки, потому что замучился считать ванную в столбик. Тот пост был про версию 1.2 — база, прямая/диагональная раскладка, смета, PDF, нумерация плиток. Комменты были классные, фидбек пошёл сразу, и за месяц я выкатил ещё три версии. Самое заметное — ёлочка и общий план квартиры, где все комнаты лежат на одном полотне. Про это и пишу.

После экспорта из Figma иконка 24×24 может оказаться в браузере крошечной, огромной или размытой. Обычно файл при этом исправен — просто разные части цепочки смотрят на разные параметры. Разбираем систему координат, viewBox, контракты и ловушки в React.

Последние недели делал небольшой проект, который в итоге назвал 410.chat.

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

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

Так появился 410.

Современный JavaScript / TypeScript сегодня, предоставляет мощный инструмент для асинхронного программирования, который знаком каждому - async/await на основе Promise. Он позволяет писать последовательный код и легко обрабатывать ошибки. Однако за простотой скрываются серьёзные ограничения, которые становятся критичными в высоко-нагруженных системах, играх, сложных пользовательских интерфейсах и приложениях, требующих предсказуемой производительности.

Представьте себе сервер, обрабатывающий тысячи запросов одновременно. Все они конкурируют за процессорное время. Как гарантировать, что запрос от клиента выполнится раньше, чем фоновая синхронизация? Как отменить долгую операцию, если клиент разорвал соединение? Как избежать пауз сборщика мусора при создании миллионов временных объектов? Нативный async/await не даёт ответов на эти вопросы - он лишь оборачивает асинхронные операции в удобный синтаксис.

В этой статье мы разберём, как кооперативные корутины (Coroutines) решают эти задачи на примере моей библиотеки ts-adaptive-coroutines, изучив каждый аспект по кирпичикам, посмотрев на инструмент, который добавляет в TypeScript адаптивные приоритеты, арены памяти, каналы, семафоры и много-поточность.

Абсолютные импорты без расширений в ESM-монорепозитории.
Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”.

Разрешаем конфликты настроек без костылей.

Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”.

Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

Задумывались ли вы когда-нибудь о том, что на самом деле происходит под капотом, когда вы рендерите приложение 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, потому что там есть хоть какой-то структурный подход. На практике это оказывается большим заблуждением.