ReactJS *

Когда продукт должен работать и на телефоне, и на планшете, и на ПК, и на маке, путей два. Первый по учебнику: нативка под iOS, нативка под Android, отдельный веб под десктоп, и дальше живёшь с тремя кодовыми базами, тремя релизными циклами и модерацией в сторах. Второй: одно сайт-приложение (SPA плюс PWA), которое ставится на домашний экран и работает везде одинаково.

В своём проекте, агрегаторе нейросетей, я сознательно выбрал второй путь. Дальше разберу на этом примере, почему так, что выиграл, что честно потерял, и три грабли из прода, которые этот выбор подсветил. С кодом.

Разбираю, почему нативного EventSource часто недостаточно для production SSE: авторизация через headers, контролируемый reconnect, backoff, race conditions, stale-stream watchdog и синхронизация нескольких вкладок через Web Locks + BroadcastChannel.

На базе этих проблем я вынес real-time слой из AI SaaS-продукта в open-source библиотеку sse-runtime и заменил ей самописную инфраструктуру: −3 455 строк кода в production PR, один useSSE-хук вместо ручного reconnect, leader election и отладочного boilerplate.

Представьте ситуацию: вы открываете какой-нибудь файл в проекте, которому уже года три (чаще всего это форма). И в голове всплывает мысль:  «А что тут вообще происходит?». Причём не в смысле «кто виноват», а в смысле «как мы вообще сюда пришли?».

Я фронтенд-разработчица, и за шесть лет в разработке такое случалось почти на каждом проекте, где мне удалось побывать. Я хочу сразу оговориться: это не статья из серии «как надо жить». Это скорее разговор по типу «смотрите, как все мы иногда делаем и даже не замечаем».

Здравствуйте, товарищи! Эта статья про state management во фронтенде, с непривычного угла. За два года я ни разу не написал ни одного редьюсера. Расскажу, как я к этому пришёл, что слышу со стороны про сторы, и почему вам, особенно если вы только заходите во фронтенд, не надо учить Redux в принципе.

Сначала немного о себе, потом про то, что такое стор и почему я считаю его антипаттерном. Затем покажу, как без него живёт моё реальное приложение. И разберем возражения

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

Меня зовут Сергей Волков, я фронтенд-разработчик в компании VK. Мы используем MobX для работы с реактивными значениями в веб-приложениях, поэтому я хочу познакомить вас с этим инструментом и показать, почему на него стоит обратить внимание.

В этой статье я хочу поделиться своими мыслями о MobX - инструменте, который я искренне полюбил после многих лет разработки интерфейсов. Приятного чтения! :)

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

Мы в стартапе ArcFront три недели двигались в совершенно неправильном направлении, пытаясь подружить современный React с 20-летним Redmine через сложный BFF-прокси. Рассказываем историю нашего провала, неожиданного архитектурного озарения и того, как мы выкинули две недели работы и заменили их 15 строками кода.

Привет, Хабр! Меня зовут Константин Шкурко, я ведущий разработчик мобильных приложений в РСХБ. Сегодня хочу рассказать историю о том, как всем известные обстоятельства заставили нас в сжатые сроки искать альтернат­ивные пути доставки нашего инвестиционного приложения «Свои инвестиции» пользователям iOS - и как это изменило наш технологический стек.

Когда Apple заблокировала российские банковские приложения в App Store, перед нами встала непростая задача. У нас были десятки тысяч активных пользователей на iOS, которые пользовались брокерским приложением для управления своими инвестициями. Торговля акциями, облигациями, аналитика портфеля, выставление заявок - всё это внезапно стало недоступно для значительной части клиентской базы.

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

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

Перед любой командой со стороны менеджмента и бизнеса стоит одна и та же задача «давайте быстрее — надо было еще вчера». Нас эта судьба также не миновала. Первое, с чего начинается оптимизация, своя дизайн‑система. У нас уже была своя дизайн‑система, она выручала нас во многих кейсах, но она была старая, подходы к разработке давно изменились, и UI Kit уже не отвечал требованиям. Поэтому было принято решение параллельно разрабатывать новую, с учетом всех последних требований и подходов.

Переезд не должен доставлять проблем и быть плавным. План такой: разрабатываем новый компонент, тестируем его, и как только результат радует, старый удаляем и внедряем новый. И так до тех пор, пока не останется ни одного старого компонента.

Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»

Начинаем

Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.

Структура получится такая:

В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.

Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат.

На маленьком экране это работает. Но дальше почти всегда начинаются одинаковые проблемы. Интерфейс начинает зависеть от чужой структуры ответа. Ошибки приходят в форме, которую неудобно показывать пользователю. Параметры запроса приходится валидировать в UI. Потом появляется базовый URL, который не хочется держать строкой в коде. Затем появляется ключ или другой секрет, который уже нельзя светить в браузере. В этот момент становится видно, что между UI и внешним API не хватает серверной границы.

В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app, по смыслу заменяют старые API Routes из pages и поддерживают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. (Next.js)

Смысл Route Handlers в том, что они позволяют собрать внутренний серверный контур прямо внутри приложения. Через него можно проксировать внешний API, нормализовать ответ под нужды UI, спрятать env-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.

У вас один SSG-лендинг, а платный трафик льётся из 12 кампаний под разные боли ЦА. Все ведут на дефолтный hero — конверсия в заявку проседает на 30–50%. Делать 12 лендингов дорого и убивает SEO, подменять hero на клиенте — FOUC и дефолт для поисковых ботов.

Рабочая схема, поставленная в продакшен за день: edge-функция Cloudflare Pages переписывает HTML на лету через HTMLRewriter, SSG остаётся источником истины, client-side React дублирует логику при гидратации. 200 строк кода, латенси без изменений (HTMLRewriter работает потоком), Lighthouse не страдает. Разбираю код, нюансы интеграции с vite-react-ssg и грабли из прода.

Мы были двумя 16-летними студентами колледжа, чья программа безнадёжно отставала от индустрии. Пока на парах проходили технологии пятилетней давности, реальный мир уже жил в экосистеме React, Next.js и WebAssembly. Пришлось учиться самим — по вечерам разбирая современный стек и споря об архитектуре. Эта тяга сподвигла нас создавать не абстрактные проекты для портфолио, а реально полезные инструменты, которыми хочется пользоваться каждый день.

Так четыре года назад родился наш проект — 167 утилит и 8 интерактивных песочниц в одном сервисе. Форматтеры, конвертеры, генераторы паролей и UUID, DevOps-конфиги, шпаргалки и песочницы для Python, SQL и Bash. Всё сделали прямо в браузере, без сервера.

Рассказываем как это было.

Каждый раз, когда я хотел поправить отступ или цвет в процессе разработки, я делал одно и то же:

открыл DevTools → нашёл элемент → поменял значение → понравилось → скопировал → переключился в редактор → нашёл файл → вставил.

Это семь шагов ради однострочного изменения. Я сделал LiveStyleSync, чтобы это был один шаг.

История о том, как один странный git push оказался началом расследования, которое вывело меня не на один взломанный аккаунт, а на цепочку зараженных репозиториев и проектов.

Снаружи все выглядело почти нормально: знакомый автор, знакомый коммит, привычные файлы. Но внутри последнего коммита уже жил чужой обфусцированный JavaScript. Он прятался в конфиге, менял Git-историю и маскировался под обычную работу разработчика.

Первой версией был взлом моего GitHub, но смена ключей и паролей ничего не решила.

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

Это оказалась PolinRider-like supply chain атака, которая использует сам developer workflow как транспорт.

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

Показываю реальные скриншоты, подозрительные изменения в .gitignore и payload внутри babel.config.js.

В конце оставил скрипты, которые могут помочь быстро проверить свои проекты и логи на PolinRider похожие признаки.

Началось всё банально. Зашёл коллега, говорит: «Где у нас хлебные крошки в шапке лежат?». Проект — около 150 компонентов, всё именуется по-своему, структура папок местами загадочная. Я начал тыкать в React DevTools, искать по тексту «Breadcrumb» в файлах… В общем, минут через пять нашёл. Это в очередной раз раздражало.

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

В России сейчас активно продвигают мессенджер MAX как официальную альтернативу Telegram. Для пользователей это значит еще один клиент на рабочем столе, а для разработчиков — ещё одна платформа для ботов и мини‑приложений.

На бумаге это звучит норм: единая платформа, интеграция с госсервисами, мини‑аппы для бизнеса (привет, WeChat). На практике возникает базовый вопрос: как это вообще разрабатывать и отлаживать, если в десктопном клиенте нет нормальных DevTools?

В этой статье я попробую рассказать, как выглядит попоболь отладка мини‑приложений в MAX сегодня, чем она отличается от привычного процесса в Telegram (да да, опять сравнение с вездесущей телегой), и почему отсутствие инструментов разработки — не мелкая придирка, а системная проблема.

Я аквариумист. Однажды мне надоело гуглить совместимость рыб в десяти вкладках и записывать параметры воды в блокнот. За два месяца это вылилось в платформу с маркетплейсом, аукционами, AI-диагностикой и 93 таблицами в PostgreSQL. Рассказываю, что получилось, на чём построено и

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

В большинстве компаний линтинг со временем превращается в хаос: разные правила ESLint, устаревшие конфиги и копипаста между проектами.

Покажу, как навести порядок – собрать линт-инфраструктуру в один пакет и выстроить систему контроля кода для всех репозиториев.