Любимая задачка на знание React

Попробуйте вместо использования флага cancelled использовать AbortController https://developer.mozilla.org/en-US/docs/Web/API/AbortController

Я конечно извиняюсь за душнилство, но в java-script, то есть в React по сути, не может быть race condition, так как он однопоточен. Ваша же ссылка об этом и говорит. Это можно назвать, особенностями асинхронного взаимодействия, или может есть другое название, я не знаю. Но это не race condition

Извините, за, может быть, наивный вопрос: а что плохого в том чтобы "обмазать результат хука async/await"?))

Здравствуйте)

Мне кажется, что еще можно сделать такие улучшения.

1. Изначально задать isLoading в true. Ну или сделать проверку, что если url есть, то true, иначе false, но это если мы допускаем, что url может быть пустым.
В таком случае мы избавимся от одного лишнего ререндера когда isLoading, при первом вызове, будет становится в true. Но тогда еще и проверку внутри useEffect можно делать, чтобы не делать лишних действий если url не правильный/его в принципе не указали.

2. Я делал еще так, что в цепочке промисов - я не сразу обновляю стейт, а сохраняю в переменные внутри useEffect, чтобы избежать лишних рендеров. А в конце в finally устанавливаю всё сразу. В конкретно этом примере, опять же, это не нужно, но в более сложных - может понадобиться. Например если мы каким-то асинхронным валидатором решим проверить наши данные о.О ну условно) Или банально делаем несколько последовательных запросов или асинхронных операций)

function useFetch(url) {
   const [data, setData] = useState(null);
   const [isLoading, setIsLoading] = useState(true);
   const [error, setError] = useState(null);

   useEffect(() => {
      // флаг отмены
      let cancelled = false;
      let data = null;
      let error = null;

      setIsLoading(true);
      setData(null);
      setError(null);
      fetch(url)
         .then((res) => res.json())
         .then((respData) => {
            if (!cancelled) data = respData;
         })
         .catch((e) => {
            if (!cancelled) error = e;
         })
         .finally(() => {
            if (!cancelled) {
              setData(data);
              setError(error);
              setIsLoading(false);
            }
         });

      return () => {
         // выставим признак того, что запрос отменен
         cancelled = true;
      };
   }, [url]);

   return [data, isLoading, error];
}

Это что касается именно реакта.

Так же - конечно, лучше, как уже писали, и мне так тоже кажется, использовать AbortController.
Так же - я бы использовал не массив для возвращения, а объект, чтобы брать только то что нужно.
Так же - кеширование fetch, или, например, хранить кеши внутри хука.. если нужно.
В общем от задачи хука много зависит) Думаю так.

Эта задача проверяет исключительно понимание реализации на функциональных компонентах Реакта с использованием хуков. Для проверки этого можно придумать пример порелевантней, потому что если использовать кейс получения данных по апи - то адекватный ответ для всех, кроме джунов, это - "так делать нельзя". А джуны как раз будут пилить setState, useEffect, обрабатывать ошибки и бороться с race condition) То есть как раз "уверенно владеющие основами" люди. Если надо найти именно таких - то статья релевантная, хотя лучше бы без вызова апи, потому что отсекает более опытных разрабов.

Если же использовать задачу не для понимания знаний реакта, а в целом архитектур, то задача про вызов апи будет очень хорошим тестом. И основные темы там будут совсем другие:

• как организовать апи, чтобы можно было вызывать как из Реакта, так и из экшенов / моделей / реакций, и при этом в Реакте можно было узнать состояние запроса и отобразить лоадер

• как сделать изоморфные вызовы во всех этих кейсах, чтобы SSR дожидался выполнения всех вызовов из всех мест и показывал финальный html пользователю, при этом при ошибке критичных запросов редиректил на страницу 500 или применял другую стратегию

• как организовать типизированные запросы (чтобы не строки передавать в качестве урла, а аргументы функции) и обогащение запросов хедерами типа авторизации (это тема про "отдельный независимый слой апи")

• как тестировать апи с моками и отдельно от вью/моделей и других слоев, а также в связке с ними

• как сделать реалтаймовую валидацию входящих-исходящих данных исходя из TS-моделей

• как связать отображение ошибок и глобальные компоненты (нотификации, модалки), при этом оставляя возможность отобразить ошибку в глубоко дочернем компоненте (например, вывод ошибки красным текстом под полем + нотификацию на странице в верхнем правом углу)

И т.п. То есть вопрос про вызов апи - это отдельная большая тема. А вопрос про хуки Реакта и асинхронщину внутри них - совсем другая. И если вопрос про апи, то там наиболее адекватно было бы сказать, что хуки для этого не подходят, нужно использовать классовые компоненты, что приведет к отдельной ветке разговора)

Для собеседования хорошая задачка, но последним вопросом должно быть - почему этот хук это плохо и что должно быть вместо него

Этот хук не будет работать как ожидается без проверки статуса ответа

У меня 2 вопроса/замечания:

1. Вы с помощью таких задач ищете людей с опытом, чтобы они и в проде такое выдавали и считали это нормой?

2. Вы уверены, что правильно понимаете понятие race condition? Это не риторический вопрос, т.к. если мы запросили 2 разных url через этот хук, то это не состояние гонки. Гонка это когда у вас 2 одинаковых запроса идут и кто первый ответил, тот и молодец))) А у вас по коду получается, что компонент при монтировании/размонтировании просто для вида локальную переменную поменяет и тут же вычистит. Запрос при этом может уйти на сервер, исполнится там с 200 OK и, например, в случае с JWT, обновит токен с ответом вникуда, что повлечёт следом некорректную работу на фронте (невалидный токен).

Почему именно задача про загрузку данных? Рассматривали ли вы задачи связанные с context и его особенности ре-рендера? Сколько не посещал таких мероприятий почти всегда было "напишите ка нам хук, где нужно данные получить"

Спасибо, было интересно.

" Если url изменится, то запроса данных не произойдет. " может вы имели в виду "если url НЕ изменится"? А если я не прав с поправкой, то можете объяснить плиз почему так произойдет?

Для проверки основ и начала диалога норм