Forem: Cristafovici Dan

Streamlining React: Utilizing React Query for Scalability

Cristafovici Dan — Mon, 06 May 2024 06:39:12 +0000

In the previous part, we set up all the necessary Axios configurations to make it easy to scale and maintain. In today’s part, we’ll install React Query and perform a similar setup to configure global and local variables.

React Query Configuration

First, let’s define our config file. In our API folder, we can create a file called queryClient.ts and define the configuration as follows. This is a basic configuration to start with, but we’ll add new properties later in the article.

import { QueryClient } from '@tanstack/react-query';

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 1,
      refetchOnWindowFocus: false,
    }
  }
});

The next step is to wrap our application with the React Query Provider as follows. The QueryClientProvider expects our config file as an argument. Additionally, we included the ReactQueryDevtools from the devtools extension.

import { ReactQueryDevtools } from "@tanstack/react-query-devtools";
import { queryClient } from "./api/queryClient";
import { QueryClientProvider } from "@tanstack/react-query";

<QueryClientProvider client={queryClient}>
  <ReactQueryDevtools initialIsOpen={false} />
  <Provider store={store}>
    <RouterProvider
      router={applicationBrowserRouter}
      fallbackElement={<Spin size="large" className="spinner" />}
     />
  </Provider>
</QueryClientProvider>

Query

The basic React Query configuration is now ready for use. The main principle of React Query, as shown in various sources such as tutorials and documentation, is to call the useQuery function, providing queryKey and queryFn. Typically, the documentation suggests providing the axios call directly in queryFn, which makes sense. However, as the project becomes more complex, it becomes challenging to maintain all the logic in a single place. To make our application easier to read and debug, the logic for fetching will be moved into a separate file. To understand the benefits of this approach, let’s first examine a similar call before refactoring to useQuery.

In this example, the fetchListOfProduct function is invoked when the component mounts for the first time and whenever specific properties change. The isLoading status is toggled to provide visual feedback to the user while the request is being processed. Inside the fetchProducts function, we await the completion of the request, perform necessary data transformations such as grouping by categories, and update the local state accordingly. Finally, based on the outcome of the request, we display relevant notifications or handle errors appropriately.

const fetchListOfProduct = () => {
  setIsLoading(true);
  const fetchProducts = async () => {
    const {
      data,
      counts: {
        foodCount = 0,
        supplementsCount = 0,
        vitaminsCount = 0,
        filterCount: filterCountResponse = 0,
      },
    } = await ProductService.getAllProducts({
      productCategoryId,
      offset,
      limit: PRODUCTS_QUERY_LIMIT,
      filters,
    });

    setCounts({
      [ProductCategoryId.FOOD]: foodCount,
      [ProductCategoryId.SUPPLEMENTS]: supplementsCount,
      [ProductCategoryId.VITAMINS]: vitaminsCount,
    });
    setFilterCount(filterCountResponse);
    setProducts(data);
    showNotification(NOTIFICATION_TYPE.SUCCESS);
  };

  fetchProducts()
    .catch((error) => {
      showNotification(NOTIFICATION_TYPE.ERROR, error.response.data.message);
    })
    .finally(() => setIsLoading(false));
};

useEffect(() => {
  fetchListOfProduct();
}, [productCategoryId, offset, filters]);

Agree that keeping all this code within our component can be hard to maintain, as the component not only includes simple fetch code but also handler logic functions and more. The main idea of the proposed structure is to introduce several layers between the component that renders and the server that responds with data. The aim is to establish the following chain:

Component -> React Query -> Intermediate data interceptor -> Axios -> Server.

So let’s call the useQuery function in our component. Using a destructuring method, we can already receive isPending (analog of our isLoading) and remove one unnecessary state and handling.

// config.ts 
export const MY_PRODUCTS_QUERY_KEY = "MY_PRODUCTS_QUERY_KEY";

const { data, isPending } = useQuery({
  queryKey: [MY_PRODUCTS_QUERY_KEY],
  queryFn: ...
});

Let’s create Query Classes akin to Axios Classes, acting as interceptors between Axios responses and useQuery. They’ll map data according to project needs

export default class ProductQueryMethods {
  public static readonly getAllProducts = async (
    query: GetAllProductsQueryResponse,
  ): Promise<ProductQueryResponse> => {
    const {
      data,
      counts: {
        foodCount = 0,
        supplementsCount = 0,
        vitaminsCount = 0,
        filterCount: filterCountResponse = 0,
      },
    } = await OrderService.getAllProducts(query);

    const counts = {
      [ProductCategoryId.FOOD]: foodCount,
      [ProductCategoryId.SUPPLEMENTS]: supplementsCount,
      [ProductCategoryId.VITAMINS]: vitaminsCount,
    };

    return { orders: data, counts, filterCount };
  };
}

And finally, our component looks much cleaner, easier to understand, and free from redundant code.

 const { data, isPending } = useQuery({
    queryKey: [MY_PRODUCTS_QUERY_KEY],
    queryFn: () =>
      ProductQueryMethods.getAllProducts({
        productStatusId,
        offset,
        limit: ORDERS_QUERY_LIMIT,
        filters,
      }),
  });

React Query is popular not just for providing the useQuery hook, its caching mechanism is a powerful tool to avoid unnecessary repeat requests to the server.

In our example with useEffect, we kept the data in local state. Every time one of the parameters changed, we made a repeated request to the server, replacing the previous data with new data. With React Query, we can keep data in the cache and retrieve it from there without making a new request.

In our example with products, we send offset and limit parameters to the server, typically for pagination. For instance, to see the first page with 20 results, we send a request with ?limit=20. When we move to the second page, we send ?limit=20&offset=20, and so on.

Returning to the second page sends another request with limit=20&offset=20. But does it make sense to retrieve new data if we already have the previous data in our cache? I think not.

So, how do we “enable” the cache? Actually, the cache is always enabled, the question is how to access it. The main principle of caching is to check the global store to see if there’s any data with the specified key and retrieve it (if not, retrieve it from the backend).

To retrieve the data, we need a unique key. The key is a significant part of the philosophy of React Query. In the previous example, we provided only one argument for queryKey, but you can see that it is an array, and we can extend it by adding three new properties:

const { data, isPending } = useQuery({
    queryKey: [MY_PRODUCTS_QUERY_KEY, offset, limit, productStatusId],
    queryFn: () =>
      ProductQueryMethods.getAllProducts({
        productStatusId,
        offset,
        limit: ORDERS_QUERY_LIMIT,
        filters,
      }),
  });

These keys will be concatenated into a unique key, and when one of the following properties changes, React Query attempts to retrieve the data using this key from cache storage or sends a request to the backend

But to make it work, there is a small prerequisite. In our queryConfiguration file, we need to adjust it with a new property: staleTime, which expects the value to be in milliseconds:

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      ...,
      staleTime: 30000,
    },
  },
});

The staleTime property gives query the idea of refreshing the request. I won’t delve too deeply into React Query properties as we have another topic, but in simple terms, it determines the lifetime of the request. In addition to my explanation of the caching mechanism, React Query checks if the request is not “outdated.” In our case, it is set to 30 seconds. If it is outdated, another request will be sent.

Mutation

Apart from fetching data, we also need to send it back, possibly in a modified form. For sending data, we’ll use the mutation hook. I prefer keeping these methods separate and calling them in the component. Mutations are named as hooks, and they aren’t grouped into a separate class.

import { UseMutationResult, useMutation } from "@tanstack/react-query";

export const useUpdateProductById = (): UseMutationResult<
  ProductsResponse,
  Error,
  UpdateProductPayload,
  void
> => {
  return useMutation({
    mutationFn: (data: UpdateProductPayload) => {
      const { id, ...rest } = data;
      return ProductService.updateProductById(id, rest);
    },
  });
};

In the component, our custom hook returns the mutate function (named updateProductById). It also provides the isPending argument, indicating the current request state. Additionally, we can pass an onSuccess callback as a second argument, executed upon a successful response, and use onError for error handling.

const { mutate: updateProductById, isPending } = useUpdateProductById();

const editCurrentProduct = (values: UpdateProductPayload) => {
  updateProductById(
    { ...values, id },
    {
      onSuccess: () => {
        fetchProducts();
        setModalIsOpen(false);
      },
      onError: () => {}
    }
  );
};

Setting Global Notifications

You may have noticed in the example with useEffect, which we refactored earlier in case of an error, I used notifications to show the status to the user. The problem was that I needed to import and call the same function every time. Let’s optimize this by moving it into the global scope. Returning to the queryClient configuration file, we can add these two new properties: queryCache for queries and mutationCache for mutations. Each of them will receive onSuccess and onError callbacks depending on the status of the request.

export const queryClient = new QueryClient({
  defaultOptions: {
   ....
  },
  queryCache: new QueryCache({
    onSuccess: (_data: unknown, query: Query<unknown, unknown, unknown, QueryKey>): void => {
     // ...
    },
    onError: (error: unknown, query: Query<unknown, unknown, unknown, QueryKey>): void => {
      // ...
    }
  }),
  mutationCache: new MutationCache({
    onError: (
      error: unknown,
      _variables: unknown,
      _context: unknown,
      mutation: Mutation<unknown, unknown, unknown, unknown>
    ): void => {
     / ...
    },
    onSuccess: (
      _data: unknown,
      _variables: unknown,
      _context: unknown,
      mutation: Mutation<unknown, unknown, unknown, unknown>
    ): void => {
      // ...
    }
  })
});

These global settings will be invoked every time when the useQuery or useMutation is executed. However, in a real project, we may not need to show the notification for every request. In this case, we can handle different scenarios. Firstly, for our query, we can add a new property called meta:

const { data, isPending } = useQuery({
    ...,
    meta: {
      ERROR_SOURCE: "[Products Failed]",
      SUCCESS_MESSAGE: "All products have been successfully received",
    },
  });

And similarly for mutation:

export const useUpdateProductById = (): UseMutationResult<
  ProductsResponse,
  Error,
  UpdateProductPayload,
  void
> => {
  return useMutation({
    ...,
    meta: {
      ERROR_SOURCE: "[Update product failed]",
      SUCCESS_MESSAGE: "The product has been successfully updated",
    },
  });
};

Now we can adjust our global config to look like this:

export const queryClient = new QueryClient({
  ...,
  queryCache: new QueryCache({
    onSuccess: (_data: unknown, query: Query<unknown, unknown, unknown, QueryKey>): void => {
      if (query.meta?.SUCCESS_MESSAGE) {
        toast.success(`${query.meta.SUCCESS_MESSAGE}:`);
      }
    },
    onError: (error: unknown, query: Query<unknown, unknown, unknown, QueryKey>): void => {
      if (axios.isAxiosError(error) && query.meta?.ERROR_SOURCE) {
        toast.error(`${query.meta.ERROR_SOURCE}: ${error.response?.data?.message}`);
      }
      if (error instanceof Error && query.meta?.ERROR_SOURCE) {
        toast.error(`${query.meta.ERROR_SOURCE}: ${error.message}`);
      }
    }
  }),
  mutationCache: new MutationCache({
    onError: (
      error: unknown,
      _variables: unknown,
      _context: unknown,
      mutation: Mutation<unknown, unknown, unknown, unknown>
    ): void => {
      if (axios.isAxiosError(error) && mutation.meta?.ERROR_SOURCE) {
        toast.error(`${mutation.meta.ERROR_SOURCE}: ${error.response?.data?.message}`);
      }
      if (error instanceof Error && mutation.meta?.ERROR_SOURCE) {
        toast.error(`${mutation.meta.ERROR_SOURCE}: ${error.message}`);
      }
    },
    onSuccess: (
      _data: unknown,
      _variables: unknown,
      _context: unknown,
      mutation: Mutation<unknown, unknown, unknown, unknown>
    ): void => {
      if (mutation.meta?.SUCCESS_MESSAGE) {
        toast.success(`${mutation.meta.SUCCESS_MESSAGE}:`);
      }
    }
  })
});

This example demonstrates how I handled notifications. If the specific meta parameter is provided in the query or mutation, the toast notification will be invoked. This approach avoids code duplication and keeps all the settings in the same part.

These two articles were aimed to share with you the way to handle communication with the server in a more efficient way, and I hope they will inspire you to try new things in your project.

Axios: Setup, Configuration, and Structuring

Cristafovici Dan — Mon, 06 May 2024 06:38:22 +0000

Data fetching remains one of the most important parts of each application. The times when a simple landing page with static information could generate leads are gone. Nowadays, modern applications are purely focused on exchanging data between the client and server.

In this article, I’ve described my personal approach to creating a scalable and easy-to-maintain solution for data fetching. By incorporating data caching mechanisms, interceptors, and a state manager into your project, you can enhance its efficiency.

Just a heads up, the article won’t go through every single line of code. It’s more about showing you how to use Axios and React Query together in a better way. I assume you’re already familiar with both tools, so let’s dive into structuring and use them together.

Axios base setup

To configure the base setup of Axios, we call the axios module and apply the create method. Currently, we only provide two options: baseURL (the main path to the server) and default headers for the client.



export const client = (() => {
  return axios.create({
    baseURL: process.env.REACT_BASE_URL,
    headers: {
      Accept: "application/json, text/plain, */*",
    },
  });
})();

Please note that the function “client” is an immediately invoked function expression, which means it’s called right after being defined. It’s crucial to create an instance of the axios query only once, when the axios module is loaded. This follows the singleton pattern commonly used in JavaScript.



const request = async (options: AxiosRequestConfig) => {
  const onSuccess = (response: AxiosResponse) => {
    const { data } = response;
    return data;
  };

  const onError = function (error: AxiosError) {
    return Promise.reject({
      message: error.message,
      code: error.code,
      response: error.response,
    });
  };

  return client(options).then(onSuccess).catch(onError);
};

export default request;

In the request, we have two different functions: onSuccess and onError. Each of them returns an Axios instance of Response/Error. Using the promise structure, we call then when the request is successful and the catch when the request fails. This approach offers two powerful advantages:

We can restructure data in case of a successful response, helping us avoid code duplication.
We can return custom error messages in case of a failed request, enabling us to adjust the error messages according to the specifications of our project.

Axios Interceptors

Request Interceptor:



client.interceptors.request.use(
  (config: InternalAxiosRequestConfig) => {
    const accessToken = localStorage.getItem(STORAGE_TOKEN.ACCESS_TOKEN);
    if (accessToken) {
      config.headers.Authorization = `Bearer ${accessToken}`;
    }
    return config;
  },
  (error: AxiosError) => {
    return Promise.reject(error);
  },
);

Before the client sends the request to the server, it can be modified. In the following example, we retrieve the accessToken from LocalStorage and set it in the global config, which we receive as a parameter for our function. After adding the Bearer token, we return the modified config. This step is necessary because if it is a restricted UI (dashboard, admin panels, etc.), all requests require authorization. Additionally, note that in case of an error, we can return Promise.reject with the occurred error.

Response interceptor:



client.interceptors.response.use(
  (res: AxiosResponse) => {
    return res; // Simply return the response
  },
  async (err) => {
    const status = error.response ? error.response.status : null;

    if (status === 401) {
      try {
        const refreshTokenFromStorage = localStorage.getItem(
          STORAGE_TOKEN.REFRESH_TOKEN
        );
        const { accessToken, refreshToken } = await AuthService.refresh(
          refreshTokenFromStorage
        );

        LocalStorageService.setTokens(accessToken, refreshToken);
        client.defaults.headers.common.Authorization = `Bearer ${accessToken}`;

        return await client(originalConfig);
      } catch (error: AxiosError) {
        return Promise.reject(error);
      }
    }

    if (status === 403 && err.response.data) {
      return Promise.reject(err.response.data);
    }

    return Promise.reject(err);
  }
);

In the second interceptor, we already modify the data received from the server. If the server responds correctly, we simply return the response. However, if there’s an error, we take specific actions. Firstly, we need to identify the error sent by the server, typically done by checking standardized statuses. In the following code, we check the status to determine the appropriate action. If it’s a 401 error, we refresh tokens using refreshToken, which has a longer expiry period. For a 403 error, we throw a Forbidden Error. This is an example of how we can globally handle every request. Keep in mind that based on your project specifications, you can handle errors in any desired way. If your server sends specific errors, you can handle them based on other parameters.

Project structure

So far, we’ve learned how to set up the Axios configuration to make it easily changeable, customizable, and scalable. The final part of the Axios configuration would be an example of how to structure and use the configured request.

Configuration file

This is the basic structure of our config.ts file. It keeps the endpoints as constants in the form of key-value pairs. The value is a function, allowing us to easily manage and call them, providing the necessary parameters when needed.



export const ProductEndpoints = {
  getMyProducts: () => "product/me",
  getProduct: (id: string | number) => `product/${id}`,
  getProductsFromOrder: (orderToken: string) => `/product/order-products?token=${orderToken}`,
};

Service file

Let’s look at the service file. We group API calls by business domain into a class, all related to products in our case. Each method calls a specific endpoint using a function from the config file as the URL. When sending query parameters, we provide them as parameters to avoid sending incorrect strings with empty parameters.



export default class ProductService {
  public static readonly getMyProducts = ({
    offset,
    limit,
    textFilter,
  }: ProductQueryParams): Promise<Product[]> => {
    return request({
      url: ProductEndpoints.getMyProducts(),
      method: AxiosMethod.GET,
      params: {
        limit,
        offset,
      },
    });
  };

  public static readonly getProduct = (
    id: string | number,
  ): Promise<Product> => {
    return request({
      url: ProductEndpoints.getProduct(id),
      method: AxiosMethod.GET,
    });
  };

  public static readonly getProductsFromOrder = (
    token: string,
  ): Promise<Product[]> => {
    return request({
      url: ProductEndpoints.getProductsFromOrder(token),
      method: AxiosMethod.GET,
    });
  };
}

This concludes Part 1. We performed the initial Axios configuration, set up interceptors, and established the folder structure for API calls. In Part 2 ,we’ll implement queries and mutations (using React Query) in our project and set up some global configurations.