Решаем проблемы REST с помощью Redux Toolkit Query

В приложениях с REST архитектурой существует ряд проблем:

• повторяющийся код при работе с состоянием приложения;

• костыли и велосипеды при обработке результатов и состояний запросов;

• отсутствие стандартного механизма кеширования полученных на клиенте данных;

• одновременные запросы за одними и теми же данными; 

• сложности реализации pessimistic/optimistic обновления состояний.

В клаудных микросервисах Netcracker мы решаем эти проблемы с помощью GraphQl & apollo. Однако есть изрядное количество приложений, использующих классический REST подход для общения с сервером. Хорошим решением для них является Redux Toolkit Query.

Netcracker стремится оптимизировать разработку клиентской части приложений на React. В начале пути мы использовали JavaScript + redux + axios для работы с состоянием приложения. В целом все было неплохо, вот только количество повторяющегося кода в redux зашкаливало, да и отсутствие типизации с болью отзывалось при любых UI изменениях. На помощь пришли Typescript и Redux-toolkit, украсив типизацией и слайсами наши front-end будни.

В крупных компаниях решение стандартных проблем с REST обычно отнимает большое количество времени и сил разработчиков. Настало время это исправить с помощью Redux toolkit query.

Документация Redux toolkit query хороша в теоретической части, но не покрывает некоторых особенностей, с которыми мы сталкиваемся на реальных проектах.

На самом redux и redux-toolkit останавливаться не будем. (про редакс, про redux toolkit)

Также к вашему вниманию:
Базовый пример стандартного CRA приложения с RTK Query.

Обратите внимание на минимальное количество кода, необходимое при работе с состоянием приложения.

// Пример использования api export const exampleApi = commonApi.injectEndpoints({     endpoints: build => ({         fetchExampleList: build.query<ExampleModel[], number | void>({             query: (limit: number = 5) => ({                 url: '/example',                 params: {                     limit,                 },             }),             providesTags: result => [{ type: 'Example', id: 'List' }],         }),         createExample: build.mutation<ExampleModel, { example: Partial<ExampleModel> & { limit?: number } }>({             query: ({ example }) => ({                 url: '/example',                 method: 'POST',                 body: example,             }),             async onQueryStarted({ example }, { dispatch, queryFulfilled }) {                 try {                     const { data } = await queryFulfilled;                      dispatch(                         exampleApi.util.updateQueryData('fetchExampleList', example.limit, draft => {                             draft.unshift(data);                         })                     );                 } catch (e) {                     console.error('userApi createUser error', e);                 }             },         }),         updateExample: build.mutation<ExampleModel, { example: ExampleModel }>({             query: ({ example }) => ({                 url: `/example`,                 method: 'PUT',                 body: example,             }),             invalidatesTags: ['Example'],         }),         deleteExample: build.mutation<ExampleModel, { example: ExampleModel }>({             query: ({ example }) => ({                 url: `/example/${example.id}`,                 method: 'DELETE',             }),             invalidatesTags: ['Example'],         }),     }), }); 

Также на созданные с помощью RTK Query хуки, позволяющие стандартизовать обработку результатов и состояний запросов:

const { data: examples = [], isLoading: examplesLoading } = exampleApi.useFetchExampleListQuery(); const [createExampleMutation, { isLoading: createExampleLoading }] = exampleApi.useCreateExampleMutation(); const [deleteExampleMutation, { isLoading: deleteExampleLoading }] = exampleApi.useDeleteExampleMutation(); const [updateExampleMutation, { isLoading: updateExampleLoading }] = exampleApi.useUpdateExampleMutation();

Приступим к рассмотрению неявных особенностей данной библиотеки:

1) Использование common.api.ts

Следует создать common.api.ts в самом начале. (Тут nota bene, на момент написания статьи в RTK (версии === 1.6.2) typescript не генерировал хуки в случае импорта createApi не из ‘@reduxjs/toolkit/dist/query/react’ и typescript версии < 4.1).

CommonApi – сущность, которая будет хранить общие настройки. Ее удобно расширять остальными *api в приложении, которые автоматически получат baseUrl (будет добавляться ко всем запросам), headers (см. пример) и tagTypes (для инвалидации кешей).

// src/store/common.api.ts export const commonApi = createApi({     reducerPath: 'api',     baseQuery: fetchBaseQuery({         baseUrl: BASE_URL,         prepareHeaders: headers => {             headers.set('Content-Type', 'application/json;charset=UTF-8');             headers.set('Authorization', 'anonymous');              return headers;         },     }),     tagTypes: ['Example'],     endpoints: _ => ({}), });   // src/store/store.ts const rootReducer = combineReducers({ …     [commonApi.reducerPath]: commonApi.reducer, … });  export const store = configureStore({     reducer: rootReducer,     middleware: getDefaultMiddleware => getDefaultMiddleware().concat(commonApi.middleware),     … }); 

2) Расширение commonApi чанками.

Каждый новый *api создаем, расширяя базовый commonApi, при этом больше не надо изменять store.ts, что очень удобно!

// src/store/example/example.api.ts export const exampleApi = commonApi.injectEndpoints({     endpoints: …

3) Pessimistic & Optimistic Updates

В интернете обычно представлены примеры запросов RTK query с последующим сбросом его кешей. Рассмотрим случай добавления/удаления сущности. После каждого подобного запроса RTK query отправит дополнительный гет запрос, чтобы получить самое последнее состояние. На практике же дополнительный запрос ни к чему.  В зависимости от вашего мировоззрения (шутка) следует использовать pessimistic/optimistic обновление данных в кеш. Это избавит вас от ненужных запросов. В основном используем pessimistic обновление, после ответа сервера.

createExample: build.mutation<ExampleModel, { example: Partial<ExampleModel> & { limit?: number } }>({     query: ({ example }) => ({         url: '/example',         method: 'POST',         body: example,     }),     async onQueryStarted({ example }, { dispatch, queryFulfilled }) {         try {             const { data } = await queryFulfilled;              dispatch(                 exampleApi.util.updateQueryData('fetchExampleList', example.limit, draft => {                     draft.unshift(data);                 })             );         } catch (e) {             console.error('exampleApi createExample error', e);         }     }, }), 

4) Разница между onQueryStarted и queryFn

Часто при работе с асинхронными вызовами, до и после отправки запроса, необходимо осуществить дополнительное действие. Для этих целей стоит использовать onQueryStarted. Модифицировать запрос не получится, однако возможно отследить его состояние с помощью queryFulfilled.

fetchEntity: build.query<EntityModel, { id: string }>({     query: ({ id }) => ({         url: getEntityUrl(id),     }),     async onQueryStarted(arg, { dispatch, queryFulfilled }) {         try {             const result = await queryFulfilled;             dispatch(setEntityAction(result.data));         } catch (e) {             await const { unsubscribe } = dispatch(entityApi.endpoints.postEntityIdOnBE.initiate({ entityId: '' }));      unsubscribe();              console.error('fetchEntity error', e);         }     }, }), 

Если же требуется полностью контролировать запрос, добавить к нему хедеры, формировать тело запроса с использованием текущего состояния, сделать кастомный action (возможно вообще без запроса) – в этих случаях стоит использовать queryFn и встроенную обертку браузерного fetch – fetchWithBQ

deanonymizeCustomer: build.mutation<             CustomerModel,             { customer: CustomerInputModel }             >({             async queryFn({ customer }, { getState, dispatch }, extraOptions, fetchWithBQ) {                 const state = getState() as RootState;                 const customerId = state.customer?.id;                  if (!customerId) throw new Error('Deanonymize customer  error, no customerId');                  const body = getDeanonymizeCustomerData(customer);                  const result = await fetchWithBQ({                     url: getDeanonCustomerUrl(customerId),                     method: 'POST',                     body,                 });                  if (result.error) throw result.error;                  const data = result.data as CustomerModel;                  return { data };             },         }),

5) RTK query и его место в приложении

Стоит отметить, что RTK query не заменит работу с состоянием приложения полностью. К нему стоит относиться, как к помощнику для REST запросов. Этот помощник умеет решать ряд проблем и предоставляет удобный инструментарий для работы с кеш, что позволяет избавиться от большого количества повторяющегося кода. Однако в больших приложениях не все метаморфозы состояния линейны. Представим сценарий, что всему приложению нужна информация о пользователе. При этом гет запрос за пользователем зависит от нескольких параметров (locationId, distributionId и тд). Чтобы получить часть состояния с этим пользователем в RTK query, необходимо знать все параметры. Что делать если их неудобно получать в контейнере, которому нужна информация о пользователе? Если контейнер, делающий запрос за пользователем, уже не на странице? Если понадобится только id последнего полученного юзера? В таких случаях информацию стоит хранить в стандартном слайсе redux-toolkit и получать обычными селекторами, не перегружая код и умы разработчиков.

В итоге RTK query:

• помог уменьшить количество кода для работы с состоянием приложения;

• избавил нас от бойлерплейтов и кастомного кода при трекинге состояний и результатов запросов;

• решил проблему одновременных запросов за одними и теми же данными;

• из коробки позволил удобно работать с кеширования полученных данных на клиенте;

• удобно реализует pessimistic/optimistic обновления состояний.