Настя Котова // Frontend & Node.js

📌 Навигация по каналу Если вы только присоединились к нам или просто хотите освежить знания, мы составили для вас удобную подборку наших материалов по ключевым темам: 👨‍💻 JavaScript: - Потеря контекста, this и globalThis: - Часть 1 - Часть 2 - Объект console и его методы - IntersectionObserver - CommonJS и ECMAScript Modules: в чём разница? 🖌️ CSS: - Анимации в CSS: - Часть 1 - Часть 2 - Z-index и контекст наложения: - Часть 1 - Часть 2 - Видео на канале - Как сделать адаптивный iframe - Как подключить локальные шрифты к вашему сайту 📜 HTML теги: - picture - audio и video - Теги для форм - svg 💻 TypeScript: - Полезные директивы TypeScript - TypeScript 5.5: - Часть 1 - Часть 2 🔥 React: - Обзор новинок React 19 - Новые хуки React 19 с примерами: - Часть 1 - Часть 2 - React Compiler - Server Components и Server Actions: - Часть 1 - Часть 2 - State-менеджеры vs React Hooks: когда и что лучше использовать - Библиотека react-use - useLayoutEffect 🤝 Двусторонняя клиент-серверная связь: - Long Polling - WebSocket - Server-Sent Events 🌐 Сети и инфраструктура: - Что такое CDN - Что такое S3 - JWT токены 🌟 Веб-разработка: - Как работают поисковые системы и как поднять свой сайт в поисковой выдаче - Что нужно знать фронтенд-разработчику за пределами фронтенда - Полезные фишки DevTools - UI-библиотеки 🛠️ Инструменты сборки: - Виды зависимостей в package.json - Семантическое версионирование - Линтеры на фронтенде: Prettier, ESLint, Stylelint - Prettier, ESLint и Stylelint: в чем разница? - Как настроить Prettier, ESlint, Styleling и Husky в проекте с нуля - Пресет для демо с помощью Vite и Express - Инструменты для сборки на фронтенде 🔒 Безопасность: - Что такое CSRF 💡 Архитектура: - Отличия Stateless и Statefull 📖 Приятного чтения! Лайки, комментарии и репосты помогают нам развиваться и делать контент ещё лучше! 👍

🤝🏻 Двусторонняя клиент-серверная связь. Часть 1: Long Polling Часто при разработке тех или иных приложений возникает потребность поддерживать двустороннюю связь между клиентом и сервером, то есть не только подгружать некоторые данные по запросу клиента, но и уметь динамически их обновлять при изменениях на сервере. Самый простой вариант реализации такого поведение - делать периодические запросы к серверу за новыми данными. Но, во-первых, это порождает кучу лишних запросов и излишнюю нагрузку на сервер, и, во-вторых, данные будут приходить с очевидной задержкой. 💡 Один из более оптимальных вариантов реализации - это использование Long Polling. Фактически, это поддержание соединения между клиентом и сервером посредством обыкновенного длинного http-запроса, который удерживается сервером, пока в нём не появятся новые данные или не пройдёт сетевой таймаут. При этом после успешного ответа, таймаута или ошибки клиент инициирует новый запрос и цикл повторяется. Простой пример реализации API с использованием библиотеки Express:

const messagesQueue = [];

// Route для отправки сообщений на сервер
app.post('/send', express.json(), (req, res) => {
    const { message } = req.body;
    messagesQueue.push(message);
    res.status(200).send('Message received');
});

// Route для long polling
app.get('/poll', (req, res) => {
    function checkForMessages() {
        if (messagesQueue.length > 0) {
            const messages = messagesQueue;
            messagesQueue = [];
            res.json(messages);
        } else {
            // Проверяем сообщения каждые 500 мс
            setTimeout(checkForMessages, 500);
        }
    }
    checkForMessages();
});

Как результат, на клиентах обновления будут ловиться с помощью метода /poll, а обновляться с помощью метода /send. Один из плюсов этого метода с точки зрения сервера в том, что для его поддержания не нужны какие-либо дополнительные настройки, так как используются обыкновенные http-запросы. 🤔 Звучит просто и круто, а какие у этого всего есть недостатки? 1. Использование ресурсов сервера - каждый Long Polling запрос требует, чтобы сервер удерживал соединение в открытом состоянии, что потребляет ресурсы сервера. Это может стать проблемой при большом количестве клиентов. 2. Задержка ответа - существует задержка между моментом появления данных и их получением клиентом, поскольку сервер должен дождаться окончания заданного интервала или появления данных перед тем, как ответить на заявку. 3. Управление ошибками и таймаутами - требуется аккуратное управление ошибками и таймаутами, чтобы избежать утечки ресурсов и удерживания соединений открытыми без необходимости. 4. Масштабируемость - масштабирование приложений с использованием Long Polling может быть сложным, поскольку каждое удерживаемое соединение занимает серверные ресурсы. 5. Отсутствие симметричности отправки и приёма сообщений - Long Polling оптимизирован для сценариев, где клиент чаще получает данные, чем отправляет. Направленная связь в обратном направлении не так эффективна. 🪄 Чуть более сложный пример реализации для обыкновенного чата на основе Long Polling есть в нашем репозитории. А в Live Demo можно потрогать результат и пообщаться! ⚡️ Как можно заметить, у этого метода есть много недостатков. Ставьте реакции, если вам интересна эта тема, чтобы углубиться в более эффективные способы реализации двусторонней связи между клиентом и сервером, такие как WebSockets, Server-Sent Events и WebRTC.

👆 Примеры вывода методов group и table

📝 Объект console и его методы Недавно у меня возникла необходимость красиво вывести результат выполнения одного скрипта в консоль, в идеале в виде таблички. И тут я вспомнила, что у объекта console в JavaScript существуют не только методы log и error, которые чаще всего используются, но ещё и ряд других, и поэтому я решила немного в них покопаться. 📌 Первые, и самые простые, это log, info, warn, error и debug. Первый просто выводит сообщения любого вида в консоль, а остальные в целом делают то же самое, но задают сообщению так называемый log level. Например, warn покрасит сообщение в жёлтый, а error в красный, но итоговое оформление будет зависеть от среды выполнения. А метод debug выведет сообщение только в том случае, если в консоли включен режим дебага. 📌 Следующий метод как раз помог мне решить мою первоначальную задачу. Метод table принимает либо двумерный массив, задающий строки таблицы, либо массив объектов с одинаковыми ключами, и на основе этих данных выводит данные в виде таблицы. Её вид также может отличаться в зависимости от среды выполнения. 📌 Совсем неожиданными для меня стали методы group и groupEnd , которые позволяют группировать выводимые в консоль сообщения, при этом групп может быть несколько и они могут быть вложенными. Например (выравнивание сделано для лучшей читаемости):

console.group("Группа");
  console.log("Внутри группы");
  console.group("Подгруппа");
    console.log("Внутри подгруппы");
  console.groupEnd();
console.groupEnd();

📌 Ещё интересные методы - это assert и count , которые могут быть полезны при дебаге. Первый позволяет проверить истинность выражения, а второй может посчитать количество вызовов сообщений с определённой меткой. Метод count может также быть полезен, если нужно посчитать количество ререндеров конкретного компонента. Примеры:

console.assert(1 === 2, "Неправильно!");  // Выведет "Неправильно!", если утверждение ложное

console.count("Метка"); // Выведет "Метка: 1"
console.count("Метка"); // Выведет "Метка: 2"

📌 Ну и последнее, но не менее важное, что хотелось бы рассмотреть - это методы time и timeEnd, которые берут на себя измерение времени между двумя точками в выполнении кода. Например:

console.time("Таймер"); // Задаём таймеру метку
for(let i = 0; i < 1000000; i++) {}  // Некий код, который занимает время
console.timeEnd("Таймер"); // Выведет время, затраченное на выполнение цикла

🔗 И это были не все методы, которые есть в объекте console. Подробнее об этих и других методах можно почитать на MDN, а поэкспериментировать с ними можно прямо сейчас в консоли вашего бразуера!

📢 Новые хуки в React 19! Часть 2 В предыдущей части мы посмотрели на хуки useActionState и useFormStatus, а сегодня разберем useOptimistic💡 Напоминаю, что все примеры лежат в нашем репозитории здесь 👉 GitHub 🔍 useOptimistic Часто в современных интерфейсах используют подход, который называется Optimistic UI. Он заключается в том, что мы предполагаем, что на бэкенде запрос выполнится успешно, поэтому сразу можем показать пользователям обновленное состояние. Ранее для реализации такого поведения приходилось сильно хитрить. Нельзя просто вызвать useState в обработчике перед асинхронной операцией и ожидать, что React сразу же отрисует новое состояние. Посмотрите на пример 5:

const [optimisticResult, setOptimisticResult] = useState(store);

... = useActionState(async (__: string | null, formData: FormData) => {
    setOptimisticResult((prevState) => ({
      title: formData.get('title')?.toString() || prevState.title,
      description: formData.get('description')?.toString() || prevState.description,
    }));

    await saveData(formData);

    return 'ok';
  }, null);

Дело в том, что в React есть специальный механизм оптимизации — Batching, который не позволяет изменениям произойти до получения ответа от сервера. Эту проблему решает новый хук useOptimistic. Если заменить в примере useState на этот хук, всё заработает правильно. Пример 6 использования нового хука:

const [optimisticResult, setOptimisticResult] = useOptimistic(store);

  ... = useActionState(async (__: string | null, formData: FormData) => {
    setOptimisticResult((prevState) => ({
      title: formData.get('title')?.toString() || prevState.title,
      description: formData.get('description')?.toString() || prevState.description,
    }));

    await saveData(formData);

    return 'ok';
  }, null);

А если наша отправка формы завершится ошибкой, “оптимистичное” состояние автоматически сбросится. Пример использования с обработкой ошибок:

const [optimisticResult, setOptimisticResult] = useOptimistic(store);

  ... = useActionState(async (__: string | null, formData: FormData) => {
    setOptimisticResult((prevState) => ({
      title: formData.get('title')?.toString() || prevState.title,
      description: formData.get('description')?.toString() || prevState.description,
    }));

    try {
      await saveData(formData);
    } catch (e) {
      return 'not ok';
    }

    return 'ok';
  }, null);

Дело в том, что при использовании useOptimistic мы передаем в него то значение, для которого хотим сделать оптимистичную версию (в данном примере это store).

const [optimisticResult, setOptimisticResult] = useOptimistic(store);

После выполнения обработчика в хук запишется значение, соответствующее текущему состоянию store. ✍️ Пишите в комментариях, полезней ли на ваш взгляд хук useOptimistic, чем два предыдущих. Мне кажется, этот хук будет использоваться чаще, чем useActionState и useFormStatus.

🎉 Недавно мои коллеги из Яндекса публично зарелизили классный продукт — CodeRun. Это как LeetCode, но с уникальными задачами на русском, а еще с более новыми версиями компиляторов. А для фронтендеров могут быть интересны задачки на вёрстку картинок на чистом HTML и CSS! Вот ссылка: Задачки на вёрстку Это не реклама (честно-честно), просто я думаю, ребята сделали действительно полезный продукт, которым можно пользоваться в том числе и для подготовки к собеседованиям. 👍 Ставьте реакции, если хотите от нас разбор каких-нибудь интересных задач на алгоритмы!

📢 Новые хуки в React 19! Часть 1. В одном из предыдущих постов мы писали про обновление React 19, и вы проголосовали за новые хуки для работы с состоянием! 💡 Я решила поразбираться в них, чтобы понять, что к чему и чем они отличаются от наших старых добрых и любимых useState и useReducer. На разборе у меня были три самых свежих и интересных: 1. useActionState 2. useFormStatus 3. useOptimistic Все примеры лежат в нашем репозитории здесь 👉 GitHub 🔍 useActionState и useFormStatus В документации React говорится, что useActionState даст преимущество в работе с Server Actions, поэтому я подняла проект, используя Next 15, который из коробки поддерживает React 19 (и сам находится в бете). Без использования директивы "use server", useActionState может показаться ничем не отличающимся от useState. Однако в сочетании с Server Action он становится очень интересным инструментом. В самом первом примере есть простая форма с одним полем, которая отправляет данные на сервер с помощью useActionState.

export function FormUseActionState() {
  const [result, formAction] = useActionState(submitForm, null);

  return (
    <form action={formAction}>
      <h2>Form With useActionState</h2>
      <input name="title" />

      <button type="submit">Save!</button>
    </form>
  );
}

'use server';

export const submitForm = (prevState: string | null, form: FormData) => {
  return form.get('title')?.toString() || '';
};

Примечательно, что в случае работы с Server Action нам достаточно просто передать его первым аргументом в useActionState, и дальше мы можем использовать возвращаемый из хука formAction напрямую в теге form. Таким образом мы: 1. совершенно не думаем о том, каким образом данные будут ходить с клиента на сервер и обратно 2. полагаемся на нативную браузерную обработку форм, не используя дополнительные обработчики onChange каждого поля и отдельные состояния, если нам это не нужно 3. можем миксовать серверный и клиентский код рядом друг с другом Во втором примере можно увидеть, что у нас также доступен isPending:

const [result, formAction, isPending] = useActionState(submitForm, null);

Однако если у нас произойдет какая-то ошибка в серверном submitForm, то все наше приложение упадет - можно посмотреть на 3 примере. А это значит, что мы обязательно должны позаботиться об обработке ошибок в той функции, которую передаём хуку useActionState. Также, если мы не хотим заниматься глубоким прокидыванием isPending в дочерние компоненты форм, можно использовать новый хук useFormStatus - 4 пример

const { pending } = useFormStatus();

✍️ Во второй части разберем хук useOptimistic, а пока пишите в комментариях, что показалось интересным и как, по вашему мнению, часто будут использоваться новые хуки! ❤️ Реагируйте, если хотите увидеть обзор на Server Components и Server Actions!

🚀 Регулярные выражения в Typescript 5.5 Недавно Оля писала о последнем обновлении TypeScript 5.5, и меня особенно заинтересовал пункт «Контроль синтаксиса регулярных выражений». Я вообще фанат регулярок, еще в университете мне хорошо объяснили их, и с тех пор я активно использую их в рабочих задачах. Поэтому я решила поподробнее посмотреть, что нового добавил здесь TypeScript. Во-первых, проверка синтаксиса будет осуществляться только в пределах литералов регулярных выражений. Например, этот код проверяться будет:

let myRegex = /@robot(\s+(please|immediately))?/;

А вот этот уже нет:

let myRegex = new RegExp("@robot(\s+(please|immediately))?");

В новую версию добавлена базовая проверка на синтаксис регулярных выражений, вроде забытых открывающих или закрывающих скобок. Кроме того, TypeScript теперь будет проверять наличие используемых скобочных групп (включая именованные) и доступность фичей регулярных выражений в используемой версии ECMAScript. Посмотрим, насколько это поможет на практике. Лично я всё равно всегда пользуюсь специальными сервисами для тестирования регулярок, например, https://regex101.com/, а потом уже копирую их в код.

Про попапы ходит невероятное количество споров, но иногда это действительно страшная вещь!

💥 Новый TypeScript 5.5: Основные функции и улучшения! На днях увидела новость, что вышло очередное обновление TypeScript версии 5.5, которое приносит с собой ряд интересных изменений. Кажется, что некоторые из них могут значительно помочь при разработке. Например: 1️⃣ Улучшенная инференция типов TypeScript 5.5 продолжает улучшать систему типов, обеспечивая более точное и умное выведение типов. Это значительно упрощает работу с сложными структурами данных без необходимости явного указания типов. Лично мне кажется, что это одно из самых долгожданных улучшений. 2️⃣ Контроль синтаксиса регулярных выражений Теперь, если вы допустили ошибку при написании регулярного выражения, TypeScript это подсветит и выбросит ошибку. Кажется, что этого очень давно не хватало. 3️⃣ Переменная ${configDir} внутри tsconfig.json Теперь для задания путей относительно конфигурационного файла можно использовать специальную переменную. Таким образом, любые расширения для базового конфигурационного файла не будут нарушать правильность указанных в нём путей. 4️⃣ Поддержка новых методов Set TypeScript теперь поддерживает новые методы для работы с Set, такими как union, difference, intersection и другие. 5️⃣ Оптимизация производительности компилятора Разработчики TypeScript уделили внимание улучшению производительности компилятора, что приводит к более быстрому компилированию кода и ускорению процесса разработки. 6️⃣ Улучшения в инструментах и IDE поддержке TypeScript 5.5 включает улучшения в интеграции с IDE, такие как более интуитивные подсказки и автодополнения, что делает процесс разработки более комфортным и эффективным. 🔗 И это далеко не все изменения в релизе. Подробнее можно узнать в официальном блоге TypeScript.

🚀 React 19: разбираемся в обновлениях! Не так давно вышла новая версия одного из самых распространенных фреймворков для разработки фронтенда. Сегодня разберемся в обновлениях и ключевых фичах этого релиза. 🔹 Новые Хуки 1. useTransition - позволяет управлять приоритетом рендеринга, делая приложение более отзывчивым и плавным. 2. useActionState - упрощает работу с состоянием, связанным с асинхронными действиями, такими как подтверждение данных или загрузка. 3. useOptimistic - позволяет интерфейсу мгновенно реагировать на действия пользователя, в то время как данные подтверждаются на сервере. 4. useFormStatus - предназначен для управления состоянием форм, такими как валидация, отслеживание изменений и управление отправкой. 5. useDeferredValue - позволяет отложить обновления некритичных данных, что может быть полезно для поддержания быстродействия интерфейса при обработке больших объемов данных или сложных рендерингов. 🔹 Новое API "use" React 19 ввёл новое универсальное API "use", которое унифицирует чтение данных из различных ресурсов при рендеринге. Сейчас это API поддерживает получение данных из Promise и контекста, в дальнейшем планируется расширение его возможностей. 🔹 React Server Components Server Components продолжают развиваться, позволяя разрабатывать компоненты, рендеринг которых происходит на сервере. Это ускоряет загрузку страниц и уменьшает ресурсоёмкость клиента. Server Actions дполнительно упрощают взаимодействие с сервером, интегрируя логику обработки действий непосредственно в серверные компоненты. 🔹 Улучшенная обработка ошибок React 19 вводит новый механизм для ловли и обработки ошибок в компонентах. Теперь разработчики могут более гибко управлять поведением при ошибках, определяя пути восстановления приложения. 🔹 Дополнительные усовершенствования - Новая реализация паттерна Provider для контекста, которая упрощает передачу данных через компоненты. - Добавление функций очистки для ссылок, которая помогает управлять памятью и ресурсами эффективнее. 🔗 Читайте полный список изменений и подробности на официальном сайте React.

⚡️ Новое видео на канале! https://www.youtube.com/watch?v=ZFCe7clBKio