ReactJS *

Копипаста редко выглядит как копипаста. После переименования переменных, строк и чисел два одинаковых блока спокойно проходят ревью как разный код. Я написал clone-alert, чтобы находить такие совпадения в TypeScript, JavaScript и шаблонах Vue, Svelte и Angular.

🇧🇷 🇨🇳 🇮🇳 Локализуем React не трогая код компонентов

React-компоненты из node_modules уже скомпилированы, поэтому внедрить react-i18next в них обычно невозможно без форка библиотеки. В статье показываю, как перехватить все вызовы jsx/jsxs через кастомный react/jsx-runtime и автоматически локализовать текст даже внутри уже собранных компонентов, не меняя их исходный код.

Мы делаем QoyHunter — учётную систему для овцеводческих хозяйств Узбекистана, с витриной животных, доставкой и блогом на соседних поддоменах. С точки зрения бизнес-логики ничего экзотического: CRM как CRM. Экзотика начинается там, где эта CRM встречается с реальностью рынка.

А реальность такая: основной канал пользователей — Telegram, а не браузер; основной язык — не всегда русский (узбекский обязателен, английский — по явному выбору); часовой пояс один (Ташкент, UTC+5, без перехода на летнее время — тоже давало баги, но об этом ниже); а разработка идёт на Windows-ноутбуках без сервера БД под рукой. Из этих фактов вытекает добрая половина решений в статье. Стек: бэкенд на ASP.NET Core (.NET 10), фронт на React + Vite, админка на react-admin, всё за nginx в docker compose.

Это продолжение моей статьи о том, как я сделал движок совместимый с GTA San Andreas для запуска в браузере, рекомендую сначала прочитать:

https://habr.com/ru/articles/1051828/

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

Статья про то, как AI-агенту дали знание о дизайн-системе, чтобы он перестал придумывать несуществующие компоненты и начал верстать из того, что реально есть в проекте.

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

Внутри: Figma MCP, свой DS MCP, React, Jetpack Compose и SwiftUI, поиск по компонентам, ChromaDB, RAG, embeddings, препроцессор для описания дизайн-системы, грабли с чтением файлов, шумом в контексте, устаревающим SKILL.md и честное сравнение подходов по tool calls, токенам и результату.

Заходите, читайте и рассказывайте, как вы решаете эту проблему у себя ❤️

На Хабре вышла хорошая статья «Нужен ли здесь useEffect?»: 12 сценариев из code review, в которых эффект либо не нужен, либо нужен не такой.

Я пишу на $mol и читал её как этнограф. в моле нет API эффектов. Во что превратятся все 12 демо, если их переписать ? Посмотрите ?. Сделал страницу с демками.

Спойлер: чек-лист из 12 строк в конце схлопнулся в …

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Олегом Щёголевым — frontend-разработчиком, преподавателем, ментором и специалистом по Angular автором Telegram-канала «SUMMON_THE_CODER».    

В этом выпуске мы разбираем путь в профессию, реальные проекты, ситуацию на рынке труда, зарплаты, использование нейросетей в разработке, статус GDE, современный Angular, сигналы, SSR, CLI, директивы, модули и главный вопрос: почему React популярнее, но крупные компании всё равно продолжают выбирать Angular.

Красная волнистая линия под строкой раздражает, и самый быстрый способ её убрать — дописать any, as или !. Компилятор замолкает, сборка зеленеет, PR уходит дальше. Вот только ошибка никуда не делась: она переехала из редактора в рантайм, поближе к пользователю.

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

Поэтому на code review я задаю не привычное «как затипизировать, чтобы TypeScript замолчал», а обратный вопрос:

Что именно я здесь отключаю — и правда ли без этого нельзя?

Веду frontend-команду, много времени провожу в чужих диффах, и про any, as и ! у нас постепенно сложился небольшой свод договорённостей для review. Из него и выросла эта статья: 13 сценариев, которые складываются в один короткий фильтр. Для каждого есть пара «плохо → хорошо» и рабочий пример на TypeScript 6 — всё можно потрогать в playground (он написан на React, но сами приёмы относятся к TypeScript в целом). Разберём any и unknown, сужение и type guards, satisfies, as const, оператор ! и валидацию данных на границе.

Главная мысль:

Типы — это проверяемые обещания о данных. any, а также необоснованные as T и !, позволяют компилятору принять такое обещание без доказательства. Если тип неизвестен — это unknown и сужение; если известен, но невиден компилятору — это guard, валидация или контролируемый инвариант, а не слепое утверждение.

Каково назначение хуков useMemo и useCallback? Какие ошибки и лучшие практики следует при их использовании, и почему удаление большинства из них может быть хорошей идеей?

Здесь вы найдете ответы на эти вопросы или можете поделиться своей историей «переоптимизации».

На code review я регулярно встречаю один и тот же вопрос, только записанный разным кодом: «Как правильно синхронизировать эти значения через useEffect?»

Со временем я понял, что чаще полезнее спросить иначе: а эффект здесь вообще нужен?

В статье разбираю 12 типичных сценариев из React-код-ревью: производное состояние, события, цепочки эффектов, внешний store, useEffectEvent, загрузку данных и современные подходы React 19.2. Для каждого случая — пример «плохо → хорошо» и практический фильтр, который помогает выбрать между рендером, обработчиком события, Action, useEffect или query-библиотекой.

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 10 раз, заменив JS-инструменты на нативные.

Вы когда-нибудь бывали в городе Лост-Хэвен? Это город, что никогда не спит. Город, где неоновые вывески офисных зданий отражаются в лужах после дождя, а в тёмном переулке стреляют из автомата «Томпсона». Этим городом правят криминальные семьи, где у каждой свои интересы, и когда эти интересы пересекаются… город погружается в хаос.

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

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

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

С примерами работы на TypeScript, React, Vue и Angular можно ознакомиться на домашней странице проекта Layout Virtual.

Репозиторий с проектом тут.

Хочу анонсировать свой фреймворк Point0. Это первый Bun FullStack фреймворк сопоставимый по функционалу с Next.js и TanStack Start. Однако, имеет кардинально другой DX, ради которого и был создан.

Мне всегда не нравились существующие фреймворки, особенно Next.js и Remix (React Router). Но я думал, что, видимо, по-другому фреймворки просто не получаются, поэтому и не делают. А громоздкость, чужие строгие соглашения, неповоротливость архитектуры, это просто необходимое зло, с которым я должен смириться.

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

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

Привет, Хабр.

Хочу рассказать про наш проект Exam AI — внутреннюю платформу для аттестации и тренировки сотрудников.
Это не “ещё один тестик на 20 вопросов”, а система, где:

За три месяца наш голосовой ИИ-агент успел соврать клиенту про несуществующего администратора, принять всех звонящих за одного человека и месяц выдавать обычный синтез за "клонированный голос". Разбираю, почему это лечится структурой кода, а не промптом — на полностью российском стеке.

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

PrimeTek, бывшая PrimeFaces, запустила PrimeUI — новую лицензионную модель для экосистемы PrimeNG, PrimeReact и PrimeVue. Это подаётся как унификация бренда, но по сути компания собирает свои ключевые продукты под одной коммерческой оболочкой. Раньше они существовали как набор отдельных библиотек, которые монетизировались через дополнительные продукты и сервисы. Теперь вся экосистема превращается в единый лицензируемый актив.

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

В этой статье разберу пять направлений, в которых мы получили измеримый эффект:

1. Type checking — TSCheck vs TSGO

2. Linting — ESLint vs Biome vs Oxlint

3. Bundling — Webpack → Vite → Rsbuild

4. API-контракты — Кодогенерация без AI

5. React-оптимизации — React Compiler в production

DatePicker казался нам небольшой задачей в разработке UI, пока мы не попробовали создать компонент, который будет корректно работать с keyboard navigation, screen reader’ом, управляемым состоянием и реальными проверками доступности.

Нам потребовался DatePicker производственного уровня на React и TypeScript, и сначала очевидный путь казался очень заманчивым: дать AI четкий запрос, получить 80% готового кода, а остальное доработать руками. Подробный разбор этого кейса есть в моей предыдущей статье «Попросили Claude создать WCAG-доступный DatePicker на React и потратили 3 дня на доработки».

Так вот.

Модель может сгенерировать структуру календаря, атрибуты ARIA, базовую keyboard navigation и логику работы с датами.

Затем начинается интеграция: поведение фокуса становится нестабильным; возникают конфликты между обработчиками событий; озвучивание screen reader’ами требует тщательного тестирования; небольшое изменение в логике работы с датами может неожиданно нарушить работу календаря; код выглядит нормально, но компонент пока не является надежным.

В этой статье я сравниваю два способа создания доступного DatePicker'а с помощью AI:

Первый — 80% кода с помощью AI, остальные 20% руками. Второй — системное проектирование с AI-агентом: PRD, декомпозиция задач, правила агента, внешняя верификация, Vitest, Playwright, сборка Vite, проверки типов и строгий цикл, в котором агент не может двигаться дальше, пока не будет пройден текущий шаг.

Дальше все по делу: в чем AI действительно нам помог; где он начал сбиваться с курса; почему одного большого promt'а оказалось недостаточно; как The Verifier изменил процесс и почему основная задача инженера в разработке с использованием AI больше не сводится только к написанию кода, а заключается в контроле над замыслом, архитектурой, контрактами и стоимостью изменений.