ReactJS *

Привет, Хабр. Давайте о больном. У вас 5+ лет опыта, вы уверенно решаете сложные задачи, менторите джунов и знаете свой стек досконально. Вы чувствуете себя сеньором. Но раз за разом на собеседованиях вам либо предлагают позицию Middle+, либо дают оффер с зарплатой, которая явно не дотягивает до сеньорской.

В чем проблема?

Проблема в том, что вы пытаетесь измерить свой уровень одномерной линейкой «знания технологий». А в голове у адекватного нанимающего менеджера — многомерная система координат.

Как бывший рекрутер, я видел десятки таких «матриц компетенций» в разных IT‑компаниях. И сейчас я вскрою этот черный ящик и покажу, по каким на самом деле осям вас оценивают.

Многие начинающие разработчики учат то, что никогда не пригодится на первой работе. В этой статье — 7 навыков, которые junior-фронтендеру можно смело отложить: от юнит-тестов до глубокого погружения в паттерны проектирования.

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

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

Всем привет! Меня зовут Тим и я недавно завершил проект под названием ether-pos цель которого — объяснить, как на самом деле работает система Proof of Stake (PoS, Доказательство доли владения) Ethereum. Если вы еще не видели ее, посмотрите здесь: ether-pos.

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

Привет. Я Дима Рагозин, фронтенд-разработчик в KTS. Эту статью я хочу начать с предыстории.

Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью.

Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом.

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

Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше.

А то:

Сервис-воркер? Напиши вручную.
Кешировать HTML? Сам придумай как.
Синхронизация вкладок? Ну это уже магия, удачи.
Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡

И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first, network-only, костылями из Stack Overflow 2019 года, и потеешь.

Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”.

Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.

Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).

Как избавиться от проп-дриллинга, упростить тестирование и навести порядок в зависимостях React/JS‑приложения? В статье — зачем вообще нужен dependency injection в JavaScript, почему он редко используется и как это меняет @wroud/di. С кодом, примерами и без тяжёлой рефлексии.

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

HTMX и AlpineJS это две JS библиотеки, которые расширяют HTML специальными аттрибутами и позволяют писать фронтенд без SPA фреймворков.

Это альтернативы React/Vue/Angular и иже с ними. Их появление вызвано усталостью от сложной JS экосистемы и тоской по временам, когда задачи решались с помощью PHP и jQuery.

Я всю жизнь писал JSON API и SPA интерфейсы и моему мозгу трудно было переварить, зачем нужны эти библиотеки и как с ними работать. Поэтому я написал эту статью.

Одним из ключевых преимуществ useGeolocation является его простота. Благодаря инкапсуляции сложной логики, необходимой для доступа к геолокации и ее обработки, этот хук обеспечивает чистое и многократно используемое решение. Хук автоматически обрабатывает состояние загрузки, обновляя его при загрузке данных геолокации, и устанавливает состояние ошибки, если в процессе возникают какие-либо проблемы.

Нам поступила задача разработать веб-сервис – интерактивную карту с каталогом проверенных коттеджных поселков. Цель проекта – привлечь целевой трафик на сайт определенного агентства недвижимости, рассказывая о поселках и направляя заинтересованных пользователей к риелторам. При этом, помимо рекламной функции, сервис должен быть полезным и информативным: показать расположение поселков на карте, их характеристики, цены и т.д. Задача осложнялась требованиями SEO – требовалось, чтобы страницы хорошо индексировались поисковиками, несмотря на наличие карты и динамических фильтров. Также важно было обойтись без собственного бэкенда для экономии ресурсов и упрощения инфраструктуры. Ниже я расскажу, какие технологии мы выбрали, с какими трудностями столкнулись и как их решили.

Привет, Хаброжители! Наверняка вы неоднократно сталкивались с ситуацией, когда начинали разработку фронтенд‑приложения на React и вроде всё было очевидно, но через некоторое время чувствовали, что уже запутались, где какой компонент. И в такой ситуации приходится вновь и вновь смотреть код, чтобы вспомнить, где в иерархии находится определенный компонент. Или, например, начинаете создавать компонент и задумываетесь на время: — «А с чего начать и какой должна быть реализация?», а реализовав компонент понимаете, что можно было бы сделать это по‑другому.

Книга «Разработка фронтенд‑приложений» предлагает решения, для подобных ситуаций, а также даст руководство по‑другому подойти к разработке. Совершенно по‑новому!

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

Недавно на проекте столкнулся с необычной задачей - сделать из готового React веб-приложения десктопную версию на Electron. Что же тут необычного? А то, что наше веб-приложение построено на микрофронтенд архитектуре и располагается в трёх отдельных репозиториях. А общение между микрофронтендами происходит в runtime через HTTP. И тут начинаются сложности, так как для создания дистрибутива, Electron'у нужен доступ к исходникам всего приложения. Хотя Electron легко подружить с Webpack, как это сделать с плагином Module Federation на первый взгляд не понятно.

Поиск готового решения в интернете ничего не дал, кроме повисших в воздухе вопросов на Stack Overflow. Пришлось придумать своё решение, которое я и опишу здесь.

Стек проекта типовой (React, Webpack Module Federation, Electron, Electron-forge), поэтому не буду подробно расписывать конфиги, лишь опишу ключевые моменты.

Да, я убрал из заголовка "за выходные", потому что проект чутка растянулся. Но идёт весело! У него и веб-версия теперь есть: https://mini.qyp.ai

Напомню: я давно хотел пощупать Tauri v2, и новомодные фреймворки для построения AI-агентов (ai-sdk / mastra / llamaindex).

Идея простая: десктопное приложение, дешборд на весь экран, справа интерфейс чата. Просим ИИ вывести на дешборд какую-то информацию в духе "сколько новых юзеров за последнюю неделю" - ИИ пишет код виджета, и размещает его на дешборде. Под капотом - runtime компиляция React.js + sql-коннекторы.
Полный open-source, весь код в репозитории: https://github.com/ElKornacio/qyp-mini

Всем, привет, меня зовут Дмитрий, я React-разработчик, и я снова здесь и попробую сегодня рассказать про Web Workers.

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

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

В современном фронтенде отзывчивость интерфейса — требование по умолчанию. Пользователи ожидают, что ваше приложение будет мгновенно реагировать на действия, даже если оно выполняет тяжёлые вычисления или загружает большие объёмы данных.

В этой статье мы разберём, как можно решить эту проблему одним из вариантов — с помощью Web Workers.

Это вторая статья из цикла про наш фреймворк Steroids, в которой мы расскажем об архитектурном подходе к построению UI-компонентов. Если вы ещё не читали первую статью — начните с неё. В ней мы объясняем, что такое Steroids и какие задачи он решает.

Создание фронтенда для Web3-приложений — это не только дизайн, кнопки и React. Это мост между пользователем и блокчейном. И ты, как фронтенд‑разработчик — тот, кто этот мост может построить...

Представьте дизайн-агентство, которое создает не просто красивые макеты, а целые технологические экосистемы. Один раз вложившись в разработку уникальных компонентов и фирменного стиля, дизайнеры получают возможность генерировать профессиональные сайты со скоростью 50+ проектов в час.

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

Или используйте полную автоматизацию так же как в v0, но с прицелом под крупные корпоративные интеграции.

В статье рассматривается библиотека @qtpy/state-management-observable и её React-обёртка @qtpy/state-management-react, объединяющая реактивность, строгую типизацию и удобный API. Если вы ищете альтернативу Redux, Zustand или Valtio с поддержкой undo/redo, granular-подписок, middleware, асинхронных обновлений и прозрачной работы с массивами через Proxy — createObservableStore может стать хорошим выбором.