Managing React server state: a simpler approach

The role of the state

The state is a property of each component that holds its data, it gives personality and structure, it’s an important factor that establishes the correct functionality and affects the interactivity in such a way that the user is greatly affected by it. When we begin to create an application we need to think about the architecture of the application itself, in a way that components are isolated from each other. This idea brings an immediate advantage, each component has its responsibility of bringing the data that needs, for example:

A story component display stories in two cases:

• All stories not considering the category
• All stories related to one category

This component then depends on the prop passed to him to change the behavior of how we bring the data, each time this prop changes it does on the server call then we get different data.

An easy way to visualize this idea is to know the basic principles of functional  programming in which react is heavily inspired on:

A function must be:

• Pure (deterministic), it should
• Return the same result given the same arguments and
• It shouldn’t cause side effects. In other words, our components need to be in charge of one main responsibility and adapt the output base on the props but accomplish the reason was originally created and not to mutate an object passed as a prop.

The difficulties in new web applications are managing the state as they get more complex structures controlling not only the server state but also the interactivity of smaller atoms in our components, if there is a small disruption in the data flow in one of them the cost of it could lead to unpredictable or unwanted behavior.

Why it’s not a good idea to over-engineer

The most popular proposal to overcome this issue is Redux which comes with the idea of establishing a single global state in which the programmer can easily debug if there’s any data corruption in the state, this is one of the key concepts of redux the single source of truth.

Here are two of the drawbacks of redux:

The problem with the Store

Breaking the layers of what each component should know between them could lead us to undesired design decisions like not isolating components and their data or making unnecessary dependencies between them to accomplish their purpose.

The other concepts

As we start doing the implementation we notice the amount of code necessary to make it work like intended, if we need it to rewrite the behavior of the existing functionality of an action in our component first we need to adapt the trigger function in the same component, then modify the action and finally adapt the reducer then after these steps we can accomplish the mission: change one value of the state.

A more simpler solution

The core concept while starting a new project its to use the less complex tools or machinery to solve the problems you are facing, it’s more important to be simplistic than clever because it makes the code more maintainable and less error-prone and it’s more easier for the programmer to read, understand the logic and the reason of the existing code implementation.

React query follows this approach, its’ built on the react hooks pattern to simplify the complexity of working with data fetching and decouple different logics into smaller functions. ‘Hooks for fetching, caching, and updating asynchronous data in react’ by is own definition we gain powerful features to manage the server state like:

• Auto caching and re-fetching
• Parallel and dependent queries
• Mutations + Reactive Query Refetching
• Multi-layer Cache + Automatic Garbage Collection

and many others…

Simple implementation example:

As simple as that you get the caching, refetch and the stale invalidation, now the concept of useQuery its to use an array just like the useEffect hook to first set the query unique name and also the initial prop to call the api, then define the function to be call.

By default (you can overwrite them) react query will execute the fetchSomething function when:

• The prop changes
• The user returns to our application (refetchOnWindowFocus)
• The network re-connects

This will also work along with the caching functionality, each time the fetch returns data this will compare between the cached data to look for changes, if it found some differences then it will trigger the re-rendering by updating the state if not then the state will remain the same and the user wouldn’t notice any disturbance caused by the component re-render.

By setting a simpler approach to managing the data fetching we then build each component based on the idea of isolation, which means each of them has his responsibility to fetch, store and transform the data, by this we get these benefits :

• Simpler state
• Minimize the amount of code to understand
• Reduced complexity

If we need to increase the component responsibility we only need to update the code in the same component and not in three different places.

Conclusion

React Query is not a solution to all projects, the main purpose is to establish the idea of starting from the most simple tool that solves your problem to gain complexity, from that as your app increase it’s sizes and responsibility and maybe you will never really need a more complex approach.

‍