В тексте все верно. Если у эффекта не указана зависимость (url), то при смене url эффект не пересчитается, новый url загружен не будет. Т.е. хук будет загружать только самый первый адрес после монтирования компонента.
А что не так с кодом? А что в нем поменяет с ростом уровня "сеньйорности" собеседуемого? Уточню - это не тестовое задание "на дом". Это задачка "на вайтборде", здесь и сейчас, минут на 10-15, не больше.
Ее основная цель (повторю в который раз) - проверить понимание основ React.
Конечно же она НЕ используется как единственный критерий оценки.
Вы с помощью таких задач ищете людей с опытом, чтобы они и в проде такое выдавали и считали это нормой?
Еще раз повторю то, что указано в начале поста. Это всего лишь одна из задач, которые я применяю на собесе. Ее функция - быстро (это не тестовое задание домой, это на условном вайтборде задача, минут на 10-15 с разговорами) оценить понимание основ React.
Вы уверены, что правильно понимаете понятие race condition?
Уверен. Более чем. Это именно состояние гонки. Т.к. без обработки "отмены" тайминг обработки запроса сервером и его RTT будет влиять на результат, который получит пользователь. В том числе мы можем получить что "молодец" как раз не тот, кто ожидался.
А у вас по коду получается, что компонент при монтировании/размонтировании просто для вида локальную переменную поменяет и тут же вычистит
Не забывайте про смену зависимостей эффекта. Переменная доступна через замыкание внутри колбэков промиса загрузки и внутри функции очистки эффекта.
Запрос при этом может уйти на сервер, исполнится там с 200 OK и, например, в случае с JWT, обновит токен с ответом вникуда, что повлечёт следом некорректную работу на фронте (невалидный токен).
Может, если на проекте авторизация по JWT. Но в условиях задачи нет ограничений и сказано что нужно просто загрузить данные по URL. Кандидат безусловно может сделать такое предположение и сообщить об этом, что будет безусловно в плюс. В этой точке я скажу что "забудь об этом, это ручка без авторизации, просто загрузи содержимое" и мы пойдем дальше.
Так в том и состоит задача интервьюера что бы постараться раскрыть кандидата при любых раскладах. Понятно что не надо по одной задачке судить всех.
Во-первых, всегда можно сказать "ок, давай отдельно обсудим почему так нельзя делать на продакшене, но сперва все же попробуем написать решение". Получить и проверку базы и дальше копнуть архитектуру. Я по прежнему считаю что это задача на хуки.
Во-вторых, при правильной аргументации со стороны кандидата можно скипнуть проверку базы и сразу понять что перед нами человек, который видит задачу с более общей точки зрения и перейти к другим вопросам, позволяющим копнуть архитектуру, изоморфность и все означенное выше. Главное что бы интервьюер обладал соответствующими знаниями ;)
Еще возможна ситуация, когда на проекте все означенные вопросы уже решены и решать их как-то иначе - не требуется. Возможно нам тут действительно не нужен архитектор, а нужен твердый мидл с хорошим пониманием базы? При собеседовании надо все же понимать, кого мы хотим нанять и зачем. И таки да, мы можем срезать тут overqualified людей. Но возможно это именно то, что в данной ситуации было нужно?
И такие найдутся, которые будут считать что это задача на хуки, а кандидат думать что на апи - и разойдутся.
Так на то оно и собеседование, что бы люди друг с другом поговорили. Потому что разработка современных продуктов это про команду, общение, аргументацию и договоренности.
Хороший кандидат задаст вопрос - что хотим тут получить? Уточнит требования, задаст вопросы о валидации, изоморфности и т.п. если это позволяет его кругозор. Хороший интервьюер направит в нужное русло и не будет слепо следовать "скрипту", сравнивать решение кандидата построчно с кодом из статьи на Хабре, верно же? )
Со всем согласен, кроме "отсекания более опытных разрабов". Можно использовать задачу как отправную точку. Ответ "так нельзя" это отличный повод задать вопрос "а почему?" и продолжить разговор, выслушать все, что описано выше.
Состояние гонки это когда параллельно какие то данные обновляются/читаются, причем могут выйти непредвиденные результаты.
Именно это тут и происходит. Без обработки смены зависимости (которая приведет к выполнению нового запроса) мы можем получить ровно вот это: непредвиденные результаты. Можно получить ситуацию, что интерфейс покажет данные для старого URL при этом пользователь ожидает другой результат.
Многие помнят что "отмена" эффекта нужна при размонтировании компонента. Но многие же забывают, что "отмена" эффекта происходит также и при смене значения зависимостей.
По поводу объекта и минимизации перерисовок - это отличное замечание, спасибо!
По поводу кэшей - тут я бы предпочел не накручивать лишнего. По мере надобности либо воспользовался возможностями, которые уже есть в HTTP, либо реализовать кэш в отдельном хуке и применил композицию.
Решения могут быть через AbortController (в случае fetch или в случае использования axios), но достаточно реализовать самый простой способ - с помощью локальной переменной
С точки зрения понимания React мне не так важно как именно будет реализована отмена, важнее что человек понимает почему она нужна (гонки), какими средствами React ("отмена" эффекта) она может быть реализована.
Безусловно, широкий кругозор соискателя (знание AbortController) будет в плюс, но достаточно простого решения.
Кстати, на тему "отмены" запроса к бэку. Совершенно верно, использование правильного механизма отмены дает больше возможностей "сэкономить". Но, с точки зрения запроса от клиента к серверу, его нельзя "отменить". Можно только разорвать соединение. А уж как этот разрыв соединения будет обработан серверной стороной, это уже зависит от конкретных используемых инструментов на бэке и какая именно задача выполнялась (запрос к базе, чтение файла и т.п.).
Конечно, JavaScript однопоточный, но вот приложение или система в целом (JavaScript на клиенте + асинхронный HTTP-транспорт + удаленный сервер) вполне может быть рассмотрена как "многопоточная", где однопоточный источник может породить несколько процессов, которые в рамках всей системы будут выполняться параллельно и вполне себе создавать race condition. Так что при всем уважении, термин я оставлю ;)
Кстати, отличное замечание! Ведь AbortContoller есть не только как часть fetch или axios (о чем упомянуто в статье), а и как вполне самостоятельная единица. С другой стороны, если его использовать самостоятельно (на в паре с fetch/axios), по сути этот тот же булевский флаг.
Кулинарная история с рецептами кажется получилась очень сложной )
Попробуйте спросить маму/девушку/жену рецепт борща. Подозреваю что для многих ингредиентов будет присутствовать дозировка «на глазок».
Я точно знаю на собственном опыте что на обезточенной машине (без аккумулятора) тормоза работают. Да, с очень слабым (по сравнению с обычным) усилием, но то и понятно — вакуумник та не работает, нет разряжения от работающего двигателя.
Интересно конечно какими входными данными руководствуется блок. Показания с тех же датчиков Холла на колесах идут к нему на сколько я видел схему НЕ по CAN шине.
В тексте все верно. Если у эффекта не указана зависимость (url), то при смене url эффект не пересчитается, новый url загружен не будет. Т.е. хук будет загружать только самый первый адрес после монтирования компонента.
А как это "сказал явно"? С точки зрения протокола HTTP как можно "явно" отменить запрос?
Вот самый правильный вопрос. Прежде чем городить звездолет, надо уточнить требования к продукту!
Потому что там асинхронность. Это сразу открывает много проблем, о которых можно поговорить и понимание которых проверить.
Субъективно, но кажется такие вот пустые запятые выглядят отвратительно ( Но про переименование поинт хороший.
А что не так с кодом? А что в нем поменяет с ростом уровня "сеньйорности" собеседуемого? Уточню - это не тестовое задание "на дом". Это задачка "на вайтборде", здесь и сейчас, минут на 10-15, не больше.
Ее основная цель (повторю в который раз) - проверить понимание основ React.
Конечно же она НЕ используется как единственный критерий оценки.
Еще раз повторю то, что указано в начале поста. Это всего лишь одна из задач, которые я применяю на собесе. Ее функция - быстро (это не тестовое задание домой, это на условном вайтборде задача, минут на 10-15 с разговорами) оценить понимание основ React.
Уверен. Более чем. Это именно состояние гонки. Т.к. без обработки "отмены" тайминг обработки запроса сервером и его RTT будет влиять на результат, который получит пользователь. В том числе мы можем получить что "молодец" как раз не тот, кто ожидался.
Не забывайте про смену зависимостей эффекта. Переменная доступна через замыкание внутри колбэков промиса загрузки и внутри функции очистки эффекта.
Может, если на проекте авторизация по JWT. Но в условиях задачи нет ограничений и сказано что нужно просто загрузить данные по URL. Кандидат безусловно может сделать такое предположение и сообщить об этом, что будет безусловно в плюс. В этой точке я скажу что "забудь об этом, это ручка без авторизации, просто загрузи содержимое" и мы пойдем дальше.
Так в том и состоит задача интервьюера что бы постараться раскрыть кандидата при любых раскладах. Понятно что не надо по одной задачке судить всех.
Во-первых, всегда можно сказать "ок, давай отдельно обсудим почему так нельзя делать на продакшене, но сперва все же попробуем написать решение". Получить и проверку базы и дальше копнуть архитектуру. Я по прежнему считаю что это задача на хуки.
Во-вторых, при правильной аргументации со стороны кандидата можно скипнуть проверку базы и сразу понять что перед нами человек, который видит задачу с более общей точки зрения и перейти к другим вопросам, позволяющим копнуть архитектуру, изоморфность и все означенное выше. Главное что бы интервьюер обладал соответствующими знаниями ;)
Еще возможна ситуация, когда на проекте все означенные вопросы уже решены и решать их как-то иначе - не требуется. Возможно нам тут действительно не нужен архитектор, а нужен твердый мидл с хорошим пониманием базы? При собеседовании надо все же понимать, кого мы хотим нанять и зачем. И таки да, мы можем срезать тут overqualified людей. Но возможно это именно то, что в данной ситуации было нужно?
Так на то оно и собеседование, что бы люди друг с другом поговорили. Потому что разработка современных продуктов это про команду, общение, аргументацию и договоренности.
Хороший кандидат задаст вопрос - что хотим тут получить? Уточнит требования, задаст вопросы о валидации, изоморфности и т.п. если это позволяет его кругозор. Хороший интервьюер направит в нужное русло и не будет слепо следовать "скрипту", сравнивать решение кандидата построчно с кодом из статьи на Хабре, верно же? )
Со всем согласен, кроме "отсекания более опытных разрабов". Можно использовать задачу как отправную точку. Ответ "так нельзя" это отличный повод задать вопрос "а почему?" и продолжить разговор, выслушать все, что описано выше.
Это именно гонка.
Именно это тут и происходит. Без обработки смены зависимости (которая приведет к выполнению нового запроса) мы можем получить ровно вот это: непредвиденные результаты. Можно получить ситуацию, что интерфейс покажет данные для старого URL при этом пользователь ожидает другой результат.
Многие помнят что "отмена" эффекта нужна при размонтировании компонента. Но многие же забывают, что "отмена" эффекта происходит также и при смене значения зависимостей.
По поводу объекта и минимизации перерисовок - это отличное замечание, спасибо!
По поводу кэшей - тут я бы предпочел не накручивать лишнего. По мере надобности либо воспользовался возможностями, которые уже есть в HTTP, либо реализовать кэш в отдельном хуке и применил композицию.
А как нам это поможет? Вернем из хука Promise? Ну допустим, давай попробуем...
Что дальше? Напишем await?
Допустим, но тогда внешняя функция должна быть async?
Но в этом случае функция MyComponent возвращает что? Правильно, Promise. А можно из React-компонента вернуть Promise? Как это будет работать?
Так я же говорю:
С точки зрения понимания React мне не так важно как именно будет реализована отмена, важнее что человек понимает почему она нужна (гонки), какими средствами React ("отмена" эффекта) она может быть реализована.
Безусловно, широкий кругозор соискателя (знание AbortController) будет в плюс, но достаточно простого решения.
Кстати, на тему "отмены" запроса к бэку. Совершенно верно, использование правильного механизма отмены дает больше возможностей "сэкономить". Но, с точки зрения запроса от клиента к серверу, его нельзя "отменить". Можно только разорвать соединение. А уж как этот разрыв соединения будет обработан серверной стороной, это уже зависит от конкретных используемых инструментов на бэке и какая именно задача выполнялась (запрос к базе, чтение файла и т.п.).
Конечно, JavaScript однопоточный, но вот приложение или система в целом (JavaScript на клиенте + асинхронный HTTP-транспорт + удаленный сервер) вполне может быть рассмотрена как "многопоточная", где однопоточный источник может породить несколько процессов, которые в рамках всей системы будут выполняться параллельно и вполне себе создавать race condition. Так что при всем уважении, термин я оставлю ;)
Кстати, отличное замечание! Ведь AbortContoller есть не только как часть fetch или axios (о чем упомянуто в статье), а и как вполне самостоятельная единица. С другой стороны, если его использовать самостоятельно (на в паре с fetch/axios), по сути этот тот же булевский флаг.
Попробуйте спросить маму/девушку/жену рецепт борща. Подозреваю что для многих ингредиентов будет присутствовать дозировка «на глазок».
Интересно конечно какими входными данными руководствуется блок. Показания с тех же датчиков Холла на колесах идут к нему на сколько я видел схему НЕ по CAN шине.