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

👩‍💻 Разрешаем выбор нескольких значений! С атрибутом multiple можно выбрать несколько имейлов или файлов в <input>, либо несколько вариантов в списке <select>. В зависимости от элемента поведение отличается: • для file — можно загрузить несколько файлов одновременно; • для select — становится доступен множественный выбор пунктов списка; • для email — можно ввести несколько адресов через запятую. multiple делает интерфейс гибче и избавляет пользователя от повторяющихся действий при работе с формами.

Различие между Object.freeze() и const const и Object.freeze – две разные фичи JavaScript. const применяется только для неизменяемой ссылки на ячейку памяти со значением, что означает невозможность задать новое значение для переменной. Object.freeze работает со значениями объектов. Делает объект неизменяемым, то есть изменить его свойства невозможно.

⛔️ 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 будет нарушаться снова и снова, сколько бы цифр вы туда ни написали.

📂 Напоминалка по циклам в JavaScript! Например, for удобно использовать, когда заранее известно количество итераций, а for...of — когда нужно пройтись по массиву или строке. На картинке — 5 циклов, которые постоянно встречаются в коде. Сохрани, чтобы не забыть!

Годная JS-либа для реализации drag-and-drop списков — Sortable Живёт уже не первый год, проверена временем и продом. Поддерживает перетаскивание элементов как внутри одного списка, так и между несколькими. Работает на нативном Drag and Drop API Простой и читаемый API, никаких зависимостей. Поддерживает анимацию при перетаскивании, работает на десктопах и тач-устройствах. Совместима с большинством фреймворков.

👩‍💻 Точность и согласованность кода благодаря функции автозаполнения! IntelliCode — улучшает автодополнение в VS Code: предлагает варианты на основе контекста, типа данных и того, что ты уже написал. Удобно в больших проектах, где важно быстрее находить нужные методы и не отвлекаться.

HTML-совет Не используй input type="number" для важных числовых полей — типа почтового индекса, номера карты и т.п. Почему? - На десктопе появляется ненужный спиннер. - Значение может случайно измениться при прокрутке мыши или нажатии клавиш вверх/вниз. Вместо этого — используй inputmode="numeric" + pattern ✅ Показывает цифровую клавиатуру на мобильных устройствах — лучше UX. ✅ Добавляет валидацию на цифры.

⛔️ 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 будет предпочтительнее. 📌 Если вам нужно часто вносить изменения в одну фичу, и для этого нужно лезть во все уголки проекта, значит архитектура выбрана неправильно. Лучший признак правильного решения — это когда фичу легко найти, изменить и удалить, а дальше уже детали.