🚀 Устал каждый раз руками создавать Component.tsx, index.ts, styles.module.scss и всё по кругу?
Решение есть! Простой и кастомизируемый CLI-инструмент для Vite, который генерирует компоненты — из шаблонов, которые ты сам задаешь.
7–8 апреля прошла самая крупная в РФ IT‑конференция, просвещённая JavaScript development и всему с ней связанному.
Итак, HolyJS — пожалуй самая крупная «семья» во всем сообществе javascript‑разработчиков, продуктивности и дружелюбности которой можно бесконечно поражаться и восхищаться! Ребята собирают под своим крылом лучших экспертов‑спикеров со всей России...
В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов.
Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.
Если вы недовольны текущими решениями для организации библиотек компонентов или просто любите технические кейсы — добро пожаловать под кат!
На одном из проектов мне нужно было реализовать Telegram-бота с использованием Web App. Я выбрал стек: Vite + React + Zustand + TypeScript. До этого я в основном работал с Webpack, и столкнулся с вопросом — как удобно организовать алиасы. В Vite есть resolve.alias, и это удобно. Но дополнительно нужно прописывать пути в tsconfig.json, чтобы IDE понимала, что происходит. А ещё это не работает с HTML-импортами.
💡 Здесь важно: HTML теперь может импортировать модули напрямую, и если бы алиасы работали и там — можно было бы писать одни и те же пути и в скриптах, и в коде, и в конфиге.
Привет! Меня зовут Алексей Песоцкий, я фронтенд-тимлид в AGIMA. Противостояние дизайнеров и разработчиков носит уже почти легендарный характер. Этой теме посвящены десятки статей, видосов и докладов. А отношения отделов ставят в один ряд с другими фундаментальными конфликтами: кошки и собаки, кому дует и кому душно, Хельга и Арнольд. Но мы в компании уверены: чтобы лучше понимать друг друга, нужно просто следовать элементарным правилам.
Я провел небольшой аудит статей по теме, понаблюдал, как эта коммуникация устроена у нас — и решил напомнить всем, почему для дружбы фронтендера и дизайнера нет никаких препятствий.
Я начал этот небольшой проект под названием isomorphic-validation, как эксперимент, в основном в образовательных целях. Несмотря на то, что существует множество других библиотек валидации, я решил все равно изобрести велосипед. Это была попытка скрыть все сложности, связанные с условными операторами и асинхронностью при создании пользовательского интерфейса...
В этой статье мы разберем ключевые преимущества TypeScript, посмотрим на его расширенные возможности и на практике покажем, как он помогает нам справляться с реальностью крупных проектов. Более того, вы сможете увидеть, как TypeScript открывает новые горизонты даже для новичков, которые только начинают путь в разработке.
На дворе 2023 год. Город Ханчжоу. Китайская компания High-Flyer решает открыть стартап DeepSeek, для более детального исследования возможностей искусственного интеллекта. Амбициозный проект, на который возложили большие надежды, в том числе, создавая цель, привнести на китайский рынок конкурентоспособную модель AI, которая будет полной альтернативой западным инструментам. Оправдались ли ожидания от открытия Deepseek?! Да, успех проекта оказался колоссальным. Даже учитывая, что это не коммерческая история, отчёт о доходах данной компании показал, что он успешно вытесняет других представителей языковых моделей с рынка. В нашем случае Дипсик полезен тем, что изначально большая его часть разрабатывалась для решения задач, связанных с программированием. Поэтому в данной статье мы рассмотрим, преимущества данного ИИ- помощника для работы с кодом.
С приходом ИИ сильно вырос соблазн заниматься простым человеческим вайб-кодингом: пишешь себе промпты, копируешь готовый код, вставляешь в проект - и готово! И бизнес рад, и времени меньше уходит… В чем подвох? Пожалуй, в том, что таким образом все меньше полезной информации оседает в голове.
В этой статье я хочу поделиться своим методом, с помощью которого я внедряю новые фичи в проект, над которым работаю, при этом получая новые знания и опыт (как в старые добрые времена), затрачивая гораздо меньше времени.
Привет, Хабр! Я Борис Ермаченко, фронтенд-разработчик сервисов для физических лиц ПСБ. В этой статье рассмотрим, как с помощью ESLint построить архитектуру в проекте, и поговорим про несколько подходов.
Также прикладываю бонус — демо-проект, где можно экспериментировать и пробовать все подходы.
Уже более пяти лет мы занимаемся разработкой OpenSilver — open-source-фреймворка, который позволяет переносить приложения на базе WPF и Silverlight в современный веб. Проект стабильно развивается, активно используется в корпоративной среде, и недавно мы задумались о том, как расширить возможности наших пользователей и запустить существующие приложения ещё и на iOS и Android.
Поскольку под капотом OpenSilver использует платформу Blazor, логичным шагом стала интеграция с .NET MAUI Blazor Hybrid. В этой статье я расскажу, как прошла интеграция и какие результаты мы получили на практике. Забегая вперёд, скажу, что результатом мы остались очень довольны!
Сегодня во фронтенде многое кажется очевидным, но когда-то всё приходилось писать вручную, и каждое решение рождалось из конкретной боли разработчиков.
Если разобраться, откуда взялись эти подходы, легче понять логику фреймворков. Мы подготовили практический разбор, который помогает увидеть структуру за интерфейсом: почему фреймворки устроены именно так и что из старых решений до сих пор влияет на код.
Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.
Однако в последнее время, особенно во фронтенд-разработке и в мире React, акцент на SOLID заметно снизился и, например, вопросы о нем на собеседованиях встречаются всё реже. В первую очередь, это связано с переходом к функциональному стилю программирования, широким использованием хуков и отказом от классовых компонентов, что отодвигает принципы ООП на второй план.
Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.
В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.
Введение: Архитектурное дежавю
Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.
Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.
Ускорьте разработку React-компонентов! Эта статья о создании шаблонов для автоматизации рутинных задач: генерация папок, файлов, управление экспортами. Экономьте время и фокусируйтесь на главном.
Фронтендеры, постоянно в поиске идеальной архитектуры. Слои, фича-слайсы, атомарный дизайн, фрактальность... Все эти подходы имеют право на жизнь. Но сегодня я хочу поделиться способом мышления, который сделает любой ваш код лучше, а любую архитектуру – яснее.
Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.
Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.
Последние три месяца я активно тестировал AI coding инструменты, изучал их ограничения и лучшие практики. В статье я рассказываю про выбор инструментов, уровни автономности ИИ-программирования, проблемы, с которыми столкнулся и выводы на будущее.
Да, я действительно написала Fetch-подобную утилиту для ReactOS. В этой статье я расскажу, как написание приложения для ReactOS стало моим первым опытом. При этом я не умею программировать.
В современном вебе защита персональных данных – неотъемлемая часть ответственной разработки. Один из ключевых элементов – получение согласия пользователя на использование cookie-файлов. Несоблюдение этих требований может повлечь не только серьёзные штрафы, но и подорвать доверие аудитории.
В этой статье мы разберём:
· Зачем нужно согласие на cookie?
· Какие бывают типы cookie?
· Что такое Google Consent Mode?
· Как реализовать баннер согласия?
· Как управлять куки в зависимости от предпочтений пользователя?
· Как проверить, что настройки согласия работают?Зачем нужно согласие на cookie?
А также приведем примеры политик использования файлов cookie.