Собеседование фронтенд разработчика. ТОП вопросов по HTTP и CORS

2 года назад·3 мин. на чтение

На собеседованиях на позицию фронтенд разработчика часто задают базовые вопросы, связанные с работой браузера и HTTP протокола.

В этой статье разберем одни из самых популярных вопросов, которые вероятнее всего спросят на frontend интервью.

Что такое CORS?

CORS (Cross-Origin Resource Sharing) - механизм, который дает возможность клиенту (агенту) получать разрешение на доступ к ресурсам сервера на домене, который отличается о того, который использует сайт. Механизм использует дополнительные HTTP-заголовки. Если источник документа, с которого происходит запрос на ресурс, отличается от ресурса протоколом, доменом или портом, то считается, что агент делает запрос с другого источника. Т.е. происходит cross-origin HTTP request.
Говорят, что агент пользователя делает запрос с другого источника (cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

Для чего нужен CORS?

Браузеры ограничивают запросы с другого источника (cross-origin запросы) в целях безопасности. Такие запросы могут совершать, например, сторонние скрипты, подключенные на сайт. Такие API как Fetch или XMLHttpRequest следуют политике одного источника (same-origin policy). Таким образом, при использовании web-приложением этого API, существует ограничение: домен запрошенных HTTP-ресурсов и домен web-приложения должен быть одним и тем же. Для снятия этого ограничения нужно использовать CORS-заголовки. Следующие вопросы связаны с работой HTTP протокола. Ответы на эти вопросы важно знать. Крупные компании часто задают эти вопросы на собеседованиях на позицию фронтенд разработчика.

Какие существуют HTTP методы?

Эти методы указывают действие, которое должно быть выполнено для указанного ресурса. Также эти методы иногда называют HTTP глаголами. Эти методы отличаются семантикой.
МетодОписание
GETизвлечение (чтение) данных ресурса
POSTдля отправки данных к указанному ресурсу; для изменения состояния и/или побочные эффекты
PUTдля замены данных ресурса данными из запроса
PATCHдля частичного изменения ресурса
DELETEдля удаления ресурса
HEADзапрос ресурса, но в отличие от GET, без тела ответа
CONNECTустанавливает туннель к серверу
OPTIONSдля описания параметров соединения с указанным ресурсом
TRACEдля вызова тестового сообщения

Из чего состоит HTTP-запрос?

  • HTTP-метод - глагол (например, GET, POST) или существительное (например, OPTIONS, HEAD), которое определяет действие, которое хочет выполнить клиент.
  • Путь к ресурсу:
    • протокол (http://)
    • домен (example.com)
    • TCP порт (80)
  • Версия HTTP-протокола.
  • Заголовки (опционально). Предоставляют дополнительную информацию для сервера.
  • Тело запроса (опционально). Некоторые методы (например, POST), могут содержать данные об отправляемом ресурсе.

Что такое HTTP cookie?

HTTP cookie (куки) - это небольшой фрагмент данных, который отправляется сервером в браузер пользователя. Далее браузер может сохранить cookie и отправлять обратно серверу с каждым запросом. Такой механизм позволяет узнать, с одного и того же браузера были отправлены запросы или нет. Это используется, например, для аутентификации пользователя. Сам протокол HTTP не хранит состояние, механизм cookie позволяет добавить в него состояние.

Для чего используют HTTP cookie?

Cookie используются, главным образом, для:
  • Управления сеансом (логины, корзины для виртуальных покупок)
  • Персонализации (запоминать предпочтения пользователя)
  • Мониторинга (отслеживания поведения пользователя)
Получив HTTP-запрос, сервер вместе с ответом может отправить заголовок Set-Cookie. Cookie обычно запоминаются браузером и отправляются в HTTP заголовке с каждым последующим запросом к серверу, который сохранил эти cookie. Cookie можно настраивать, задав срок действия или срок его существования. Также можно указать ограничения на путь и домен. Если флаг HttpOnly не установлен, то доступ к существующим cookies можно получить через JavaScript.

Что такое HTTP?

Протокол передачи гипертекста (Hypertext Transfer Protocol, HTTP). Это протокол прикладного уровня для передачи гипертекстовых документов, таких как HTML. Он создан для связи между веб-браузерами и веб-серверами. Протокол следует классической клиент-серверной модели. Клиент открывает соединение для создания запроса, а затем ждет ответа. HTTP - это протокол без сохранения состояния, т.е. сервер не сохраняет никаких данных (состояние) между двумя парами "запрос-ответ". Несмотря на то, что HTTP основан на TCP/IP, он также может использовать любой другой протокол транспортного уровня с гарантированной доставкой.

Особенности протокола HTTP

Простота. HTTP удобен и прост для восприятия человеком. HTTP сообщения легко читать и тестировать. Расширяемость. За счет HTTP-заголовков можно легко его расширить, добавив новую функциональность на основе соглашений между клиентом и сервером. Нет состояния, но есть сессия. Между разными запросами не существует связи. Однако, cookie позволяют использовать сессии для идентификации пользователей. Соединение управляется на транспортном уровне. Протокол требует надёжность и отсутствие потерянных сообщений. Подходящим транспортным протоколом является TCP.

Отличия HTTP/1.0, HTTP/1.1, HTTP/2

HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом. Открытие соединения требует нескольких обменов сообщениями, и потому это медленный процесс. HTTP/1.1 предоставил конвейерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок Connection.
HTTP/2 добавил мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным. В этой статье рассмотрели топ вопросов на позицию frontend developer, связанных с HTTP протоколом и CORS.

Хуки useTransition и useDeferredValue в ReactJS 18

2 года назад·3 мин. на чтение

В React 18, релиз которого произошел в марте 2022, появилось много новых инструментов для написания производительных и отзывчивых приложений. Одним из заметных изменений является механизм рендеринга с новой ключевой концепцией: конкурентный рендеринг (concurrent rendering).

В этой статье повнимательнее рассмотрим два новых хука: useTransition() и useDeferredValue(). Эти два хука дают возможность определять приоритет обновления состояния, или, скорее, указывать, является ли обновление менее важным, чем другие, и откладывать его в пользу более срочных.
Какое обновление можно считать срочным, а какое обычным?
  • Срочные обновления: отражают прямое взаимодействие, такое как набор текста, клики, нажатия и т. д., т.е. то с чем взаимодействует пользователь. Когда вы вводите текст в поле ввода, вы хотите сразу увидеть введенный вами текст. В противном случае UI будет казаться медленным и подлагивать. Поэтому мы хотим сделать такие обновления приоритетным.
  • Обычные обновления: переход пользовательского интерфейса из одного вида в другой. Пользователи знают, что представление должно измениться или обновиться (например, когда ожидается ответ на запрос данных). Даже если есть небольшая задержка, это можно рассматривать как ожидаемое поведение, и это не будет восприниматься как медлительность приложения.
Итак, теперь подробнее рассмотрим эти два новых хука, объясним, когда их можно использовать, и посмотрим на конкретные примеры того, как их реализовать.

Хук useTransition() и функция startTransition()

До React 18 все обновления состояния помечались как "срочные". Это означает, что все обновления состояния обрабатывались одинаково с одинаковым приоритетом. С помощью useTransition() теперь можно пометить некоторые обновления состояния как несрочные.

Когда использовать useTransition() ?

Одним из примеров может быть список товаров с параметрами фильтрации. Когда вы переключаете чекбоксы, чтобы выбрать размер или цвет одежды, вы ожидаете, что чекбоксы сразу же отобразят отмеченное или снятое состояние. А сам список товаров, которые необходимо обновить согласно фильтрам, может быть отдельным и менее срочным обновлением.

Как использовать useTransition() ?

function App() {
 const [isPending, startTransition] = useTransition();
 const [searchQuery, setSearchQuery] = useState('');
 
 // запрос данных, который занимает некоторое время
 const filteredResults = getProducts(searchQuery);
 
 function handleQueryChange(event) {
   startTransition(() => {
     // оборачивая setSearchQuery() в startTransition(),
     // мы помечаем эти обновления как менее важные
     setSearchQuery(event.target.value);
   });
 }
 
 return (
   <div>
     <input type="text" onChange={handleQueryChange} />
 
     {isPending && <span>Loading...</span>}
     <ProductsList results={filteredResults} />
   </div>
 );
}

Хук useDeferredValue()

useDeferredValue() очень похож на useTransition() в том, что он позволяет отложить несрочное обновление состояния, но применяется его к части дерева. Это похоже методы debounce и throttle, которые мы часто используем для отложенных обновлений. React будет работать с такими обновлениями, как только завершатся срочные обновления.

Когда использовать useDeferredValue()?

С помощью useTransition() вы сами решаете, когда конкретное обновление состояния может быть помечено как менее срочное. Но иногда такой возможности может и не быть, например, если фрагмент кода находится в сторонней библиотеке. В таких случаях можно воспользоваться хуком useDeferredValue(). С помощью useDeferredValue() вы можете обернуть значение и пометить его изменения как менее важные и, следовательно, отложить повторный рендеринг. useDeferredValue() будет возвращать предыдущее значение до тех пор, пока есть более срочные обновления для завершения и отображения дерева с обновленным значением.

Как использовать useDeferredValue() ?

function ProductsList({ results }) {
 // deferredResults получат обновленные данные
 // когда завершатся срочные обновления
 const deferredResults = useDeferredValue(results);
 
 return (
   <ul>
     {deferredResults.map((product) => (
       <li key={product.id}>{product.title}</li>
     ))}
   </ul>
 );
}

Итоги

Эти два новых хука позволяют сделать интерфейсы максимально отзывчивыми, даже в сложных приложениях с большим количеством повторных рендерингов, отдавая приоритет обновлениям, которые имеют решающее значение для взаимодействия с пользователем, и помечая некоторые другие как менее важные. Это не означает, что нужно оборачивать все состояния этими хуками. Их следует использовать в крайнем случае, если приложение или компоненты не могут быть оптимизированы другими способами (например, при помощи lazy loading’а, пагинации, веб-воркеров и т. д.).