ReactJS *

Всем привет! Меня зовут Артем, я фронтенд разработчик в Банки.ру. Недавно перед нашей командой встала задача внедрить SSO-аутентификацию через Keycloak для клиентских сервисов. Помимо базовой настройки важно было полностью переработать стандартные формы входа, чтобы они соответствовали корпоративному стилю и UX-требованиям.

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

Представь, что ты строишь крутой интерактивный сайт из деталек LEGO. React — это как раз такой продвинутый набор «умных» деталек для постройки сайтов. А эта книга — инструкция к нему.

В данной статье рассказывается о личном опыте переезда с JS на TS, как у меня получилось подружить Node.JS с TypeScript без сторонних инструментов.

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

Недавно мы с командой работали с клиентом из финансового сектора: у него есть сайт и личный кабинет, давно написанные на PHP (бэк и фронт), и задача — обновить дизайн и пользовательский опыт без глобальных изменений «под капотом».

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

В данной статье будет предоставлена детальная информация по реализации высокопроизводительного вьюпорта мессенджера на Angular, который обеспечит высокую и плавную скорость работы и низкое потребление ресурсов с применением инструмента виртуализированных списков ng-virtual-list. А также представлен порт на React.

Всем привет! Меня зовут Александр Битько, я фронтенд-разработчик в ПСБ. Сегодня поговорим об одной из частых болей в работе с микрофронтенд-архитектурой — поиске баланса между независимостью микрофронтов и согласованным UI. Когда независимые микрофронты используют разные подходы к стилям (CSS-фреймворки, методологии вроде BEM или CSS-in-JS, глобальные стили), возникают конфликты с визуальной несогласованностью в приложении. Красная кнопка вдруг становится зелёной, шрифты начинают прыгать и так далее. 

Что с этим делать? В этой статье я расскажу о конфликтах стилей: какими они бывают, как с ними бороться и какие стратегии лучше подходят для приложений в разных случаях. И приведу примеры, как это работает на Angular и на React с использованием наиболее популярных библиотек Angular Matherial и MUI. Поехали.

Сегодня поговорим про реализации решения конфликтов подходов local / offline-first – это когда ваше приложение позволяет пользователям работать полностью или частично оффлайн, а когда они выходят в сеть, синхронизировать все их изменения.

Примеры таких приложений: Notion-like редакторы, Figma-like вайтборды или Linear-like таск менеджеры.

Основная идея – коллаборация, а коллаборация несет за собой конфликты, разберем очень наглядный пример:

Когда я начал разбираться с Motion для React, то оказалось, что свежих обзорных статей почти нет — нашёл только несколько старых постов про framer-motion. Поэтому я решил написать свой обзор: перевёл и разобрал документацию (ссылки в конце), попробовал библиотеку в деле и собрал всё в одном месте.

В статье есть примеры кода, GIF-анимации и описание хуков, которых, по моему личному мнению, достаточно, чтобы понять Motion, и, возможно, попробовать его руками, сэкономив время на чтении документации.

Push-уведомления в вебе без Firebase, OneSignal и прочих посредников - только штатные браузерные API: Service Worker, Push API, VAPID и Notifications API. На десктопе и Android пуши работают в обычной вкладке, PWA-обвязка нужна ради iOS 16.4+.

В статье:

• как устроена вся цепочка и почему именно так

• готовый код Service Worker и клиентской части

• сервер на Express с отправкой и чисткой мёртвых подписок

• PWA-манифест и специфика iOS

• детекция платформы и подсказка об установке

• грабли, из-за которых «не работает» - event.waitUntil, тихие пуши, протухшие подписки

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

Давайте честно. Есть один этап в IT-найме, от которого у любого Senior-разработчика начинает дергаться глаз. Это технический скрининг с HR-ом.

Вы специалист с 10-летним опытом. А напротив вас сидит 23-летняя девушка, которая по бумажке задает вам вопросы, ответы на которые она сама не понимает. «А чем отличается SQL от NoSQL?», «Расскажите про SOLID».

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

Но что, если я скажу вам, что ваша злость и попытки «доказать, что вы умный» это именно то, из-за чего вы проваливаете этот этап?

Как бывший рекрутер, я сейчас вскрою этот театр абсурда и покажу, что на самом деле происходит в голове у HR-а, и как нужно действовать, чтобы пройти этот фильтр с конверсией 90%.

На выходных вышли сразу две громкие ИИ-новости, которые захотелось пощупать руками.

Во-первых, на OpenRouter тихо появились две стелс-модели: Sonoma Dusk Alpha и Sky Alpha. Обе заявлены с окном контекста 2 млн токенов, поддержкой изображений на входе и параллельным вызовом инструментов, и сейчас бесплатны; Dusk заявляется как быстрая модель на каждый день, Sky - как максимально интеллектуальная для сложных задач.

Во-вторых, z.ai запустили API совместимый с Claude Code с доступом к своей флагманской модели GLM-4.5 по за $3/мес (план GLM Coding Lite) — с лимитом ~120 промтов на каждые 5 часов. Есть и Pro за $15/мес (~600 промтов/5 ч). Эти планы работают только внутри инструментов кодинга вроде Claude Code (в веб-чате их не включают).

Ну как не потестить? Потестим.

По мере роста фронтенд-приложений управление пользовательскими взаимодействиями становится все более важным. Добавление обработчика событий на каждый интерактивный элемент — плохая практика: это усложняет код, увеличивает расход памяти и снижает производительность. Здесь на помощь приходит делегирование событий (event delegation).

Каждая интерактивная веб-страница опирается на Document Object Model (DOM) и ее систему событий. Когда мы нажимаем кнопку, вводим текст в поле или наводим курсор на изображение, возникает событие. Но оно не происходит само по себе — событие проходит по дереву DOM в процессе, который называется распространением события (event propagation).

Показать данные красиво и понятно бывает сложнее, чем написать саму бизнес-логику. Нужно не просто вывести цифры, а сделать так, чтобы ими было удобно пользоваться: масштабировать, сравнивать, фильтровать. Можно ли совместить мощь, интерактивность и гибкость в одной библиотеке визуализации — и при этом без боли интегрировать ее в React? Спойлер: да, и это ECharts.

Привет, Хабр! Меня зовут Ольга Китова, я разработчик в IBS. Эта статья — про ECharts, один из самых сильных и гибких инструментов для визуализации данных. Я покажу, какие возможности дает эта библиотека, как она устроена «под капотом», в чем ее плюсы и минусы и как использовать ECharts в React-приложениях, на практике.

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

Давайте вспомним как мы строим роутинг в наших приложениях. В примере ниже – react-router-dom, но в других фреймворках/библиотеках все примерно также:

Рассуждаю о проблеме регулярного создания файлов и о том, как поддержать архитектуру и автоматизировать рутину.

Написал утилиту на Go для генерации структур файлов по шаблонам, которая, думаю, будет полезна многим.

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

Сегодня хотелось бы поговорить с вами о такой теме как Легаси.

Давайте дадим определение, что такое легаси.

Легаси - это тот код, который писали до нас и который пришел нам от других.

Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.

Почти любой проект со временем превращается в легаси, если его не обновлять.

На своем опыте разработки я могу классифицировать легаси на три категории. Опять же я не претендую на абсолютную объективность. Это только моя классификация, на основе того, с чем лично я столкнулся.

1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример  проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.

2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке. 

Одним из ключевых преимуществ этого пользовательского хука является его простота. Вы можете использовать его для хранения данных любого типа, таких как строки, числа или даже сложные объекты, всего с помощью нескольких строк кода. Кроме того, useStorage выполняет сериализацию и десериализацию данных за вас, поэтому вам не нужно беспокоиться о преобразовании значений в JSON и из него.

Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался.

Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.