Привет, Хабр! Меня зовут Дэниз, в этой статье я расскажу о микрофронтах — что это такое, какие у них плюсы и минусы, и как их можно реализовать. Пройдемся от того, зачем моей компании они понадобились, разберем реализацию, плюсы-минусы, и сделаем выводы.
26 ноября 2024 года вышла новая мажорная версия инструмента для сборки приложений Vite. Это событие особенно примечательно тем, что это первый релиз после анонса VoidZero, где Even You представил грядущее направление развития основных продуктов.
Далее мы рассмотрим ключевые моменты этого обновления.
Технически это называется «неконсистентный». А по-человечески — боль. Делюсь рабочим, хоть и неидеальным, способом её лечения.
Привет, Хаброжители! Наверняка вы неоднократно сталкивались с ситуацией, когда начинали разработку фронтенд‑приложения на React и вроде всё было очевидно, но через некоторое время чувствовали, что уже запутались, где какой компонент. И в такой ситуации приходится вновь и вновь смотреть код, чтобы вспомнить, где в иерархии находится определенный компонент. Или, например, начинаете создавать компонент и задумываетесь на время: — «А с чего начать и какой должна быть реализация?», а реализовав компонент понимаете, что можно было бы сделать это по‑другому.
Книга «Разработка фронтенд‑приложений» предлагает решения, для подобных ситуаций, а также даст руководство по‑другому подойти к разработке. Совершенно по‑новому!
Привет, с вами снова я – Дмитрий, React-разработчик, хотелось бы сегодня затронуть тему среды выполнения JS. Многие знают, другие уже подзабыли, а новички — вовсе не в курсе. В общем, эта статья точно найдёт своих читателей. Постараюсь простыми словами и по делу.
Привет! Меня зовут Алексей Гомелевский, я frontend-разработчик в Garage Eight. Моя команда занимается улучшением взаимодействия пользователей с продуктом, и недавно мы решили реализовать комментарии. В этой статье расскажу, как выбирали между решением из коробки и собственной разработкой, с какими сложностями столкнулись и как на базе комментариев создали чаты.
Всем, привет, меня зовут Дмитрий, я React-разработчик, и я снова здесь и попробую сегодня рассказать про Web Workers.
Если вы хоть раз пробовали обрабатывать большой файл, парсить массив из сотен тысяч элементов или запускать сложные вычисления прямо в React-компоненте, то наверняка сталкивались с тем, что интерфейс подвисает, кнопки перестают реагировать, анимации застывают, и всё на секунду подвисает, пока скрипт не разлучит нас (ой, это не из этой сказки) завершит свою работу.
Почему так происходит? Всё дело в том, что React, как и JS, в браузере работает на одном основном потоке. Точнее, чтобы меня не закидали помидорами, React — это библиотека JS, и она полностью работает в основном потоке браузера, который однопоточен. Когда вы запускаете тяжёлую синхронную задачу, она полностью занимает этот поток и блокирует его, мешая браузеру рендерить интерфейс и обрабатывать события пользователя.
В современном фронтенде отзывчивость интерфейса — требование по умолчанию. Пользователи ожидают, что ваше приложение будет мгновенно реагировать на действия, даже если оно выполняет тяжёлые вычисления или загружает большие объёмы данных.
В этой статье мы разберём, как можно решить эту проблему одним из вариантов — с помощью Web Workers.
Я починил плохой перевод силами ИИ, написав расширение при помощи ИИ. И я удивлён, что до сих пор такого не сделали.
Привет, Хабр!
При разработке фронтенда мы часто ограничиваемся тремя состояниями UI-запроса: loading, error, data (или success). Но это не всегда достаточно — особенно когда дело доходит до тонких UX-деталей, предотвращения гонок запросов и адекватного управления отменой при размонтировании компонентов. В статье рассмотрим, почему добавление состояния idle делает систему более надёжной, как реализовать конечный автомат для управления статусами, как отменять fetch-запросы и оптимизировать перерисовки.
Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.
Однако в последнее время, особенно во фронтенд-разработке и в мире React, акцент на SOLID заметно снизился и, например, вопросы о нем на собеседованиях встречаются всё реже. В первую очередь, это связано с переходом к функциональному стилю программирования, широким использованием хуков и отказом от классовых компонентов, что отодвигает принципы ООП на второй план.
Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.
В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.
Подписки в GraphQL позволяют клиенту подписаться на изменения данных на сервере. Например, в чате с их помощью можно получать уведомления о сообщениях, их удалении или изменении. В отличие от обычных запросов, подписки работают асинхронно, поддерживая постоянное соединение через WebSocket. В этом случае сервер может в любое время послать запрос клиенту. В то же время для обычных запросов(queries), чтобы увидеть изменение данных, клиенту нужно запрашивать их заново каждый раз. А ещё с помощью GraphQL Subscriptions и библиотеки Relay можно создать собственный мессенджер.
Современный React все больше соответствует идеалам функционального программирования.
Ежедневно мы пользуемся подходами из мира ФП, зачастую даже не подозревая об этом.
Эти паттерны плотно укоренились в сознании фронтенд-разработчиков, делая наш код значительно чище, читаемее и предсказуемее.
В этой статье мы применим один из функциональных паттернов в React приложении и посмотрим что из этого выйдет.
Привет, Хабр!
Сегодня поговорим о блокировке документов при совместной работе — задаче, которая на первый взгляд кажется простой, но таит в себе множество подводных камней. В этой статье я расскажу о нашем опыте реализации такого механизма в одном из проектов. Мы рассмотрим, с какими проблемами столкнулись, какие решения пробовали и к какому итогу пришли.
Недавно, работая с компонентом ввода номера телефона в форме регистрации, я столкнулся с весьма неочевидной особенностью работы различных обработчиков событий. Связано это непосредственно с onChange, onPaste и onInput. Мне пришлось провести достаточно глубокий ресерч, чтобы разобраться в особенностях, которые я встретил. Начнем по порядку.
Оптимизация производительности React приложений — важная часть разработки, особенно когда речь идет о сложных интерфейсах. В основном разработчики лишь краем уха слышат о необходимости использования хуков useMemo, useCallback и React.memo для оптимизации кода. Но если бездумно использовать их, то можно даже навредить вашему приложению
В этой статье я попытаюсь разобрать, когда действительно стоит использовать useMemo, useCallback и React.memo, а когда их использование излишне. Мы изучим каждый из хуков, их влияние на рендеринг компонентов в React, а также рассмотрим практические примеры с подробными объяснениями работы каждого из хуков.
Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался.
Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
20 частых антипаттернов в React и как их исправить. Разбираем ошибки с хуками, состоянием, мемоизацией и структурой компонентов: когда не нужен useEffect, зачем useCallback, почему не хранить производные значения в state. Минимальные примеры, чёткие принципы, практичные альтернативы.
Еще в бытность джунни, я наткнулся на милейшую интерактивную обучалку по селекторам CSS: CSS Diner. Кто не знает — обязательно посмотрите, эстетический кайф гарантирован. Прошел ее минут за 15 на одном дыхании и подумал: а почему бы не сделать что‑то подобное с аналогичной механикой «допиши правильное слово в пропуск в бойлерплейте», только по другой теме? Сходу на ум ничего не пришло, но идею я запомнил.
Три года спустя я решил изучить React, написав на нем какой‑нибудь пет‑проект (имхо, лучший способ изучить новую технологию/язык). Тут‑то я и вспомнил про CSS Diner. Осталось только найти подходящую тему, где эта механика бы зашла.
С этой статьи я начну цикл материалов, посвященных базовым концепциям реактивности, основанных на идеях и примерах, которые подробно изложил автор SolidJS, Райан Карниато (Ryan Carniato), в своем блоге. Наша цель — разобрать фундаментальные принципы, лежащие в основе реактивных систем, и показать их применимость в различных контекстах.
Кто сказал, что разработка ИИ‑агента — это сложно, долго и только для корпораций с миллионами в бюджете? Сегодня мы убедимся, что добавить в своё приложение умного ассистента может каждый. Встречайте: ИИ‑агент, который помогает пользователю принимать решения и обновляет данные в реальном времени.
Используя CopilotKit, LangGraph и Google Maps API, мы создадим приложение, которое не только действует по сценариям, но и предлагает решения. Мы изучим, как реализовать human‑in‑the‑loop, чтобы пользователь мог одобрять или отклонять действия агента.
Приятного прочтения (‑:
