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

❓ Shallow vs Deep Copy: как не сломать данные? Когда мы копируем объекты в JS, важно понимать, «зацепят» ли изменения оригинала нашу копию. ⤴️ Shallow Copy (Поверхностная) Копирует только верхний уровень. Если внутри есть вложенные объекты, то копия будет ссылаться на те же участки памяти, что и оригинал. Как сделать: [...arr], {...obj} или Object.assign(). Недостаток: Изменишь вложенный объект в копии — он изменится и в оригинале. ⤵️ Deep Copy (Глубокая) Создает полную независимую копию всех уровней вложенности. Как сделать: structuredClone(obj) — современный стандарт (рекомендуется в 2026!). JSON.parse(JSON.stringify(obj)) — старый костыль (не копирует методы и Date). Библиотеки типа lodash (cloneDeep). const user = { name: "Ivan", skills: ["JS"] }; const copy = { ...user }; // Поверхностная копия copy.skills.push("React"); console.log(user.skills); // ["JS", "React"] — Ой! Оригинал тоже изменился.

🗳 Почему типы не спасают от плохого API Есть распространённая иллюзия, если код типизирован — значит, всё ок. Спойлер: нет. Типы защищают от части ошибок, но не от плохих архитектурных решений. ❗️ Типы проверяют форму, а не смысл type User = { id: string role: string } С точки зрения типов — идеально. С точки зрения домена — катастрофа. Что такое role? Какие значения допустимы? Что означает пустая строка? Типы молчат. Ошибки — нет. ❗️ Типизированный хаос — всё ещё хаос API может быть: — перегруженным — непоследовательным — с неочевидными побочными эффектами — и при этом идеально типизированным doStuff(data, options, flags, ctx) ❗️ Типы не заменяют дизайн, лишь фиксируют этот бардак в коде Если API: — принимает «объект всего» — возвращает any-подобные структуры — заставляет знать внутренности системы Плохой интерфейс + типы = плохо типизированный интерфейс. ❗️ Типы не объясняют, как пользоваться API TypeScript не отвечает на вопросы: — в каком порядке вызывать методы — какие комбинации валидны — что можно делать, а что нельзя Если без документации API непонятен — типизация не спасёт. ❗️ Типы часто скрывают архитектурные проблемы Когда видишь: — гигантские union-типы — Partial<T> поверх всего — бесконечные дженерики Это не «сложно». Это симптом. ❗️ Как типы усиливают хороший дизайн, а не маскируют плохой Типы работают, когда: — API маленький — ответственность чёткая — доменные ограничения выражены явно — названия говорят сами за себя 📌 TypeScript — это не страховка от плохого API. Это усилитель. Хороший дизайн он делает надёжнее. Плохой просто закрепляет навсегда.

👩‍💻 Указываем, по каким линиям обрезать вертикальные отступы текста. Свойство text-box-edge задаёт, по каким визуальным линиям текста нужно обрезать вертикальные края блока, когда используется text-box-trim. Это помогает более точно контролировать высоту текстового контейнера. Границы текста можно задать разными способами. Верхняя граница (top-edge): • cap — по верхушкам заглавных букв; • ex — по высоте строчных букв; • text — по фактическому верху видимых символов. Нижняя граница (bottom-edge): • alphabetic — по базовой линии текста; • text — по самой нижней части символов (включая «хвосты»). Отлично подходит для числовых полей, дат и диапазонов, делая валидацию более наглядной.

Когда они это добавили? Теперь в Chrome DevTools отображаются вычисленные пошаговые значения для css calc() + переменных. Отладка стала в 100 раз проще

👩‍💻 Разрешаем выбор нескольких значений! С атрибутом 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 помогают при работе со строками. На картинке — базовые конструкции языка и самые часто используемые методы, которые стоит держать под рукой. Сохрани, чтобы не забыть!