DEV Community: Xuan

Enhancing User Experience with Daxus

Xuan — Sat, 29 Jul 2023 10:28:48 +0000

Daxus is an exceptional server state management library tailored for React applications. With Daxus, developers have complete control over their data, allowing them to craft websites with superior user experiences.

Building a Better User Experience with Daxus

Let's consider the scenario of developing a forum website. Our website comprises various lists of posts, such as "popular," "latest," "recommended," and more. Users can interact with the posts, for example, by liking them, and the post will display the total number of likes.

Initially, we might opt for React Query to manage the server data. Here's an example of how we could use React Query:

import { useQuery, useInfiniteQuery } from '@tanstack/react-query';

export function usePost(id: number) {
  return useQuery({
    queryKey: ['post', 'detail', id],
    queryFn: () => axios.get(`/api/post/${id}`)
  });
}

export function usePostList({ forumId, filter }: { forumId: string; filter: 'popular' | 'latest' | 'recommended' }) {
  return useInfiniteQuery({
    queryKey: ['post', 'list', forumId, filter],
    queryFn: ({ pageParam = 0 }) => axios.get(`/api/post?page=${pageParam}&forumId=${forumId}&filter=${filter}`),
    getNextPageParam: (lastPage, pages) => lastPage.nextCursor
  });
}

React Query provides the useQuery and useInfiniteQuery hooks to simplify data handling. With just the queryKey and queryFn, React Query efficiently manages the data for us.

Now, let's address the logic of users liking a post:

import { useMutation, useQueryClient } from '@tanstack/react-query';

export function useLikePost(id: number) {
  const client = useQueryClient();

  return useMutation({
    mutationFn: () => {
      return likePostApi({ id });
    },
    onSuccess: () => {
      client.invalidateQueries({ queryKey: ['post'] });
    }
  });
}

When a user likes a post, we invalidate all post data, triggering a refetch of the post the user is currently viewing. Moreover, when the user returns to the post list, it is also refetched, displaying the updated like count.

However, there is a noticeable delay between the user liking a post and the post displaying the updated like count. To address this in the post view, we can implement optimistic updates:

export function useLikePost(id: number) {
  const client = useQueryClient();

  return useMutation({
    mutationFn: () => {
      return likePostApi({ id });
    },
    onMutate: async () => {
      await client.cancelQueries({ queryKey: ['post', 'detail', id] });
      client.setQueryData(['post', 'detail', id], (old) => ({ ...old, likeCount: old.likeCount + 1 }));
    },
    onError: () => {
      client.setQueryData(['post', 'detail', id], (old) => ({ ...old, likeCount: old.likeCount - 1 }));
    },
    onSettled: () => {
      client.invalidateQueries({ queryKey: ['post'] });
    }
  });
}

Now, users can immediately see the result after liking a post. However, when they return to the post list, they still see the old post data. They have to wait for some delay to see the latest result. Considering the multiple lists on our website, finding the post in every list and then performing an optimistic update isn't efficient.

Daxus to the Rescue!

Enter Daxus! With Daxus, we can create a custom data structure for our post data, ensuring that each post entity references the same data. This feature allows us to eliminate the delay issue without any hassle. Let's see how we can use Daxus to manage the post data:

import { createDatabase, createPaginationAdapter, useAccessor } from 'daxus';

export const database = createDatabase();

export const postAdapter = createPaginationAdapter<Post>();

export const postModel = database.createModel({name: 'post', initialState: postAdapter.initialState});

export const getPost = postModel.defineAccessor({
    name: 'getPost',
    async fetchData(id: number) {
        return axios.get(`/api/post/${id}`);
    },
    syncState( draft, { data } ) {
        postAdapter.upsertOne(draft, data);
    }
})

export const listPost = postModel.defineInfiniteAccessor({
    name: 'listPost',
    async fetchData({forumId, filter}: {forumId: string, filter: 'popular' | 'latest' | 'recommended'}, {previousData}) {
        const page = previousData?.nextCursor ?? 0;
        return axios.get(`/api/post?page=${page}&forumId=${forumId}&filter=${filter}`);
    },
    syncState( draft, { data, arg: { forumId, filter} }) {
        const key = `${forumId}&${filter}`;
        postAdapter.appendPagination(draft, key, data);
    }
})

export function usePost(id: number) {
    return useAccessor(getPost(id), state => postAdapter.tryReadOne(state, id));
}

export function usePostList({forumId, filter}: {forumId: string, filter: 'popular' | 'latest' | 'recommended'}) {
    return useAccessor(listPost({forumId, filter}), state => {
        const key = `${forumId}&${filter}`;
        return postAdapter.tryReadPagination(state, key)?.items
    });
}

export async function likePost(id: number) {
    postModel.mutate(draft => {
        postAdapter.readOne(draft, id).likeCount += 1;
    })

    try {
        await likePostApi({id});
    } catch {
        postModel.mutate(draft => {
            postAdapter.readOne(draft, id).likeCount -= 1;
        })
    } finally {
        postModel.invalidate();
    }
}

In Daxus, we provide the necessary instructions on how to update our state after fetching the data from the server. The createPaginationAdapter function returns an object with operations for accessing pagination data. If we need a more customizable data structure, we can build our adapter as well.

Since each entity in the pagination data structure references the same data, when a user likes a post and returns to any list, they will immediately see whether they have liked that post. No delays, no fuss - just a seamless user experience!

For more detailed information and code examples, please visit the Daxus GitHub repository.

Daxus is continually evolving, and your valuable feedback is crucial to making it even better! Give Daxus a try and share your thoughts with us! Let's create remarkable React applications together!

Discover the Power and Simplicity of Daxus: Take Control of Your Data with Ease

Xuan — Tue, 18 Jul 2023 09:52:16 +0000

Hello everyone, as the creator of Daxus, I am thrilled to introduce this powerful tool to the developer community. In this article, I want to share with you the motivation behind developing Daxus and why you should give it a try.

Daxus is a server state management package specifically designed for React applications. It empowers developers to take full control of their data and build a single source of truth effortlessly. With Daxus, you can easily create a structured data model that perfectly suits your application's needs.

One of the key advantages of using Daxus is the ability to establish a single source of truth for your data. This means that you have a centralized data source that reflects the true state of your application. By managing the server state yourself, you can ensure consistency and eliminate data inconsistencies that may occur with other approaches.

But that's not all. Daxus also offers a fantastic feature called the Lazy Model. This feature is specifically designed for scenarios where you don't need to customize the data structure extensively. With the Lazy Model, you can effortlessly handle data that doesn't require complex structures. It simplifies the process by taking care of data synchronization internally, allowing you to focus on building your application without the need for additional code.

To get started with Daxus, all you need to do is create a model and define the corresponding accessors. The intuitive API and documentation will guide you through the process, making it easy to integrate Daxus into your React projects.

By using Daxus, you gain the power to efficiently manage your data and establish a solid foundation for your application. Whether you're building a small project or a large-scale application, Daxus provides the flexibility and control you need to create robust and scalable solutions.

I encourage you to give Daxus a try in your next project. You'll be amazed at how it simplifies data management and enhances the development experience. Join our community on GitHub, where you can find the official Daxus repository here. We welcome your feedback, questions, and contributions as we strive to make Daxus even better.

Thank you for considering Daxus as your go-to data management solution. Together, let's unlock the full potential of our applications with ease and efficiency.

Happy coding with Daxus!

Lazy Model in Daxus

Xuan — Thu, 13 Jul 2023 07:14:36 +0000

In Daxus, developers have the flexibility to manage state updates themselves, allowing for customized state structures such as pagination for a single source of truth. However, not all data requires a custom data structure. For most data, we simply need to record the fetched data without worrying about how it is synced to the model's state.

To simplify the code required for such scenarios, Daxus introduces a new feature called "Lazy Model". Let's explore how to use this feature.

Creating a Lazy Model

const lazyModel = createLazyModel();

const getUser = lazyModel.defineNormalAccessor<string, User>({
  fetchData: async (userId) => {
    return getUserApi(userId);
  },
});

function useUser(userId: string) {
  return useLazyAccessor(getUser(userId));
}

When using createLazyModel, there's no need to provide an initial state, and you don't have to create an adapter since you don't need to manage how the fetched data is synced to the model's state.

It is recommended to use the useLazyAccessor hook with accessors defined using the lazy model. This hook allows easy access to the cached data without the need for a getSnapshot function. However, if desired, you can still provide a getSnapshot function to select specific data:

function useUserName(userId: string) {
  return useLazyAccessor(getUser(userId), (user) => user?.name);
}

Mutating Data

The lazy model also provides a mutate method, but it functions slightly differently from the original model. Developers need to provide an accessor to access the corresponding cached data:

lazyModel.mutate(getUser(userId), (prevUser) => {
  return { ...prevUser, name: 'new user name' };
});

Note that when using the lazy model, it is important to return a new data object instead of directly mutating the cached data.

Retrieving State

To retrieve the cached state, you can use the getState method with the corresponding accessor:

lazyModel.getState(getUser(userId)); // Returns User | undefined

Limitations

When using the lazy model, there is a trade-off in terms of control over the model's state. The data is bound to the accessor, and its definition is derived from the return value of the fetchData function.

It is recommended to use only one lazy model in your app and avoid using accessors generated by a normal model with the mutate or getState methods. These methods have different internal behaviors and may not function as expected when used with accessors from other models.

Build a Single Source of Truth by Using Daxus!

Xuan — Sat, 08 Jul 2023 13:37:12 +0000

I'm excited to introduce Daxus I've developed to the community. In this article, I would like to simply share with everyone the motivation behind creating Daxus.

First of all, Daxus is a server state management package that make developer have full control over their data such that they can build a single source of truth by themselves.

Someone may ask: why don't you just use React Query or SWR?

In my company, we use redux with async thunk to manage the server state and implement single source of truth by ourselves. Take post as example, suppose there are two lists contain the post with the same id. This post share the same reference in the redux. That is, if the user update this post, the two posts will update simultaneously, and we don't need to make an extra request to refetch the whole post lists.

React Query encourages us invalidate the query if we have some data updated, which means that we need to refetch the whole list. However, refetch the two list just because we update a single post seems wasteful. We hope that we don't need to refetch the lists, but the same post in the both list should update also.

That is why I develope Daxus. You can find more details about the motivation in the readme also. Feel free to see it. https://github.com/jason89521/daxus#development-motivation

If you find this project interesting, also welcome to give it a star. It would be a tremendous encouragement to me. At the same time, I also hope that I can persuade my colleagues to adopt Daxus to our codebase. Thanks for your reading!

There is a question that I'm often asked:

Q: Why don't you just use queryClient.setQueryData?
A: In the pratical cases, we have not only two lists of the posts. If we consider update all these lists, it may be a disaster. Someone may ask, how about queryClient.setQueriesData? The answer is that the type is too dynamic. For more information, you can read this article.

If you have any question, I recommend read the motivation first. It provide more detail of why I want to develope Daxus. Thanks for reading!

Daxus - A New Server State Management Library for React

Xuan — Thu, 06 Jul 2023 03:38:21 +0000

Previously, I named the package React Server Model, but I wasn't quite satisfied with the name. The reason is that it's not unique enough and can easily be confused with React Server Component. Now, I have renamed it to "Daxus," which is a combination of "data" and "nexus." I'm very happy with this name because it's distinctive enough.

Daxus is a React server state management package that emphasizes giving developers complete control over their data. If you need to establish a single source of truth, Daxus would be a great choice.

	`Daxus`	`React Query`	`Redux With Async Thunk`
Customizable data structure	✅	❌	✅
Dedupe	✅	✅	❌
Revalidate on focus	✅	✅	❌
Revalidate on reconnect	✅	✅	❌
Revalidate if stale	✅	✅	❌
Polling	✅	✅	❌
Error retry	✅	✅	❌
Invalidate queries	✅	✅	❌
Mutation	✅	✅	✅
Conditional fetching	✅	✅	❌
DevTool	❌	✅	✅

If you find this project interesting, please leave your star. It would be a tremendous encouragement for me. Thank you. Here is the repo of Daxus: https://github.com/jason89521/daxus

Daxus v0.3.0 is released!

Xuan — Sun, 18 Jun 2023 15:15:05 +0000

TL;DR

Daxus is a new server state management library for React. It allow developer to customize the data like using Redux, while also provide an easy-to-use api like React Query's useQuery. Try it out!

Hi everyone, it feels like it's been a while since we last talked, even though it's only been a little over a week. Since my last article, I've been fully immersed in developing Daxus. Today, I'm excited to announce the release of Daxus version 0.3.0, along with the basic API documentation. I want to express my gratitude for all the encouragement I've received from you, whether it's the interactions on social media or the stars on the Daxus repository on GitHub. Your support has been a great motivation for me, thank you! (Especially the stars, they really get me excited.)

Now, let's dive into the specific features that Daxus provides.

Fully Customizable Data

This is where Daxus differs the most from React Query. Daxus allows developers to define their desired data structures, similar to using Redux. Developers can tailor the data structures to their specific needs. However, this feature also comes with some trade-offs. Since the data is managed by the developers, Daxus is not aware of how to update the cache after fetching data. Therefore, when using Daxus, you need to inform it about how you want to update the cache. If fully customizable data is not your primary concern, using React Query to manage the server state may be more suitable.

Adapter

When using Daxus, I recommend developers create an adapter for the models. This adapter provides the initial state values and various operations for the state, such as read and write. Creating an adapter can be cumbersome, so Daxus currently includes support for a pagination adapter, inspired by our company's approach. This adapter should suffice for most pagination scenarios.

Since my initial goal was to address pagination, Daxus currently only supports the pagination adapter. However, in the future, additional adapters will be added to meet other requirements. I also welcome any ideas you may have.

Deduplication

In Redux, deduplication can also be achieved. In my company, we write code like this:

export const listAchievementBadge = createAsyncThunk<
  { items: BasicAchievementBadge[] },
  ListAchievementBadgePayload
>(
  `${ACHIEVEMENT_BADGE}/list`,
  (ctx, { lang }) => {
    const res = await listAchievementBadgeApi({lang});
    return {items: res.items}
  },
  {
    modifiers: [throttle(10000, { keySelector: (_, { lang }) => lang })],
  }
);

throttle(10000) means that the same action won't be dispatched within 10 seconds, and keySelector is used to determine whether the actions are the same. Usually, most APIs require deduplication, so adding throttle to each new action can be quite cumbersome. Moreover, it's important not to forget to define the keySelector, otherwise, every dispatch of the action will be considered unique. I once forgot to add keySelector and ended up with excessive API calls after the product went live.

Daxus automatically handles deduplication, so you don't have to worry about repeated requests being continuously dispatched.

Revalidate On Focus/Reconnect

Just like React Query's refetchOnWindowFocus and refetchOnReconnect, Daxus also provides these features to enhance the user experience.

My company hasn't implemented this feature with Redux, but I think it would be quite troublesome.

Polling

If you want to fetch data from the backend at regular intervals, Daxus also offers polling functionality. You just need to tell Daxus how often to fetch data, and it will handle it automatically for you.

Error retry

When encountering an error while fetching an API, you can simply throw an error, and Daxus will automatically retry until the defined number of attempts is reached before throwing the error. Of course, you can also disable this feature so that a single API failure is considered a failure and shown to the user.

Invalidate data

Currently, Daxus only supports invalidating a single piece of data and doesn't have the ability to invalidate multiple data entries at once, like React Query. For example, if you have query keys like the following:

['posts', 'list', 'all']
['posts', 'get', 1]

Using queryClient.invalidateQueries({queryKey: ['post']}) will mark all the mentioned data as stale. This is a great feature, and Daxus is expected to support similar functionality in the future.

Written in TypeScript

Using TypeScript has become a standard practice for packages nowadays. Writing code with TypeScript provides a more pleasant development experience.

Getting Started

After discussing all of that, I believe many of you may still be unsure about how to use Daxus (since there was no related code mentioned above). Now, let's dive into how to actually utilize Daxus!

Create Model

Unlike Redux, where data is centralized in the store, Daxus requires developers to categorize data and create different models for different data types. For example, in our company, we have data types like posts, comments, and forums, so we need to create separate models for them. The reason behind this is that different data types may require different data structures. For example, posts may be suited for a pagination data structure, but user settings may not be.

import { createPaginationAdapter, createModel } from 'react-server-model';

const postAdapter = createPaginationAdapter<Post>();
const postModel = createModel(postAdapter.initialState);

Accessor with `useAccessor` hook

Once the model is created, you can start defining accessors. Accessors play a crucial role in Daxus. They fetch data from the server and synchronize it with your model. After your model is updated, it notifies the components that use the corresponding model to check if a rerender is needed.

const getPostById = postModel.defineAccessor<number, Post>('normal', {
    fetchData: async (id) => {
        const data = await getPostApi(id);
        return data;
    },
    syncState: (draft, payload) => {
        postAdapter.upsertOne(draft, payload.data);
    }
})

The first argument of the defineAccessor method accepts only 'normal' or 'infinite'. Usually, you only need to use 'infinite' when implementing infinite loading. In most cases, using 'normal' is sufficient.

The second argument is the accessor's action. fetchData tells the accessor how to fetch data from the server, and syncState specifies how to sync the received data with the model's state.

The defineAccessor method returns an accessor creator function. If you pass the same arguments, it will return the same accessor. Now, let's use the accessor created by defineAccessor with the useAccessor hook.

function usePost(id: number) {
    const accessor = getPostById(id);
    const { data, error, isFetching } = useAccessor(accessor, state => postAdapter.tryReadOne(state, id));

    return { post: data, error, isFetching, revalidate: () => accessor.revalidate() };
}

The second argument of useAccessor determines the shape of data. You can think of it as a selector function in Redux. In Daxus, we call this parameter getSnapshot because it provides a snapshot of the model's state. If you only want to retrieve the title of a specific post, you can write it like this:

function usePostTitle(id: number) {
    const accessor = getPostById(id);
    const { data } = useAccessor(accessor, state => postAdapter.tryReadOne(state, id)?.title);

    return data;
}

Although both hooks subscribe to the same accessor, they will rerender at different times due to the difference in the second argument. usePost will rerender when the corresponding post data for the given id changes, while usePostTitle will only rerender when the title of the corresponding post with the given id changes.

It's important to note that getSnapshot is tied to the accessor. You must ensure that the props and state used in getSnapshot are the necessary parameters for the accessor creator. Otherwise, you may encounter unexpected behavior. In the above example, only id affects the accessor, so only id can be included in getSnapshot. You can think of this limitation as similar to the dependencies array in useEffect.

In addition to being used with useAccessor, accessors themselves have some methods that can be used, such as accessor.revalidate used in usePost. If there is no ongoing revalidation process for the accessor, calling this method will fetch data and synchronize it with the model.

Benefits of Customized Data

Now, let's explore how Daxus addresses the issues mentioned in my previous article.

Readers who are not familiar can refer to this article.

First, let's define getPostList.

const getPostList = postModel.defineAccessor<string, Post>('infinite', {
    fetchData: async (filter, { previousData }) => {
        if (previousData.length === 0) return null;
        const data = await getPostListApi(filter);
        return data;
    },
    syncState: (draft, payload) => {
        postAdapter.appendPagination(draft, payload.filter, payload.data);
    }
})

getPostList fetches different post lists based on different filter values and stores these lists in the model's state.

Suppose we individually fetched paginations with filter values of 'latest' and 'popular', and both lists contain a post with the ID of 100. Now, if a user leaves a comment on this post and we execute the following code:

postModel.mutate(draft => {
    postAdapter.readOne(draft, 100).totalCommentCount += 1;
})

When the user switches to the popular list, they will see that the total comment count of the post with ID 100 has been updated. If they then switch to the latest list, they will also see the same result. All of this is possible thanks to the customized data structure in Daxus. In the pagination adapter, all entities are managed centrally, and pagination claims data based on IDs. Therefore, whenever an entity is updated, any pagination that includes that entity will be updated as well. This perfectly solves the problem mentioned earlier.

Conclusion

Although Daxus is not yet a mature package, I will continue to improve it. In addition, I have managed to persuade senior members in our company to apply it to our products. I hope it can help us completely eliminate Redux.

Finally, I want to express my gratitude once again to the community. Without your encouragement and practical support, the senior members of our company might not have agreed to let me do this. It's thanks to your recognition of Daxus that I was able to seize this opportunity. Thank you very much! I also hope that Daxus can help readers who are looking for alternative solutions. Have a wonderful day!

Introducing Daxus - The Design Philosophy

Xuan — Sun, 11 Jun 2023 10:48:07 +0000

The Design Philosophy Behind Daxus

This article is also included in https://github.com/jason89521/daxus#design-philosophy

Using Redux has its advantages, especially when it comes to customizing data structures. In our company, pagination is one of the most frequently used data structures for various entities like posts, comments, and forums. To simplify the process of creating paginations, our senior engineer developed a createPaginationAdapter function.

The state type returned by createPaginationAdapter is defined as follows:

export interface Pagination {
  noMore: boolean;
  index: EntityId[];
  loading: boolean;
  fetched: boolean;
  error?: any;
}

export interface PaginationState<T> {
  data: Record<EntityId, T | undefined>;
  paginations: Record<string, Pagination | undefined>;
}

PaginationState consists of two properties: data and paginations. data stores all the entity data, while paginations keeps track of the pagination states and the associated IDs.

To illustrate, let's consider the example of managing posts. When retrieving the list of posts without any filters, the API endpoint would look like /api/posts?filter=all, and the corresponding pagination key would be filter=all. Suppose the API returns the first page of posts with IDs 1 to 5. In this case, paginations["filter=all"] would contain the following:

{
    noMore: false,
    index: [1, 2, 3, 4, 5],
    loading: false,
    fetched: true
}

The data object would store the actual post data:

{
    1: {
        // post data
    },
    // and so on
}

To access the pagination for filter=all, we can use the object obtained from createPaginationAdapter:

const postAdapter = createPaginationAdapter();

function usePost() {
  const postPagination = useSelector(state =>
    postAdapter.selectByPagination(state.post, 'filter=all')
  );
  return postPagination;
}

At this point, you might think, "Isn't this similar to RTK's createEntityAdapter?" Indeed, there are similarities between the two, but createPaginationAdapter is an enhanced version specifically designed for pagination data. Now, let's delve into its most significant advantage.

Do you remember when React Query fails to meet our needs? Yes, it's when we have multiple paginations that might include the same post. React Query cannot handle this scenario effectively, but the pagination adapter perfectly solves this problem. By centralizing all the data in data and using paginations to collect the associated IDs, any updates to a specific post will automatically reflect in all the paginations containing that post. There won't be any inconsistencies.

So, what is the design philosophy behind Daxus?

The answer lies in customized data structures.

Every application has unique requirements for data structures. In our company, we designed PaginationState to fulfill our needs. Daxus's design philosophy empowers developers to define and use data structures tailored to their specific requirements. You only need to invest effort in creating suitable adapters and instructing Daxus on how to fetch data and synchronize it with your model. Daxus takes care of the rest, including deduplication, revalidation, and more.

However, creating an adapter does require some code, so Daxus also strives to provide pre-built adapters that cater to most use cases. If you have any new data structures in mind that Daxus doesn't support yet, we welcome your suggestions, and we'll make an effort to implement them.

Currently, Daxus only offers createPaginationAdapter, and I haven't thought of other forms of data structures. If you have any ideas, please let me know!

You can give Daxus a try and provide me with any feedback. Thank you!

The repo of Daxus: https://github.com/jason89521/react-server-model

I'm developing a new server state management library for React.

Xuan — Sat, 10 Jun 2023 09:55:46 +0000

I'm excited to introduce the Daxus tool I've developed to the community. In this article, I would like to share with everyone the motivation behind creating Daxus.

In my company, we use Redux with async thunk to manage server state. While Redux brings many benefits with centralized state management, it also comes with some drawbacks. For example, combining all reducers into a single store leads to excessively large initial JavaScript files. Additionally, even with Redux Toolkit, we still need to write a lot of repetitive code. As a result, senior engineers in the company have been considering replacing Redux, but so far, we haven't found a suitable package.

Why not use SWR or React Query?

Actually, we have tried incorporating both SWR and React Query into our internal console-type websites, and colleagues find React Query to be more user-friendly than SWR. Although React Query performs well in console-type products, most colleagues believe it is not quite suitable for our main product website.

Our product is a user forum that receives a large number of user visits every day. Here's an example that colleagues think React Query is not suitable for our product: when a user creates a new comment, we want the corresponding post's totalCommentCount to increase by one. From the perspective of React Query, we should execute the following code after creating a comment:

queryClient.invalidateQueries({ queryKey: ['posts', 'get', postId] });

This way, React Query will automatically request the new post in the background and update the corresponding post. However, considering that our post response is quite large, fetching the entire post just for updating totalCommentCount seems wasteful. You might think we can do it this way instead:

queryClient.setQueryData(['posts', 'get', postId], oldPost => {
  const totalCommentCount = oldPost.totalCommentCount + 1;
  return { ...oldPost, totalCommentCount };
});

But there's a problem with this approach. When the user goes back to the post list, the totalCommentCount on the list won't update because the queryKey is different. This may appear odd to observant users. Of course, we can add more code like this:

queryClient.setQueryData(['posts', 'list'], oldPosts => {
  const oldPost = oldPosts.find(post => post.id === postId);
  if (!post) return oldPosts;
  const totalCommentCount = oldPost.totalCommentCount + 1;
  const newPost = { ...oldPost, totalCommentCount };
  const oldPostIndex = oldPosts.indexOf(oldPost);
  const newPosts = [...oldPosts];
  newPosts.splice(oldPostIndex, 1, newPost);
  return newPosts;
});

This way, we take into account the scenario of updating the list. But is it really that simple? Our list can have various forms, such as "popular," "latest," and different forums with their own lists. The queryKey might look like this:

const allPopular = ['posts', 'list', 'popular', 'all'];
const allLatest = ['posts', 'list', 'latest', 'all'];
const forumPopular = ['posts', 'list', 'popular', forumId];
const forumLatest = ['posts', 'list', 'latest', forumId];

If we also consider all these scenarios, it might bring us even more mental burden than using Redux, not to mention some API responses have this format:

{
  "items": [],
  "nextKey": "123"
}

If we have to mutate the data using the methods mentioned above, it would be a disaster. Moreover, it goes against the practical way React Query recommends us to use. While React Query fits well with console-type websites, unfortunately, it seems less suitable for our main website.

You may think that we can use queryClient.setQueriesData to set all lists, but it will make things more complicated. Moreover, the maintainer of RQ doesn't like use this too. (See here)

So, what makes React Query unsuitable for our main website? I believe it's the level of control over the data. React Query focuses on managing server state for us, which means we don't have as much control over the data compared to using Redux. When using Redux, updating a post would automatically update the corresponding post in the list. However, when using Redux, it's not as straightforward as using useQuery to retrieve the data. We need to write a lot of actions and reducers, and if we want to add features like deduplication and revalidation, the amount of code to write increases even more. Clearly, Redux is not the optimal choice.

Since we haven't found a suitable package for our use case, why not develop our own? This brings up the issue of maintainability. If we create a tool that only we use, then the responsibility of maintaining it falls solely on us. Lack of community support is a significant concern for senior colleagues.

As a junior developer, I have always been interested in state management problems. Therefore, I want to try developing my own tool that meets the company's needs as my side project. Of course, I also hope this tool can help other developers who are struggling with managing server state.

Goals to achieve

First and foremost, it is essential to empower users to have full control over their data. Unlike React Query, where server state management is handled for us, all data writes will be user-defined. Although this may require users to write more code, I believe it is a necessary trade-off, and compared to Redux, the amount of code to write is relatively less.

Another crucial point is to provide a concise and user-friendly hook, similar to useQuery, that allows developers to call it from any component without worrying about duplicate requests. Additionally, features like polling and revalidation are also important.

If you have any ideas or suggestions regarding this project, please feel free to share them with me. Thank you.

Here is the repo of Daxus: https://github.com/jason89521/daxus

I create a package to simplify the work when using useReducer

Xuan — Sun, 01 May 2022 17:14:29 +0000

Using useReducer to handle complicated state is preferable than using useState. However, writing a reducer is kind of annoying because we may need to write so many switch/case to determine which action we are going to handle. Furthermore, we may prefer writing action creators to generate actions instead of writing an action directly.

To solve these problems, I write a package called use-case-reducers to simplify our work.

Features of this package

Use an object to generate a reducer
Automatically generate action creators
Allow mutating state in case reducer

Use an object to generate a reducer

Instead of writing a reducer function, use-case-reducers use an object containing case reducers to generate a reducer. A case reducer is a function that only handles one case of actions. For example, if we want to handle a counter state with two actions increment and add, then the object may look like:

const caseReducers = {
  increment: state => ({count: state + 1}),
  add: (state, amount) => ({count: state + amount}),
}

Automatically generate action creators

use-case-reducers will generate all action creators corresponding to the case reducers you pass in. Take the above caseReducers for example, it will generate two action creators increment() and add(amount).

Allow mutating state in case reducer

This package use immer in the generated reducer, so we can mutate the state inside our case reducers. We can rewrite the above caseReducers to:

const caseReducers = {
  increment: state => {state.count += 1},
  add: (state, amount) => {state.count += amount},
}

This feature may be useful when our state is very complicated.

How to use this package

Use npm or yarn to install it as a dependency:

npm install use-case-reducers
#or
yarn add use-case-reducers

We are going to write a component with a counter state and use this package to update it.

import useCaseReducers from 'use-case-reducers'

const initialState = {count: 0};
const caseReducers = {
  increment: (state) => {state.count += 1},
  add: (state, amount) => {state.count += amount},
};

const Counter = () => {
  const [state, dispatch, {increment, add}] = useCaseReducers(caseReducers, initialState);

  return (
    <div>
      count: {state.count}
      <button onClick={() => dispatch(increment())}>increment</button>
      <button onClick={() => dispatch(add(10))}>add 10</button>
    </div>
  )
}

Let's look the same component but writing with useReducer.

import {useReducer} from 'react'

const initialState = {count: 0};
const reducer = (state, action) => {
  switch(action.type) {
    'increment': {
      return {count: state.count + 1};
    }
    'add': {
      return {count: state.count + action.payload};
    }
  }
}

const increment = () => ({type: 'increment'});
const add = (amount) => ({type: 'add', payload: amount});

const Counter = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      count: {state.count}
      <button onClick={() => dispatch(increment())}>increment</button>
      <button onClick={() => dispatch(add(10))}>add 10</button>
    </div>
  )
}

As you can see, we can write less code with use-case-reducers. Hope this package will help you. Have a good day!