Сетевой запрос может иметь 3 разных ответа: отклонено, успешно и в ожидании. В этом посте я представляю способ обработки нескольких запросов в приложении React. Цель подхода — безопасно выполнять запросы в правильном порядке, а также упростить понимание функциональности другими разработчиками за счет строгой структуры.
Структура основана на идее, что функциональность кнопки не должна быть непосредственно привязана к кнопке. Тот же принцип, который работает с большим количеством оборудования. Например, если вы используете калькулятор. Функциональность каждой кнопки на калькуляторе не привязана непосредственно к кнопке, а размещена внутри машины. Кнопки несут ответственность только за вызов функций внутри машины, которые связаны с тем, что кнопка должна делать. Это означает, что все функции размещены вместе в одном месте, что упрощает понимание всего набора функций, а не каждого действия в отдельности.
Если вы работаете с приложениями, обрабатывающими несколько запросов, которые зависят друг от друга, может быть сложно обеспечить, чтобы эти запросы всегда были в правильном порядке. Как я обычно иду дальше и делаю это, пытаясь отделить как можно больше логики от файла компонента, чтобы позволить компоненту обрабатывать как можно меньше логики и сосредоточиться на рендеринге элементов.
Компоненту потребуется доступ к логике, определенной в файле useStateManagement, который по сути представляет собой хук состояния custom, созданный с помощью редюсера. Если мы посмотрим на компонент, отвечающий за рендеринг элементов в DOM, он будет выглядеть примерно так:
Файл useStateManagement экспортирует один объект и одну функцию. Объект state — это состояние, определенное в файле useStateManagement, и его можно легко настроить в соответствии с вашими потребностями. Значение состояния в состоянии отвечает за определение того, что отображается в компоненте, и в зависимости от состояния отображаются различные элементы, и поэтому пользователю предлагаются различные функции. Второй экспорт — это функция с именем dispatch, которая отвечает за инициирование event.types.
На данный момент файл useStateManagement еще не известен приложению. Ниже показано, как это будет выглядеть.
Мы используем хуки useReducer и useEffect из React, чтобы помочь нам обрабатывать события и изменения состояния в этом файле. Редьюсер отвечает за решение, какие действия доступны (action === event.type, другими словами, какой тип события доступен для каждого status). При начальной загрузке статус устанавливается на idle, разрешая только один тип события, FIRST_REQUEST. Мы также применили это в предыдущем файле, который заботится о визуализируемых элементах. Если статус внутри состояния равен idle, пользователь сможет просмотреть кнопку Initiate request sequence , которая, в свою очередь, инициирует диспетчерский вызов FIRST_REQUEST.
После того, как пользователь нажмет Initiate request sequence, запустится первый эффект — firstRequest. Как вы можете видеть здесь, мы переключаем статус на loading, что помогает нам указать пользователю, что что-то загружается (помните, что мы используем статус для отображения различных элементов в компоненте). Статус также предоставляет доступ к большему количеству типов событий. Если вы посмотрите в тело useEffect, мы определили первый запрос, и в случае успеха он запускает следующее событие отправки: dispatch({ type: ‘SECOND_REQUEST', data: response })})
Это означает, что когда первый запрос выполнен, мы направляемся прямо ко второму запросу, и мы также передаем ответ от первого запроса как data следующему событию. Причина этого в том, что второй запрос зависит от данных ответа на первый запрос. Здесь мы можем передать данные следующему запросу, передав их эффекту, запускающему второй запрос:createEffect('secondRequest', { firstRequestResponse: event.data })
Затем к этим данным можно получить доступ внутри тела useEffect (только в предстоящем цикле, позже доступ к ним будет затруднен). Это просто доступ с использованием текущего эффекта, который мы прокручиваем, и выбора той переменной, которую мы определили, когда передавали ее: effect.firstRequestResponse.
Чего нам не хватает, так это определения createEffect, которое в основном является просто объектом, использующим тип эффекта (это первый аргумент, который мы передаем в createEffect, который является строкой, с помощью которой мы называем эффект), а затем второй аргумент, который является данными переходим в createEffect. В нашем случае выше это { firstRequestResponse: event.data }.
Надеюсь, это вдохновило меня на то, как структурировать запросы в приложении React. Я считаю, что это вполне безопасный подход для обработки нескольких зависимых запросов, которые также зависят от данных из предыдущего запроса. Это последовательность запросов, которой довольно легко следовать, если вы новичок в кодовой базе и пытаетесь устранить неполадки или продолжить разработку функциональности.
Если у вас есть мнения об этом подходе или предложения по его улучшению, я был бы очень рад, если бы вы оставили комментарий со своими мыслями.
