DEV Community: Marin Virdol

Things I learned while using React Query - Part 2

Marin Virdol — Mon, 08 Mar 2021 08:14:15 +0000

This blog post is the second in a series:

Things I learned while using React Query - Part 1
Things I learned while using React Query - Part 2 (this post)

Disable some of the defaults while in development

React Query comes with some aggressive defaults that are useful in production
but not that much while developing.

For example, by default, a refetch happens in the background on window focus to
keep the user as up to date as possible with the server. In development you
really don't need to sync with the server so often.

The same goes for the automatic retry behaviour when the query fails. Having no
retry for queries that fail is perfectly acceptable in development and it will
improve your development speed.

I recommend that you disable these two defaults at the level of the query
client. The advantage of doing it here is that you do it in only one place and
you don't need to worry about the other queries in your app.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: process.env.NODE_ENV === 'production',
      refetchOnWindowFocus: process.env.NODE_ENV === 'production',
    },
  },
})

Configure `staleTime` based on your needs

If you know that a certain query doesn't change often, probably you should
change the staleTime from the default value of zero, to a value that best fits
your needs for that specific query.

Use the `enabled` option to create dependent queries or to disable/enable a query

I've seen many people having a hard time running a query conditionally. Since
hooks don't work with if statements, React Query provides the enabled
configuration option exactly for this. You can disable/enable a specific query
by providing true or false to the enabled option.

Another useful features that comes with the enabled option is the ability to
create dependent queries. You fetch data in one query and the second query runs
only after the first one successfully completes.

Treat query keys like a dependency array, `useEffect` style

React Query does the cache management based on your query keys which means that
your query keys uniquely describe a piece of data in your application. These
query keys can be simple string values, complex nested objects or array of
strings and complex nested objects.

Many of your fetching functions will have dynamic route parameters or query
parameters. Think of the situations when you want to fetch a resource based on
its id or when you are doing server side pagination or filtering.

Knowing this, it's a good idea when designing your query keys, to treat them
like a dependency array, just like you do with your useEffect hooks. The rule
of thumb is to add to the query key any variable that your fetch function
depends on.

The benefit of doing this is that React Query will automatically trigger a
refetch whenever the query key changes and the synchronisation with the server
just happens.

Create custom hooks

A good practice is to wrap your useQuery hook calls in your own custom hook.
Functionality wise there is no added benefit, but there are a few developer
benefits.

First, we separate our data fetching from the UI
Second, we can be sure that we are NOT using different query keys for the same data
Lastly, if we need to tweak some settings for a specific query, or add some data transformation, we do that in only one place

Don't be afraid to use your hook in every component you need

If you need the same piece of data across your application in multiple
components, don't be afraid to use your custom hook (or the useQuery hook with
the same query key) in multiple components.

React Query automatically de-duplicates queries based on the query key,
therefore you can be sure there will not be more than one request per query key.

Use a default query function

To make things even more simpler, you can share the same fetch functionality for
queries throughout your application by creating a default query function.

As I told you before, many of your fetching functions will have dynamic route
parameters or query parameters. This means that we can create a default query
function that we can use for all of our queries.

There are two steps we need to do: create the general fetch function and specify
to React Query that we are going to use a default query function and which is
the function we want to use.

First, let's create the general function

function createQueryFn(baseUrl: string): QueryFunction {
  return async ({queryKey}) => {
    const path =
      typeof queryKey === 'string' ? queryKey : queryKey[0] + qs(queryKey[1])
    const res = await fetch(baseUrl + path)

    if (!res.ok) throw new Error(await res.json())

    return res.json()
  }
}

And second, we need to tell React Query about this function

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      queryFn: createQueryFn('https://api_base_url'),
    },
  },
})

Once this is done, you can use the useQuery hook in the following ways:

// query with simple query key as string
export function useMovies() {
  // a GET request will be fired to https://api_base_url/api/movies
  return useQuery('/api/movies')
}
// OR
// query with complex query key as object
export function useMovies({page, pageSize, searchTerm}) {
  // a GET request will be fired to
  // https://api_base_url/api/movies?page=0&pageSize=10&searchTerm=matrix
  return useQuery('/api/movies', {page, pageSize, searchTerm})
}

Things I learned while using React Query - Part 1

Marin Virdol — Fri, 26 Feb 2021 09:23:13 +0000

I've been using React Query in real world applications for over 8 months now, and I want to share with you some of the things I found useful to know when using it. This is the first part of a blog series.

React Query is a light caching layer

React Query is a caching layer that improves the developer experience and the user experience. The cache lives in memory, within your application, which means there is NO server or browser caching involved.

One of the most common mistakes when starting with React Query is to treat it like a traditional cache. Many developers are taken by surprise when they see the background refetch of the data. They expect to have only the initial network request and then to have the data served (only) from the cache.

But this is not the case.

React Query uses the stale-while-revalidate caching strategy in the attempt of keeping the user as up to date as possible with the server data without affecting the user experience.

Understand the different states of a query and the differences between them

In the documentation or in any other resource on React Query you will see many references to the different states in which a query can be.

These are: fresh, fetching, stale and inactive. Understanding why a query is in a certain state and when it will transition to a new state is crucial if you want to be proficient with React Query. They are the backbone of this library.

As you can see in the above diagram, the staleTime and cacheTime play a crucial role in deciding the state of the query. Make sure you understand when to use staleTime and when to use cacheTime. I like how @TkDodo describes the differences between the two.

staleTime = the duration until a query transitions from fresh to stale

cacheTime = the duration until inactive queries will be removed from the cache

Use the built-in dev tools to visualize the states of your queries

React Query ships with built-in dev tools. They can be extremely useful when learning the library.

Having a graphical representation of the different states in which a certain query is in will make it easier to understand them

Know the important defaults

Be aware of the important defaults and throughly understand them to make learning and debugging easier.

Why I stopped using Postman?

Marin Virdol — Fri, 26 Feb 2021 09:20:29 +0000

I've been using Postman for about 7 years now and I must say, it was an amazing journey. When I started as a software developer there wasn't any good tool to create/test/share APIs but then Postman appeared in my life and made everything much, much better. 7 years later, Postman is the industry standard. Very well done, Postman 👏!

During all these years of using Postman I've also found many disadvantages. It turns out, sharing your requests is not that simple, it has so many features I don't need and that makes it difficult to find what you do need. The application is slow to start and eats a lot of memory. Still, with all these disadvantages I was using it everyday without even thinking to search for a replacement. Until one day.

I've just switched jobs and I was discussing with my new teammate, Csaba, about designing the API for a new set of features we were to develop. I proposed to use Postman for the API design and then start the implementation based on the contract we define between the frontend and the backend. He told me that he knows a better tool for this task: REST Client extension for VS Code. I was skeptic 🤨about this, after all, Postman is the industry standard, use by so many developers. Even so, there was one thing that I loved from the beginning: I was able to /create/test/share the api from within the comfort of my editor 🤟. I mean, how awesome is that? And there is more, I can design my APIs by writing code, it has auto-complete, variables and no unnecessary functionality. We created a file .http file in our repository and off we went on coding our APIs. There are so many advantages to this like: it's easy to do versioning, track changes and share the file with other developers.

I removed Postman from my laptop and I've been enjoying this extension ever since. Go have a look at this extension and let me know how it helped you.

Thanks Csaba for introducing me to this extension.

How Can Declarative Programming Simplify your UIs

Marin Virdol — Tue, 02 Jun 2020 05:34:37 +0000

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Flower

Many UIs are lousy. I'm not referring to the fact that the User Experience is bad or that the website doesn't look great, I'm referring to the fact that they crash, lock up, mislead the user and are a nightmare for the programmers maintaining them.

I strongly believe that this happens because many developers are using an imperative, event-driven programming approach which results in code riddled with huge number of convoluted conditional logic. If one could somehow reduce the number of conditional behaviours, the code can get easier to grasp, test and maintain.

Techniques based on declarative example can help achieving this.

What are the problems with imperative, event-driven programming?

In event-driven programming you have an UI component that generates an event, for example input onchange, which triggers an action that is directly attached to the component. The component implementation decides how to react to that action, making the action tightly coupled to the event. Basically, such a component is waiting for the occurrence of some external or internal event, such as button pressed or data arrived, and they react by performing the appropriate computation.

The problem is rooted in the difficulty of describing this behaviour in ways that are clear, easy to understand, enhance and test.

What is the problem with this approach?

First, such a system neglects the context or current state in which the event takes places and because of this it generate a huge number of convoluted conditional logic, making it hard to handle all the states our application can be in.

Second, the actions actually executed are determined by events which largely are in an unpredictable timing and order making the path through the code to differ each and every time.

What is declarative programming?

I think the easier way of describing the difference between declarative programming and imperative programming is through a real life analogy.

Suppose you have to go to the headquarters of a company for an interview. Let's describe how you are going to reach their office through each of these techniques.

The imperative approach of going to the interview is: Exist your house, turn right, at the forth traffic light make left and then straight ahead until you reach the metro station. Take metro number 1 and get down at the station A, exit the metro station through exit 2a. The office is right across the street.

The declarative approach is: The address of the office is 23rd Huston Avenue, Boston, MA.

The key difference here is that with declarative programming the steps are abstracted away from you. In order to reach your destination you must have a GPS or another method that knows how to get you to the address you provide.

To sum up, the difference between the two programming paradigms is that with declarative programming you describe the desired result without explicitly listing all the steps that must be performed while in imperative programming you must describe exactly each step that will be executed.

How can declarative programming simplify your UI?

There are several declarative programming paradigms and libraries you can use but the most used nowadays are react, reactive programming (rxjs) and finite state machines with state-charts (xstate).

React

React is probably the most known declarative library out there. In a React application you are simply stating that the view should look in a certain way given a certain state, there are few things that can go wrong with this approach.

Moreover, React allows us to do declarative programming without the drawbacks that are usually associated with this paradigm: performance. In React, the DOM manipulation is abstracted away from us through the Virtual DOM which handles the performance issue of making changes to the DOM often.

Reactive Programming Using A Library Like RxJs

I am a huge fan of reactive programming which is a declarative style of programming. It makes it very easy to express static or dynamic data streams and moreover it is easy to express an inferred dependency within the associate execution model that facilitates automatic propagation of the changed data.

I first learned about reactive programming and rxjs when I started with the new version of angular a few years ago. I must admit, at the beginning it was a little bit difficult to understand how everything is tight together (because I was used programming in an imperative way) but as time passed by and I got more experience and knowledgeable I started to really see the benefits.

I mean, how awesome it is to create streams of data from different sources like search input, server data, routing data, etc and then combine these streams in other streams that you finally use to create the state of the UI at any given moment? I tell you, it's amazing!!! And makes your code really, really simple to reason about.

Finite State Machines Using A Library Like XState

State machines are one of the most effective methods for developing robust UI. Our apps have lots of states that they can be in. We usually handle states like, loading, success and maybe failure. What about other states our app can be in? Imagine the number of combinations you can have if you have five booleans in your state, around 120. Crazy, right? There is more to this, our app should not even be in many of those 120 possible states.

All these state problems can be tackled by using a state machine. A state machine encourages you to plan your states, to declare all your possible states and all possible transitions removing the impossible states and reducing the number of total states.

Takeaways

Declarative programming makes it more easy to reason about a piece of code because of the following:

It is less code you have to worry about. Therefore, fewer things can go wrong.
You specify what should happen not how it should happen.
Easier to test programmatically.
It forces you to make a little bit of planning before you jump straight into coding.

3 Tips That Will Simplify Your Application State Management

Marin Virdol — Thu, 21 May 2020 18:10:54 +0000

The Introduction

The goal of this blog post is to introduce you to some of the most common pitfalls that make state management unnecessarily difficult and to outline 3 simple strategies that will help you avoid them.

Managing the state of an application if extremely hard and I think is the main reason why applications tend to become so complex. For some reason, we try to manage the complexity by over-engineering our solution to the problem. There are so many ways of managing the state of your application (redux, flux, finite state machines) and countless abstraction libraries on top of these.

But first, let's quickly define what I call the state of an application so we are on the same page.

The Definition Of State

The state of an application is a representation of a system at a given time. The UI of a front-end application is a representation of the state. If a user changes the state by interacting with your application, the UI may look completely different afterward because it is represented by this new state.

The state is able to keep the data of different components in sync (or not) because each update will re-render all relevant components. Moreover, you can use the state to communicate between different components.

I would suggest that there are the following types of state:

Persistent State - this one lives on the server and it is accessible, for example, via a REST endpoint
Navigation State - where is the user in the application? Is he on the sign-in page, the sign-up page or the profile page?
Local UI State - what is the colour of the button? Is the panel expanded or not? Is the modal open
Client State - you can think of the filters selected by the user when dealing with a large list of items, the current page in the list of items

As you can see, there are many aspects to be taken into consideration when thinking about the state of our application. The biggest problem in state management arises when we try to coordinate all these state sources (server data, web workers, UI components, navigation etc) all of which update the state concurrently.

How we decide to sync all this data is one of the most important decision when designing the state management of our application.

The 3 Simple Strategies That Will Simplify Your Application State Management

1. Identify the type of state you are dealing with

Make this your first step in your state management decision tree. Developers seriously underestimate the value of doing this (including myself) but it is extremely important in order to keep it simple.

To help you identify it, you should think if this particular state of the application should be saved for later use or if you want the user to share the exact same state of the application with another user. If this is the case you should consider to reflect the state of the application in the URL.

Why is important? Except for the persistent state, the rest of the state is not stored on the server which means that there is no way of saving it for later use or for sharing it with other users. Also, if the user refreshes the page he will land on the same state of the application.

Example. Think about when you want to share a Youtube video with a friend from a specific moment. The link you are going to share will have all the information needed to play the exact same video from that exact specific moment.

2. Keep your state data as close as possible

The next step in simplifying the state of your application is to keep your state data as close as possible to where it is needed. This comes with the following two benefits: maintainability and performance.

Performance

Imagine you have a hierarchy of components and you keep your state in the root component. Each time the state changes the entire tree is re-rendered and that is perfectly fine if all the components in the tree depend on that state. But what if that change only affects a component somewhere at the bottom of the hierarchy? You want to keep that part of the state as close as possible to the component that needs it. This way the component tree will re-render a lot fewer components than a state change at the top of the tree.

Maintainability

From the maintainability point of view always start a new component by managing it’s internal state inside of that component and if a sibling or the parents need access to that state just lift that part of the state up to the parent. This goes both ways. If you have a piece of state in a parent component that only one child needs, then move that piece to the child level.

3. Don't keep your entire state globally

I've notice this pattern especially in applications that use redux. There are developers that like to keep their entire state into redux. If you are using redux you should aim on keeping only global state into redux and the local state as close as possible to the components that need that data.

The problem with using redux for every piece of state is increased complexity. Redux adds a lot of complexity to your application because maintaining the state involves working with reducers, actions, dispatching calls which results in having your state management all over the place. It get really hard to maintain. Ben Lesh puts it really well in one of his tweets:

https://twitter.com/BenLesh/status/1241525265228017670

Conclusions

As you can see, as soon as the application is starting to grow, so does the complexity of managing the state. This is why the state management strategy is not something that you want to add late in your project, you should plan for it because it can be the decisive factor for the success or failure of your application.

“If you fail to plan, you are planning to fail!” - Benjamin Franklin