
🚀 Устал каждый раз руками создавать Component.tsx, index.ts, styles.module.scss и всё по кругу?
Решение есть! Простой и кастомизируемый CLI-инструмент для Vite, который генерирует компоненты — из шаблонов, которые ты сам задаешь.
JavaScript-библиотека для создания интерфейсов
🚀 Устал каждый раз руками создавать 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. Если ранее мы затрагивали производные и их планирование, то сегодня разберём более сложную тему — асинхронность в контексте реактивного программирования. Эта концепция добавляет новый уровень сложности, поскольку требует учёта динамических процессов, выходящих за рамки синхронных операций.
Хочу показать три приёма, как можно ускорить загрузку интерфейсов с Backend-Driven UI и улучшить UX. Решения показали хорошие результаты на демо-версии, но увы, пока ещё не внедрены в реальный проект. Было бы интересно обсудить с вами, как эти приёмы могут помочь в боевых задачах и что ещё можно улучшить.
Пишу про полезные материалы про IT, и собираю свой ламповый нетворкинг тут - https://t.me/+434aQiGpZtAyNTU6. Присоединяйтесь!
Оглавление.
JetBrains зарелизил новую версию своего AI-ассистента и вместе с ним Junie - автономного нейросетевого агента-программиста, которому можно поручать небольшие рабочие задачи.
Буквально вчера я получил к нему доступ и не смог не воспользоваться возможностью. Я даже не представлял...
В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (Next.js и Nuxt, Redux и Pinia), использование в бэкенде, популярность решений в энтерпрайзе, а так же понимание разработчиками и LLM моделями.
Когда проект разрастается до десятков экранов, а папка helpers начинает весить больше, чем хотелось бы, приходит время пересмотреть подход к архитектуре. В этой статье — как я пришёл к принятию Feature-Sliced Design на React. Только личный опыт, ошибки и выводы.
Привет, Хабр!
Сегодня я хочу поделиться с вами руководством, как реализовать Static Site Generation (SSG) в React без использования сторонних фреймворков, таких как Next.js, TanStack Start, React Router и им подобных. Сразу оговорюсь: я не считаю их чем-то «плохим» и не агитирую против их применения. Всё гораздо проще: иногда по тем или иным причинам нет возможности использовать эти инструменты, или самостоятельная реализация оказывается предпочтительнее из-за количества изменений в кодовой базе.
Если вам интересна тема стратегий рендеринга веб-приложений, то прошу под кат.
Как понять, что реально делают ваши UI автотесты?
ui-coverage-tool — это инновационный инструмент нового поколения, не имеющий аналогов. Он визуализирует покрытие прямо в браузере, работая с реальным приложением. История по каждому элементу, фильтры по действиям, динамика и полная наглядность — всё, чтобы не просто тестировать, а понимать и улучшать.