Телеграм канал «Frontender\'s notes [ru]»

🎭 Как писать фронтенд-API без боли Когда разрабатываешь фронтенд-API, важно помнить, что это не просто тонкий слой поверх бэкенда. Это полноценный контракт, который определяет, насколько удобным будет продукт, как он будет восприниматься командой и какие проблемы будут возникать в будущем. Вот чеклист, как делать API, которые не только работают, но и легко поддерживаются. ⬆️ Предсказуемость API Одной из главных проблем является непоследовательность. Разные названия полей, структуры ответов или коды ошибок могут разрушить любые попытки стабильно работать с API. Если разработчик уже сталкивался с одним вашим эндпоинтом, он должен быть уверен, что следующий будет примерно таким же. Это поможет избежать проблем с поддержкой и быстрым внедрением новых функций. ⬆️ Документация, которая работает автоматически Ручная документация быстро устаревает. Используйте инструменты, которые генерируют документацию автоматически. Применяйте OpenAPI или Swagger, JSON Schema, и автоматическую генерацию TypeScript-типов и клиента. Так API и документация будут всегда в актуальном состоянии, и фронтенд станет намного стабильнее. ⬆️ Стабильность типов Проблемы начинаются, когда поля данных могут быть как null, так и отсутствовать. Это ломает UI и делает приложение нестабильным. К примеру, лучше иметь всегда однотипную структуру с корректным значением, чем случайные поля с разными типами данных. Убедитесь, что данные всегда стабильны и предсказуемы. ⬆️ Избегайте «магических значений» Пример плохого API: { "status": 3 }. Какое значение означает 3? Это нечитаемо. Лучше использовать понятные значения, например { "status": "blocked" }. Это снижает количество ошибок, делает API легче в поддержке и чтении, а также повышает понимание со стороны разработчиков. ⬆️ Ошибки — это не просто статус коды Ошибки должны быть обработаны с умом. Базовые коды ошибок 200 и 500 недостаточны для хорошей работы. Вместо этого используйте чёткие коды ошибок с описанием. Например, если сессия истекла, верните: { "error": { "code": "INVALID_TOKEN", "message": "Token expired" } } Это поможет сделать более эффективное восстановление сессий, ретраи и улучшит UX. ⬆️ Когда пишете API, учитывайте, что фронтенду важно: • Меньше мелких запросов • Возможность кэширования • Нормализованные данные • Компактные ответы • Фронтенд не любит, когда API возвращает огромные ответы с лишними данными. Помните о пагинации, батчинге и стабильных ETags для ресурсов. ⬆️ Давайте всё, что нужно для кэширования API должно поддерживать кэширование. Используйте такие механизмы, как ETag, Cache-Control, Last-Modified и max-age. Это позволяет фронтенду эффективно использовать кэш, уменьшить нагрузку и ускорить работу. ⬆️ Защищайте от over-fetching и under-fetching Убедитесь, что API не отправляет лишние данные (over-fetching), например, если вам не нужны роли пользователей или их настройки. Также не стоит заставлять фронтенд делать несколько запросов для получения нужных данных (under-fetching). Используйте view-модели, которые заточены под конкретные UI-экраны. ⬆️ Осознанно подходите к версионированию API Версионирование API должно быть осознанным. Простой путь с номерами версий /v2, /v3 — это ещё не всё. Важно обеспечивать совместимость внутри каждой версии и предусматривать возможность отката. Версионирование должно быть предсказуемым и чётким. ⬆️ Создайте клиентскую обёртку Фронтенд должен самостоятельно решать такие задачи, как ретраи, отмена запросов, debounce, тайм-ауты и токен-логика. Это не должно быть задачей бэкенда. Создайте единый слой API для клиента с помощью custom fetch wrapper, axios instance или TanStack Query. Один класс для всех запросов поможет добиться более стабильного поведения и улучшить контроль над запросами. 📌 Крутое фронтенд-API — это не просто набор точек входа, а целая система, которая должна быть предсказуемой и стабильной. Давайте создавать API, которое не ломает фронтенд, а упрощает жизнь всей команде. 🚪 Frontender's notes

Критическая уязвимость в React Server Components (CVSS 10.0). Рекомендуется обновление 🚨 React-команда официально сообщила о серьёзной проблеме безопасности в React Server Components. Уязвимость позволяет выполнить произвольный код на сервере без аутентификации — достаточно отправить специально сформированный HTTP-запрос. Даже если вы не используете React Server Functions напрямую — вы всё равно можете быть уязвимы, если ваш проект поддерживает React Server Components. Уязвимость получила идентификатор CVE-2025-55182, оценку CVSS 10.0, и затрагивает версии 19.0, 19.1.0, 19.1.1 и 19.2.0 следующих пакетов: react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack 🔘Что делать прямо сейчас Патч уже опубликован. Нужно обновиться на версии: 19.0.1, 19.1.2, 19.2.1. Если ваш React-код вообще не работает на сервере, или вы не используете фреймворки/бандлеры с поддержкой RSC, то вы не затронуты. Некоторые экосистемы зависели от уязвимых пакетов. В зоне риска: Next.js React Router (нестабильные RSC-API) Waku @parcel/rsc @vitejs/plugin-rsc Redwood SDK Команда React работает с хостинг-провайдерами, и временные смягчения уже включены. Но на них рассчитывать нельзя — обновляться всё равно нужно. 🔘В чём суть уязвимости React Server Functions позволяют клиенту вызывать функции на сервере. На стороне клиента вызов превращается в HTTP-запрос, который React затем десериализует и мапит на вызов серверной функции. Проблема — в том, как React декодирует payload от клиента. Атакующий может создать вредоносный HTTP-запрос, который при десериализации приводит к удалённому выполнению кода. Подробности раскроют позже, когда обновления будут полностью раскатаны. 🔘Инструкция по обновлению Next.js Установите патч в рамках вашей версии: npm install next@15.0.5 npm install next@15.1.9 npm install next@15.2.6 npm install next@15.3.6 npm install next@15.4.8 npm install next@15.5.7 npm install next@16.0.7 Если вы сидите на 14.3.0-canary.77 или выше — откатитесь на стабильную 14.x: npm install next@14 React Router (нестабильные RSC API) Обновите зависимости: npm install react@latest npm install react-dom@latest npm install react-server-dom-parcel@latest npm install react-server-dom-webpack@latest npm install @vitejs/plugin-rsc@latest Expo См. changelog на expo.dev. Redwood SDK npm install rwsdk@latest npm install react@latest react-dom@latest react-server-dom-webpack@latest Waku npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest Vite RSC npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest Parcel RSC npm install react@latest react-dom@latest react-server-dom-parcel@latest Turbopack RSC npm install react@latest react-dom@latest react-server-dom-turbopack@latest Webpack RSC npm install react@latest react-dom@latest react-server-dom-webpack@latest 📅 Таймлайн 29 ноября — уязвимость найденa и отправленa в Meta Bug Bounty. 30 ноября — Meta подтвердила и начала работать над фиксом с командой React. 1 декабря — фикc готов, идёт работа с хостингами и OSS-проекта́ми над валидацией и mitigations. 3 декабря — патч опубликован, уязвимость раскрыта публично. 📍 Ссылка на оригинал статьи...

⬇️ Modern lazy-loading: что грузить первым в 2025 В 2025 году концепция ленивой загрузки — это не просто разделение бандлов на чанки. Производительность веб-страниц достигла нового уровня: браузеры становятся умнее, сети быстрее, а пользовательские интерфейсы сложнее. Важно понять новую стратегию приоритетов загрузки, чтобы даже самый идеальный код не стал «тяжёлым» для пользователя. ❌ First-party UI: что грузить первым? В 2025 году при разработке UI важно сосредоточиться на быстрой загрузке ключевых элементов — каркаса, кнопок, инпутов и навигации. Это улучшит метрику Interaction to Next Paint (INP), ставшую приоритетом для браузеров. Критичные стили и UI-код также должны загружаться немедленно. Функционал, сложные компоненты и данные ниже первого экрана можно загружать лениво, включая аналитику и фоновые задачи для оптимизации производительности. ➡️ Всё, что ниже сгиба, можно загружать лениво Ленивую загрузку можно применять ко всем тяжелым секциям, изображениями с атрибутом loading="lazy", а также к модулям, которые загружаются после первого скролла. Новый IntersectionObserver 2 делает отслеживание видимости элементов более надёжным и быстрым, что идеально подходит для массового отслеживания lazy-load. ❗️ Библиотеки и UI-компоненты — только по мере необходимости Если пользователь не взаимодействует с модалкой, зачем грузить библиотеку для порталов, анимаций или форм? Используйте React.lazy или его аналоги для ленивой загрузки компонентов. Золотое правило: никогда не грузите компоненты без необходимости. ↗️ Статические ассеты: как загрузить их умнее В 2025 году можно расставлять приоритеты для загрузки ассетов. Для критичных изображений используйте атрибут fetchpriority="high", для шрифтов — preloading, для сторонних API — preconnect, а для фоновых картинок — приоритет low. 📣 Не забываем про «delayed-init» Иногда нужно загрузить код сразу, но выполнить его позже для минимизации нагрузки на UI. Это важно для аналитики, сложных элементов (карт, списков) и операций, которые могут «заморозить» основной поток. Используйте requestIdleCallback, setTimeout(..., 0), Web Workers и scheduler API для снижения нагрузки на UI. Этот подход не является настоящей lazy-load, но эффективно помогает оптимизировать работу интерфейса. 💡 AI-предсказания: предсказываем, что загрузить Фреймворки начинают использовать данные о поведении пользователей, чтобы предсказать, какие ресурсы будут востребованы. Например, Next.js, Remix, и Astro могут предварительно загружать ссылки при наведении, использовать гироскопические данные для prediction-preloading и статистическое кеширование переходов. 📝 Пример кода: // Пример кода для React: const FancyModal = lazy(() => import("./FancyModal.js")); // Для ванильного JS: if (needsModal) { import('/modal.js').then(initModal); } // Ленивую загрузку стилей тоже стоит включать с использованием атрибута media (html): 📌 Логика lazy loading стала более сложная. Понимание, что и когда грузить, поможет вашей странице работать быстрее и юзеры будут довольны. 🚪 Frontender's notes

🌎 Google не разрешает сотрудникам использовать свою же недавно выпущенную IDE Antigravity И, видимо, не зря — реддитор рассказал, что ИИ-агент Antigravity случайно удалил весь его диск, пока пытался исправить баг: «Я просматриваю журналы с предыдущего шага и с ужасом вижу, что команда, которую я выполнил для очистки кэша проекта (rmdir), по всей видимости, ошибочно указала на корень вашего диска D:, а не на конкретную папку проекта. Мне очень, очень жаль.» ✖️ xCode Journal

Ускорьте работу фронтенд-разработчика Cursor — IDE с ИИ, которая помогает писать код по описанию, искать ошибки и приводить проект в порядок быстрее обычного. Что делает: • генерирует и дополняет код на естественном языке • объясняет непонятные участки • находит ошибки и предлагает фиксы • подсказывает оптимизации и практики • работает как полноценная IDE, только быстрее Для компаний — это реальный способ ускорить команду без найма дополнительных разработчиков: меньше рутины, больше времени на архитектуру и продуктовые задачи. Попробовать Cursor: https://clck.ru/3QeE4z Поставщик в России — «Системный софт» (оплата в рублях, закрывающие документы и поддержка при подключении). Перейти на сайт #реклама 16+ syssoft.ru О рекламодателе

📣 Синхронизация состояния между вкладками: BroadcastChannel, SharedWorker и localStorage Когда пользователь открывает несколько вкладок одного приложения, часто возникает проблема синхронизации состояния. Например, пользователь может выйти из аккаунта в одной вкладке, но в других вкладках приложение продолжит считать его авторизованным. В 2025 году у нас есть несколько инструментов, которые помогают решить эту задачу: BroadcastChannel, SharedWorker и, для старых браузеров, localStorage. ➕ BroadcastChannel — простое решение для синхронизации сообщений Это API для синхронной передачи сообщений между вкладками браузера. Он позволяет подписываться на канал для получения и отправки данных, что эффективно для уведомлений и событий в разных вкладках. Подходит для синхронизации логина, выбора темы, обновления кеша и уведомлений о новой версии. Преимущества: простота, быстрая доставка, работа в фоновом режиме. Ограничения: не поддерживает общее состояние и сложные операции. ➕ SharedWorker — когда все вкладки работают как одно приложение Это инструмент для централизованной работы между вкладками, обеспечивающий синхронизацию состояния, кэширование и управление запросами. Он полезен для приложений, требующих координации между вкладками. Преимущества: централизованное хранилище состояния, разделение ресурсов и снижение повторных API-запросов. Ограничения: не поддерживается в Safari, требует сложного дебаггинга и продуманной архитектуры. ➕ LocalStorage + storage event — старый, но работающий способ Один из самых простых методов синхронизации данных. Этот подход подходит для проектов, требующих поддержки старых браузеров и не использующих Service Worker или SharedWorker, а также для простых случаев синхронизации между вкладками. Преимущества: простота реализации и широкая совместимость. Ограничения: хранит только строки, событие storage срабатывает в других вкладках, а не в той, где произошли изменения, и может быть медленнее, чем BroadcastChannel. ✅ Примеры: // BroadcastChannel const channel = new BroadcastChannel("session"); channel.onmessage = (e) => { console.log("message:", e.data); }; channel.postMessage({ loggedOut: true }); // SharedWorker // main.js const worker = new SharedWorker("worker.js"); worker.port.postMessage({ type: "ping" }); worker.port.onmessage = (e) => console.log(e.data); // worker.js onconnect = (e) => { const port = e.ports[0]; port.onmessage = () => port.postMessage("pong"); }; // LocalStorage + storage event window.addEventListener("storage", (e) => { if (e.key === "logout") { // синхронизация } }); 📌 Для синхронизации состояния между вкладками используют BroadcastChannel для уведомлений (например, для событий входа/выхода), SharedWorker для разделения состояния в PWA и дашбордах, а в старых браузерах — localStorage с событием storage. У каждого инструмента своя фишка, и выбор зависит от того, насколько замороченный у тебя проект, какие браузеры поддерживаешь и с какими данными работаешь. 🚪 Frontender's notes

JavaScript сегодня отмечает 30-летие 🎂 Именно 4 декабря 1995 года миру показали язык под знакомым нам названием — JavaScript. ❌ Вот история именинника: • У языка было три имени за пару месяцев. Сначала его назвали Mocha, потом переименовали в LiveScript, и только затем закрепилось финальное — JavaScript. • К Java он почти не имеет отношения. Название выбрали скорее как маркетинговый ход: в середине 90-х вокруг Java был мощный хайп, и на эту волну просто запрыгнули. • JS слепили всего за 10 дней. Брендан Эйх в бешеном темпе собрал первую версию, когда в Netscape решили: «нам срочно нужен язык для скриптов в браузере». • Создатель языка успел стать CEO Mozilla — и быстро лишиться должности. Из-за скандала вокруг его гомофобных взглядов Эйху пришлось уйти с поста, хотя имя JavaScript уже навсегда вписано в историю. 🎉 Поздравляем старичка, который до сих пор двигает весь веб. 🚪 Frontender's notes