В апреле я съездил на HolyJS. Еще до поездки в расписании конференции моё внимание привлек доклад Виктора Хомякова «Удаление мертвого кода в проекте: практическое руководство». Послушав его, я понял, что могу использовать полученные знания в своем текущем проекте, при этом не затрачивая много усилий. В этой статье я расскажу, что у меня получилось.
Привет, с вами снова я – Дмитрий, React-разработчик, хотелось бы сегодня затронуть тему среды выполнения JS. Многие знают, другие уже подзабыли, а новички — вовсе не в курсе. В общем, эта статья точно найдёт своих читателей. Постараюсь простыми словами и по делу.
Введение в любой фреймвок начинается с написания одного простого компонента. Чаще всего этим компонентом будет "счетчик нажатий". Это своеобразный "hello world" в мире фронтенд разработки. Именно поэтому я и возьму его за основу данного материала.
В блоге React Labs мы делимся проектами, находящимися на этапе активных исследований и разработки. В этой статье рассказываем о двух новых экспериментальных возможностях, которые уже доступны для тестирования, а также делимся новостями о других вещах, над которыми сейчас работаем.
Сегодня мы рады представить вам документацию по двум новым экспериментальным возможностям, уже доступным для тестирования:
View Transitions (переходы между экранами)ActivityА также делимся обновлениями по возможностям, над которыми продолжаем работать:
Пример использования 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-компонентов! Эта статья о создании шаблонов для автоматизации рутинных задач: генерация папок, файлов, управление экспортами. Экономьте время и фокусируйтесь на главном.
Фронтендеры, постоянно в поиске идеальной архитектуры. Слои, фича-слайсы, атомарный дизайн, фрактальность... Все эти подходы имеют право на жизнь. Но сегодня я хочу поделиться способом мышления, который сделает любой ваш код лучше, а любую архитектуру – яснее.
Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.
Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.
Всем привет! Меня зовут Иван Кузнецов, я руковожу группой «Дизайн и клиентский сервис» в ИТ-команде «Северстали» Если в первой части мы поделились предпосылками, целями и общим видением будущей системы, то сейчас настало время заглянуть «под капот» и рассказать о том, как мы воплотили эти идеи в жизнь. Здесь подробно обсудим архитектурный подход, ключевые принципы построения системы, а также познакомим вас с важнейшим её аспектом – токенной системой, которая обеспечивает единообразие и адаптивность продуктов построенных на её базе.
Самое популярное приложение после Hello World на react - это личный планировщик задач Todo и мы не будем сильно оригинальничать и напишем его с нуля на react и разместим в docker контейнере и поможет нам в этом Cursor AI IDE.
Разрабатывать приложение будем в ОС Windows 10, упакуем в docker контейнер и после разместим на хостинге.
Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно. Мы называем это “джаваскрипт”, но под капотом скрываются три разные сущности: EcmaScript, среда исполнения и экосистема. Иногда о них стоит говорить отдельно, но сегодня я хочу обсудить всё сразу и объяснить, почему джаваскрипт — это плохой язык. Не в смысле “не работает”, а в смысле “заставляет страдать”.
До недавнего времени программный доступ к куки в браузере осуществлялся через API document.cookie — простой строковый геттер/сеттер. Для получения одного файла куки приходилось разбирать всю строку вручную и преобразовывать ее в удобный формат. А чтобы записать куки, нужно было сначала сформировать структурированные данные, затем сериализовать их в строку и только после этого присвоить значение document.cookie. Разработчики часто используют популярные библиотеки, например js-cookie, которые делают работу с куки гораздо удобнее.
Сегодня мы продолжим разбирать базовые концепции реактивности, изложенные Райаном Карниато (Ryan Carniato), автором SolidJS. Если ранее мы затрагивали производные и их планирование, то сегодня разберём более сложную тему — асинхронность в контексте реактивного программирования. Эта концепция добавляет новый уровень сложности, поскольку требует учёта динамических процессов, выходящих за рамки синхронных операций.