ReactJS *

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

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