ReactJS *

Я продуктовый дизайнер, больше шести лет делаю SaaS. Программировать умею, но фулстек-разработчиком себя не назову. Уже несколько месяцев я в одиночку делаю Котомку, планировщик жизни по методу PARA: сферы, проекты, задачи, календарь, привычки, финансы. Есть веб, мобильная версия, синхронизация между устройствами и с Google и Apple календарями. Почти весь код пишет Claude Code. Я ставлю задачи, проверяю результат и принимаю решения.

Этой осенью сын пошёл в пятый класс, и я заметил странную вещь: со смартфоном он на «ты», а за обычной клавиатурой теряется. Мы попробовали несколько тренажёров слепой печати, но ему быстро стало скучно — и я решил сделать свой.

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

Хочу посвятить эту статью погружению в разные возможности обновления данных в JS и React, раскрыв это на примере своей библиотеки "nexus-state". Поделюсь подробными примерами, мотивацией и расскажу, для чего вообще нужны стейт-менеджеры и как они работают. При написании примеров я постараюсь максимально просто объяснить суть и не буду затрагивать тему типизации.

В большинстве SPA-авторизация до сих пор строится вокруг JWT, localStorage и заголовка Authorization. Такой подход прост и удобен, но он заставляет клиентское приложение самостоятельно управлять credential и пользовательской сессией.

В этой статье разберём, что меняется при переходе на HttpOnly Cookie и серверные сессии: как браузер хранит и отправляет Cookie, зачем нужны HttpOnly, Secure, SameSite, Domain и Path, и почему вместе с Cookie приходится по-новому смотреть на CSRF и CORS.

Отдельно разберём разницу между JWT и session ID внутри Cookie, а в практической части посмотрим, как такая архитектура меняет React-приложение с Axios и MobX.

Всем привет, это третья часть, в которой пилю калькулятор плитки - tilely.ru. Получился довольно крупный патч, в основном вокруг 3D-режима, и там оказалось прилично багов. Многое пришлось переделывать из того, что сначала казалось логичным, а на практике оказалось вообще неудобным.

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

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

При этом ради оптимизация не всегда правильно использовать useMemo и React.memo. Такой подход даже ухудшить ситуацию, если реализовывать его без понимания причины проблемы.

Полгода назад я в одиночку начал делать Nookly — локальное приложение для заметок на Flutter: страницы, блочный редактор, таблицы с канбан-видом, полнотекстовый поиск. Ключевое требование с самого начала: всё работает офлайн, данные не покидают устройство. В этом посте — не про сам продукт, а про два инженерных решения, которые могут быть полезны: как спроектировать схему БД так, чтобы синхронизация потом не потребовала переписывания половины кода, и как собрать лендинг вообще без шага сборки.

Разбираю несколько инженерных решений из небольшого браузерного проекта: бинго на шахматных задачах Lichess без собственного сервера. Как получить одну и ту же карточку у всех игроков в один день с помощью детерминированного сида, почему запись из пула данных нельзя удалять (флаг retired), как записать правило «одна партия в день» частичными уникальными индексами и почему политик RLS в Supabase недостаточно: по умолчанию клиентским ролям выданы права, в том числе TRUNCATE, который RLS не проверяет.

Хочу рассказать о своей npm‑библиотеке — это мой второй и самый сложный npm‑проект на момент написания статьи.
Библиотека решает ряд проблем и ограничений связанных с дефолтным поведением браузерного элемента скролл.

Глубоко в код погружаться не буду — поделюсь историей создания и мотивацией.✨

React 19.3 уже доступен в npm!

В прошлом году мы представили View Transitions и Fragment Refs как новые экспериментальные API, которые готовились к появлению в React. Теперь оба API получили стабильный статус в React 19.3.

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

Внешний API возвращает данные в своей модели. Названия полей, вложенные объекты, изображения, цены и правила пагинации принадлежат provider. UI приложения обычно работает с другой моделью. Если компонент читает event._embedded.venues[0].city.name напрямую, структура внешнего ответа распространяется по интерфейсу. Изменение API затрагивает карточки, detail page, search, metadata и тесты.

В App Router внешний запрос можно выполнять на сервере. Server Components работают с fetch, а серверный код не попадает в клиентский bundle. API key при такой схеме остаётся вне браузера. Документация Next.js описывает server-side data fetching для App Router. В учебном проекте EventMap внешний источник событий проходит через server API слой.

На примере маркетплейса разберём, как разделить приложение на feature-модули, связать сервисы через DI, организовать состояние и изолировать работу с браузерными API.

React давно перестал быть просто библиотекой для отрисовки интерфейсов. Вокруг него выросла огромная экосистема, а сама работа фронтенд-разработчика меняется под влиянием ИИ быстрее, чем успевают обновляться привычные roadmap. Нужно ли сегодня глубоко знать JavaScript, стоит ли учить Next.js «по умолчанию», чем React выигрывает у Angular, что не так с вайб-кодингом и останется ли вообще ручное написание кода через пять лет?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Ломковым — фронтенд-разработчиком и автором YouTube-канала «Friendly Frontend». Обсудили рынок найма, переход из VK в Wildberries, нейросети в реальной разработке, React и его экосистему, серверный рендеринг и то, какие навыки становятся важнее самого умения писать код.  

Короткая версия: за несколько месяцев на одной домашней видеокарте у крымскотатарского языка появились работающее распознавание речи (WER 0.3463 → 0.1701) и синтез, который прочитал вслух целую книгу — шестнадцать глав, 1 час 58 минут звучания. На обучение моделей из этого ушли часы. Всё остальное время съели данные, проверки и выяснение того, какие из моих собственных измерений врут.

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

Сразу оговорка про то, чего в статье не будет: конкретных источников аудио, договорённостей с правообладателями, точных рецептов пайплайна и внутренних скриптов. Будут метрики, порядки величин, методология проверки и грабли. Грабель много.

Каждые несколько лет (а сейчас уже и чаще) разработчиков снова хоронят.

Сначала нас должны были заменить визуальные конструкторы. Потом no-code. Потом low-code. Потом автогенерация CRUD. Потом Copilot. Теперь, кажется, пришёл финальный босс в виде больших языковых моделей, которые за вечер могут накидать backend, frontend, Docker Compose, миграции, OpenAPI, Kafka, PostgreSQL, Redis, авторизацию, тесты, README и компилятор на сдачу.

А если открыть любую соцсет, то везде: «Я сделал SaaS за 20 минут», «нейросеть написала мне приложение», «один промпт заменил команду разработки»…Всё выглядит так, будто профессии действительно место в музее рядом с перфокартами и дискетами, так как теперь обычный пользователь интернета может навайбить энтерпрайз ПО, банковское мобильное приложение и агрегатор такси. И всё это только за утро. 

Но чем больше я работаю с ИИ-инструментами, тем меньше верю в исчезновение разработчиков. Но не потому что ИИ тупой. Как раз наоборот — ИИ сейчас хорошо пишет код. Но чтобы не рассуждать о теме абстрактно, расскажу одну показательную историю. Специально возьму самый скромный масштаб из возможного: без бэкенда, без Kafka и восьми сервисов. Один фронтенд. Если совсем честно,то это будет один экран поиска. Там всё и увидим.

Многие аналитические платформы сталкивается с одним и тем же вопросом: как связать компоненты, которые изначально не знают друг о друге? График живёт по одним правилам, карта — по вторым, таблица — по третьим. Каждый движок говорит на собственном языке событий и данных, и заставить их работать слаженно — нетривиальная архитектурная задача. В этой статье рассказываем, как мы её решаем в Modus.

Мы сделали свой UI Kit: 6 компонентов превратились в 30+, а одна ошибка сломала разметку во всех проектах

С чего всё начиналось

Когда в проекте начинает появляться всё больше одинаковых элементов интерфейса, рано или поздно возникает вопрос: зачем каждый раз создавать один и тот же Button, Input или Select?

Мы рассматривали готовые решения, в том числе Ant Design и Material UI, но они не закрывали наши требования. Нам требовался больший контроль над внешним видом и поведением компонентов, возможность детально адаптировать их под наши задачи и учитывать требования проекта к безопасности.

В Next.js изображения, metadata и production build находятся в разных частях проекта. next/image занимается загрузкой и геометрией изображений. Metadata API формирует <title>, description, Open Graph и Twitter metadata. next build собирает production-версию приложения. Ошибки в этих местах часто не мешают работе next dev. Страница открывается, локальная картинка показывается, title есть. На другом домене внешний Image получает запрещённый URL, Open Graph содержит localhost, production build падает на конфигурации или импорте. Разберём эти три части отдельно на примере проекта Goods Finder.

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

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

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

Поэтому я поставил эксперимент с одной фронтенд-задачей, одной моделью и четырьмя одинаковыми копиями проекта. В первом случае оставил агента без подсказок, во втором дал ему скилл с правилами проекта, в третьем подключил MCP с документацией дизайн-системы, а в четвертом совместил всё сразу. Мне хотелось узнать, какая комбинация превратит генерацию кода в эликсир скорости, а какая породит еще одно чудовище, не способное пережить встречу с typecheck и build.