Фронтенд Гайд

⛔️ Performance budget который все любят на словах и игнорят в жизни Про performance budget говорят красиво. На созвонах кивают, в доках рисуют цифры, в презентациях всё зелёное. А потом проходит пара спринтов и внезапно выясняется, что бандл потолстел, LCP поплыл, а никто даже не заметил. Я такое видел не раз и почти всегда причина одна и та же. ✅ Как performance budget обычно выглядит в теории На бумаге всё выглядит аккуратно и логично. Ограничения на размер бандла, контроль LCP, TTI и CLS, лимиты на количество запросов, ожидания по времени рендера. Кажется, что если есть цифры, значит есть и контроль. Но реальность быстро вносит свои правки. ❌ Почему budget умирает почти сразу Самая частая ошибка в том, что budget вводят как набор чисел, а не как процесс. Написали JS не больше условных 200 KB и разошлись. Никто не проговорил, что делать если лимит превышен, кто за это отвечает и что важнее в конкретный момент новая фича или перф. В итоге цифры есть, а решений ноль. Вторая боль это отсутствие автоматической проверки. Если budget не проверяется в CI, его просто не существует. Локально у всех всё быстро, а в проде внезапно плюс десятки килобайт и лишние секунды LCP. И самое грустное никто этого не поймал в моменте. 👏 Почти всегда побеждают фичи Когда нужно выбирать между релизом и остановкой из за производительности, команда почти всегда идёт в сторону релиза. Performance это отложенная боль, а фича нужна прямо сейчас. Потом к этому возвращаются. Или не возвращаются. Ещё одна проблема в том, что budget делают слишком общим. Один лимит на всё приложение выглядит просто, но работает плохо. Лендинг, дашборд и админка живут по разным правилам и ожиданиям. Но budget почему то часто одинаковый для всех. 📣 И финальный гвоздь в крышку гроба это отсутствие прозрачности Когда лимит превышен, никто не может быстро ответить, чем именно мы его съели. Без понимания причин budget превращается в абстрактную цифру из дока. ⚙ Когда performance budget реально начинает работать Он перестаёт быть про килобайты и становится про пользовательские метрики. Он проверяется автоматически через CI, Lighthouse или Web Vitals. Он разбит по страницам и сценариям, а не размазан по всему приложению. И самое важное есть чёткое правило, что делает команда если лимит превышен. Performance становится частью Definition of Done, а не красивым бонусом. 📌 Performance budget это не цифры в документации. Это договор внутри команды. Про то, что для нас достаточно быстро и про то, от чего мы готовы отказаться, если стало хуже. Пока этого договора нет, budget будет нарушаться снова и снова, сколько бы цифр вы туда ни написали.

📂 Напоминалка для работы с CSS-псевдоклассами! Например, :first-child применяется к элементу, который является первым дочерним элементом родителя, а :first-of-type выбирает первый элемент указанного типа среди дочерних. На изображении - наиболее используемые псевдоклассы для работы со структурой DOM. Сохрани, чтобы не забыть!

5 недооцененных возможностей JavaScript 1. FlatMap FlatMap в JavaScript — это отличная техника, с которой можно познакомиться здесь. FlatMap объединяет в себе функции map и метода массивов filter. Рекомендую использовать flatMap() вместо комбинации filter() и map(). 2. Порядок использования методов массивов Методы массивов — одни из самых важных методов, помогающих взаимодействовать с массивами. В JavaScript существует множество методов массивов. 3. Метод reduce Я наблюдал эту проблему у многих фронтенд-разработчиков. Когда пакет типа react-charts запрашивает данные в объектоподобной структуре, а реализация react-charts запрашивает данные в формате, сгруппированном по ключу, большинство разработчиков применяют метод .forEach() или некорректно используют метод map(). 4. Генераторы Генераторы и итераторы, пожалуй, относятся к элементам кода, не используемым JavaScript-разработчиками, знания которых ограничиваются вопросами для собеседования по программированию. В сценариях извлечения данных можно столкнуться с огромным объемом данных в БД/API, которые придется передавать во фронтенд. В этом случае наиболее часто используемым решением в react является бесконечная загрузка. 5. Нативные классы JavaScript В комплект поставки JavaScript входят нативные классы, с помощью которых можно довольно легко создавать/инстанцировать такие элементы, как URL, заголовки и т. д.

👩‍💻 3D-лента изображений с фокусом при наведении! В этой фишке мы создаём 3D-ленту изображений с глубиной, перспективой и движением. Как работает: • используется единая адаптивная единица --index, которая масштабируется; • perspective задаёт глубину; • кастомный cubic-bezier формирует плавное движение без дёрганий; • вся интерактивность работает через transform и filter. Такой приём отлично подходит для галерей и портфолио, подборок контента, hero-блоков.

📂 Напоминалка для работы с JavaScript! Например, let и const используются для корректного объявления переменных, map и forEach — для обработки массивов, а includes и split помогают при работе со строками. На картинке — базовые конструкции языка и самые часто используемые методы, которые стоит держать под рукой. Сохрани, чтобы не забыть!

👩‍💻 Посимвольная загрузка с волновой анимацией! Интерактивность не всегда требует сложных компонентов. Иногда достаточно правильно прописать движение. Как работает: • каждый символ вынесен в отдельный <span>, что дает контроль над фазой анимации; • animation-delay через CSS-переменную создаёт ритм без дублирования ключевых кадров; • движение построено на transform, поэтому анимация не вызывает перекомпоновки; • изменение opacity визуального акцента активных цифр. Отлично подходит для обработки загрузки, ожидания и переходов, где важно удерживать внимание, не перегружая пользовательский интерфейс.

👩‍💻 Управляем резиновым ресайзом одной строкой! Пользователь может растянуть <textarea> как угодно, и это часто ломает layout, вылазит за контейнер, разваливает сетку, сдвигает кнопку отправки: textarea { resize: both; } Если ресайз в интерфейсе не предусмотрен, запретим его явно: textarea { resize: none; } Нужен только вертикальный ресайз (самый безопасный для формы)? Тогда так: textarea { resize: vertical; } 🔥 Такая мелкая деталь, позволяет сохранять целостность интерфейса.

Вертикальные вкладки доступны за флагом в Chrome 145 (текущая бета) 1. Перейдите на chrome://flags/#vertical-tabs 2. Включите флаг (установите Enabled) 3. Перезапустите Chrome 4. Кликните правой кнопкой по панели вкладок и выберите “Move Tabs To The Side” (переместить вкладки вбок)

🔎 Feature-based vs Layered архитектура: что выбрать для фронтенда? Когда вы начинаете проект, всё кажется довольно простым. Но потом начинаются проблемы. Архитектура фронтенда может быть выбрана так, что она сначала удобна, а потом превращается в настоящую головную боль. Сегодня давайте разберёмся, чем отличается feature-based подход от layered архитектуры и где каждый из них действительно работает. ➕ Layered архитектура Layered архитектура — это та самая классика, с которой все когда-то начинали. Всё в проекте делится на слои: компоненты, сервисы, store, api и утилиты. • Это удобно на старте, и легко понять новичкам, потому что структура очевидна и проста. Но когда проект начинает расти, появляется куча проблем. Например, если вам нужно внести изменения в бизнес-логику, то придётся таскаться по пяти разным папкам. Вроде бы просто, но на деле начинается путаница. • Пример, который я часто встречаю: добавление функционала «избранного». UI живёт в папке components, запросы — в api/favorites, а состояние в store. Функция вроде как есть, но она размазана по всему проекту, и найти все её части в одном месте просто невозможно. ➕ Feature-based архитектура В feature-based архитектуре всё куда проще: каждый функционал — в своей папке. Структура выглядит примерно так: /features /favorites ui/ api/ model/ lib/ • Здесь вся фича собрана в одном месте: UI, API и модель. Это даёт отличный контроль за кодом, упрощает рефакторинг и удаление функций, и делает работу с фичами понятной и изолированной. Всё, что связано с конкретной фичей, будет в её папке, и даже если вам нужно её удалить — вы просто стираете папку. Меньше глобального шума и больше порядка. • Однако, как и в любом подходе, тут тоже есть свои нюансы. Например, если фичи слишком маленькие, это может привести к дублированию логики. Плюс, нужно чётко следить за границами и договориться с командой, что стоит делать фичами, а что нет. ➕ Как это выглядит на практике? В больших проектах, как правило, не бывает чистых подходов. Очень часто используется гибрид: папки для инициализации, провайдеров, бизнес-сущностей и пользовательских сценариев. • Такой подход позволяет сбалансировать бизнес-логику и не превращать папку shared в помойку, сохраняя возможность масштабирования. • Когда стоит выбрать какой подход? Если проект маленький, срок жизни короткий и работает 1-2 человека, то layered будет вполне хорош. Но если продукт живёт долго, несколько команд работает над ним, а фичи часто меняются — feature-based будет предпочтительнее. 📌 Если вам нужно часто вносить изменения в одну фичу, и для этого нужно лезть во все уголки проекта, значит архитектура выбрана неправильно. Лучший признак правильного решения — это когда фичу легко найти, изменить и удалить, а дальше уже детали.

💼Можно ли управлять отображением цифр в тексте без подмены шрифта? Свойство font-variant-numeric позволяет управлять начертаниями цифр и связанных с ними символов. Принимает одно или несколько значений: • normal — отключает альтернативное начертание; • ordinal — добавляет дополнительные глифы для порядковых числительных; • slashed-zero — ноль будет с чертой внутри; • lining-nums — каждая цифра лежит на базовой линии текста; • oldstyle-nums — набор строчных цифр, в котором 3, 4, 7, 9 свешиваются с базовой линии; • proportional-nums — допустима разная ширина цифр; • tabular-nums — одинаковая ширина каждой цифры; • diagonal-fractions — числитель и знаменатель в дроби уменьшены и разделены косой чертой; • stacked-fractions — числитель и знаменатель в дроби уменьшены и разделены горизонтальной линией. Это свойство работает только со шрифтами, в которых заложены OpenType фичи.

❌ Когда useMemo и useCallback делают только хуже Все любят useMemo и useCallback. А точнее, все любят думать, что они ускоряют приложение. Но проблема в том, что в реальных проектах они часто могут ухудшить производительность, а не улучшить. Давайте разберёмся, когда эти хуки на самом деле становятся более вредными, чем полезными. 🗳 Оптимизация, где её нет Начнём с того, что если компонент и так рендерится быстро, то использовать useMemo не имеет смысла. Эти хуки добавляют ненужную работу: React всё равно должен хранить зависимости, сравнивать их и поддерживать ссылки в памяти. А для чего? Чтобы оптимизировать то, что и так работает нормально? Это самый популярный антипаттерн, с которым сталкиваются почти все фронтендеры. ⬅️ «useCallback ради useCallback» Очень частая ситуация: оборачиваем колбэк в useCallback, думая, что это спасёт нас от лишних рендеров. Но на самом деле, если эта функция не передаётся в memo-компонент и не участвует в зависимостях эффектов, то useCallback просто создаёт лишний шум в коде, не давая ни улучшений в производительности, ни каких-то других плюсов. ❗️ Ломается читаемость Забудьте про чистоту кода. Когда вы обвешиваете всё хуками, как ёлку игрушками, код становится сложнее для восприятия и поддержки. Особенно это важно для новых людей в команде: приходится разбираться в логике, а зависимости в коде ломаются быстрее, чем вы успеваете заметить. 🔫 Иллюзия оптимизации Самая опасная ошибка — это когда вы начинаете думать, что «всё оптимизировано», потому что начали использовать useMemo и useCallback везде. Но настоящие проблемы обычно кроются в лишних рендерах из-за стейта, тяжёлых эффектах, layout thrashing и, конечно же, неправильной архитектуре компонентов. Эти проблемы не решаются хуками. 📌 Помните, что оптимизация не всегда требует использования дополнительных хуков. Прежде чем применять эти инструменты, важно понять, действительно ли это необходимо. Оптимизация должна быть направлена на уменьшение лишней работы, а не на усложнение кода.

👩‍💻 Настраиваем иерархию стилей в проекте! Когда проект растёт, стили начинают перебиваться и путаться. CSS дал решение - каскадные слои. Создайте слои с приоритетом: @layer reset, base, components, utilities; Теперь порядок каскада становится управляемым: слои идут строго в указанной последовательности, а внутри слоя продолжают работать обычные правила (специфичность и порядок объявления). Например, базовые стили: @layer base { button { font-size: 1rem; }} Компоненты идут выше по приоритету: @layer components { .btn-primary { font-size: 1.1rem; }} И утилиты завершают каскад: @layer utilities { .fs-lg { font-size: 1.25rem; }} 🔥 Так исчезают конфликты слоёв, приоритеты всегда предсказуемы, проще мигрировать и рефакторить большие проекты.

Обрати внимание, что в корректном примере чипы мгновенно перемещаются на новую позицию, когда один из чипов удаляется. Это происходит из-за режима popLayout в AnimatePresence из motion/react, который обеспечивает более плавную и быструю анимацию при удалении элемента

📂 Напоминалка для работы с React.js! Например, useState помогает хранить состояние компонента, а useEffect — работать с побочными эффектами и запросами к API. На картинке — основные темы и приёмы, которые чаще всего используются в React-разработке: хуки, рендеринг, формы, роутинг, стилизация и оптимизация. Сохрани, чтобы не забыть!

Держите полезную CLI-утилиту — npkill, предназначенную для удаления всех папок node_modules в проектах. Позволяет освободить значительное количество места на диске Запускаешь команду: npx npkill Дальше, просто нажимаешь [Пробел], чтобы удалить те папки, которые больше не используешь Удобно ещё и то, что она показывает, сколько дней назад была последняя модификация