ReactJS *

Несомненно, появление концепции лайка открыло новую страницу в механизме feedback. Не только для крупных компаний, но и для мелких девчушек, которые гоняются за лайками от своих сверстников. Однако, в какой‑то момент времени, лайки стали тормозить развитие механизмов получения того самого feedback. Зачем что‑то выдумывать новое, если уже есть лайк, понятный даже макаке‑резус и регулярно повсеместно используемый? Концепция лайков противоречит количественной социологии? Да ну ее на фиг, эту социологию! Одним лайком сложно получить качественный feedback? Зато лайк это уже традиция — так еще наши прадеды делали, деды, отцы делали, и мы делать будем, и наши дети и правнуки, ну Вы поняли. В данной статье не только делается попытка поиска следующего за лайком механизма feedback. Но и приводится вместе с исходным кодом действующий компонент на React TypeScript. Если кому интересна тема поиска новых механизмов feedback, добро пожаловать под кат!

Важность надежной обработки запросов в оффлайн-режиме невозможно переоценить, особенно для приложений, которые должны функционировать и в отсутствии интернет-соединения. Workbox - это мощный инструмент для управления Service Worker в браузерах, он как раз призван решать подобную задачу при помощи соответствующего плагина, но поддержка Background Sync API не универсальна. В этой статье я покажу, как расширить Workbox, чтобы Background Sync корректно работал даже на платформе iOS/Safari.

Работая над продуктом для «внешнего» пользователя, разработчик интерфейсов может столкнуться с необходимостью использовать серверный рендеринг. Поисковые системы по прежнему остаются значительным источником трафика почти для любого сайта, контент на котором не будет проиндексирован, если сервер его не отдаст. Кроме того, «приготовленный» определенным образом, серверный рендеринг может положительно сказаться на всех основных метриках производительности проекта, существенно ускорив загрузку страниц. В то же время, эта технология накладывает определенные ограничения, с которыми необходимо считаться и повышает требования к экспертизе разработчика. В статье будут предметно разобраны подводные камни, с которыми можно столкнуться при разработке платформы, использующей отрисовку HTML в Node.js окружении, и даны практические рекомендации, как их избежать.

На конференции React прошлым летом команда объявила, что Remix «уходит в спячку».

К тому моменту Remix v2 стал настолько тонкой обёрткой над React Router, что между проектами возникло искусственное разделение. Чтобы упростить архитектуру фреймворка, команда перенесла код сборщика и серверного рантайма из Remix непосредственно в React Router v7, объединив всё лучшее из фреймворка в так называемый “framework mode” для роутера. Также было объявлено о планах добавить ограниченную поддержку React Server Components (RSC) в React Router.

Эта работа была завершена: версия 7 была выпущена в ноябре прошлого года, а в конце мая была представлена предварительная поддержка RSC. Теперь разработчики, использовавшие Remix v1, v2 или более ранние версии React Router, могут рассчитывать на стабильную платформу с долгосрочной поддержкой.

Теперь же, пришло время заняться Remix!

Еще в бытность джунни, я наткнулся на милейшую интерактивную обучалку по селекторам CSS: CSS Diner. Кто не знает — обязательно посмотрите, эстетический кайф гарантирован. Прошел ее минут за 15 на одном дыхании и подумал: а почему бы не сделать что‑то подобное с аналогичной механикой «допиши правильное слово в пропуск в бойлерплейте», только по другой теме? Сходу на ум ничего не пришло, но идею я запомнил.

Три года спустя я решил изучить React, написав на нем какой‑нибудь пет‑проект (имхо, лучший способ изучить новую технологию/язык). Тут‑то я и вспомнил про CSS Diner. Осталось только найти подходящую тему, где эта механика бы зашла.

В этом материале познакомимся с таким пакетом как Webpack Bundle Analyzer, который позволяет наглядно увидеть из каких частей состоит проект. В качестве тестового проекта использована сборка на базе Next.js 15-й версии с app router.

В апреле я съездил на HolyJS. Еще до поездки в расписании конференции моё внимание привлек доклад Виктора Хомякова «Удаление мертвого кода в проекте: практическое руководство». Послушав его, я понял, что могу использовать полученные знания в своем текущем проекте, при этом не затрачивая много усилий. В этой статье я расскажу, что у меня получилось.

Привет, с вами снова я – Дмитрий, React-разработчик, хотелось бы сегодня затронуть тему среды выполнения JS. Многие знают, другие уже подзабыли, а новички — вовсе не в курсе. В общем, эта статья точно найдёт своих читателей. Постараюсь простыми словами и по делу.

Введение в любой фреймвок начинается с написания одного простого компонента. Чаще всего этим компонентом будет "счетчик нажатий". Это своеобразный "hello world" в мире фронтенд разработки. Именно поэтому я и возьму его за основу данного материала.

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

Сегодня мы рады представить вам документацию по двум новым экспериментальным возможностям, уже доступным для тестирования:

• View Transitions (переходы между экранами)
• Activity

А также делимся обновлениями по возможностям, над которыми продолжаем работать:

• Треки производительности React (React performance tracks)
• Расширение редактора кода для компилятора
• Автоматические зависимости эффектов
• Ссылки на фрагменты (fragment refs)
• Конкурентные хранилища данных (concurrent stores)

Пример использования View Transitions и Activity в клоне AirBnB

Грандиозная история вокруг микро open-source проекта который неожиданно выстрелил и вытащил меня из ямы

Асинхронность в JavaScript, где и как использовать в web разработке на frontend и backend. Цепочка промисов и их параллельные выполнение.

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

При разработке фронтенда мы часто ограничиваемся тремя состояниями UI-запроса: loading, error, data (или success). Но это не всегда достаточно — особенно когда дело доходит до тонких UX-деталей, предотвращения гонок запросов и адекватного управления отменой при размонтировании компонентов. В статье рассмотрим, почему добавление состояния idle делает систему более надёжной, как реализовать конечный автомат для управления статусами, как отменять fetch-запросы и оптимизировать перерисовки.

🚀 Устал каждый раз руками создавать Component.tsx, index.ts, styles.module.scss и всё по кругу?

Решение есть! Простой и кастомизируемый CLI-инструмент для Vite, который генерирует компоненты — из шаблонов, которые ты сам задаешь.

В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов. 

Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.

Если вы недовольны текущими решениями для организации библиотек компонентов или просто любите технические кейсы — добро пожаловать под кат!

На одном из проектов мне нужно было реализовать Telegram-бота с использованием Web App. Я выбрал стек: Vite + React + Zustand + TypeScript. До этого я в основном работал с Webpack, и столкнулся с вопросом — как удобно организовать алиасы. В Vite есть resolve.alias, и это удобно. Но дополнительно нужно прописывать пути в tsconfig.json, чтобы IDE понимала, что происходит. А ещё это не работает с HTML-импортами.

💡 Здесь важно: HTML теперь может импортировать модули напрямую, и если бы алиасы работали и там — можно было бы писать одни и те же пути и в скриптах, и в коде, и в конфиге.

Когда мы решили вывести на прод Telegram‑мини‑приложение для «капельных» (drip) TON‑платежей, довольно быстро стало ясно: обычный CRUD‑фронт тут не выживет. Сразу накрыла волна специфичных задач — от гранулярного онбординга в Web‑App до борьбы с ограничениями API‑ключей и тонкостей работы с TON SDK во встроенном браузере Telegram. Каждый шаг требовал не только кода, но и аккуратного выбора архитектурных приёмов, иначе продукту грозили дубли запросов, «белые экраны» и несогласованность состояний.

В этой статье я разобрал пятнадцать самых характерных «боевых» сложностей, показал, каким паттерном мы их укрощали, и какой антипаттерн поджидал за поворотом. Это не академический список, а выжимка из коммитов и ночных дебаг‑сессий, которая поможет тем, кто строит похожие интеграции между Telegram, TON и React.

Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.

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

Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.

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

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

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