DEV Community: Nischal Dutt

RxJS Observables vs Promises

Nischal Dutt — Tue, 22 Nov 2022 17:08:01 +0000

For a long time in JavaScript, handling asynchronous values has come down to callbacks or Promises. Being an asynchronous primitive, Promises are often compared to RxJS Observables. To illustrate the difference between Promises and Observables, let us write a promise from scratch.

const myPromise = new Promise((resolve) => {
  setTimeout(() => {
    console.log("myPromise timeout hit")
    resolve(100)
  }, 1000)

  console.log("myPromise started")
});

myPromise.then((response) => console.log({ response }));

As soon as we run our code. the promise will start executing without any delay.

In other words by the time have access to myPromise object, it has already been executed. Even if we omit the last line with .then call, the promise will still execute except now our resolve call will not do anything as we are not providing in the .then callback.

Now let us see how Observables behave in the same scenario. We’ll pretty much use the same code except now we’ll use subscribe from RxJS which allows an observer to get attached to the observable execution.

const myObservable = Observable.create((observer) => {
  setTimeout(() => {
    console.log("myObservable timeout hit");
    observer.next(100);
  }, 1000);

  console.log("myObservable started");
});

myObservable.subscribe((x) => console.log(x));

The output will be similar to as if we are using Promises.

So where’s the difference here?
To see the difference between Promises and Observables, remove the last line from the above example i.e. omit the call to subscribe and run the code again.

myObservable.subscribe((x) => console.log(x)); // remove this line

If you’ll check the console this time, nothing gets printed on the console indicating Observables are lazy and they won’t execute until we subscribe to them. But what advantage do we have with Observables having this lazy feature?

This is where it gets interesting.
If we were using a promise, it is always going to fire the block that's inside of it. For instance, If we are setting up some asynchronous call, the instant you have a promise it's going to fire that asynchronous call, setting up some event handler, or anything else. That is already done by the time you have access to the promise.
On the other hand, If I have an Observable, the Observable will not execute itself unless we subscribe to it. Moreover, it is also possible to cancel the execution of an Observable, something which is not possible with promises.

Let us see how we can cancel an Observable mid-way through its execution. Considering the above example, the call to subscribe returns an object called subscription. The Subscription represents the ongoing execution and has a minimal API that allows you to cancel that execution. With subscription.unsubscribe() you can cancel the ongoing execution.
Each Observable must define how to dispose resources of that execution when we create the Observable using create(). We can do that by returning a cleanup function from within an observable.

const myObservable = Observable.create((observer) => {
  const id = setTimeout(() => {
    console.log("myObservable timeout hit");
    observer.next(100);
  }, 1000);

  console.log("myObservable started");

  return () => {
    console.log("unsubscibing myObservable");
    clearTimeout(id);
  };
});

const subscription = myObservable.subscribe((x) => console.log(x));

setTimeout(() => {
  subscription.unsubscribe();
}, 500);

Notice how the Observable starts executing but as soon as it is unsubscribed after 500 ms, we clear the timeout and the inner setTimeout callback is never executed.
Observables can embody the setup and teardown for their data sources. What does that mean? That means, unlike Promises, Observables can be canceled because they embody everything necessary to tear themselves down.
Likewise, because Observables embody everything necessary to set themselves up they can be called again as long as we have access to them. So if we were to call a promise again, it's not going to run again. It's just going to return the same value it already had.

This means if we have an Observable that's errored, we can simply subscribe to it again to retry it or use one of the retry operators such as retry() from RxJS. Whereas with a Promise if the Promise has errored, we better have access to whatever function returned the Promise because the Promise has already executed its logic.

Thank you for reading!

I hope this post was useful to you and helped you understand the difference between RxJS Observables and JS Promises.

Feel free to reach out to me! 😊

💻 Github II ✨ Twitter II 💌 Email II 💡Linkedin

What are RxJS Observables?

Nischal Dutt — Tue, 22 Nov 2022 01:47:23 +0000

RxJS is a framework for reactive programming that makes use of Observables making it easy to write asynchronous code. Observable being a core concept in RxJS represents the idea of an invokable collection of future values or events.
Let us understand what need Observables fill and why we need them.

const list = [1, 2, 3, 4, 5, 6];

list.forEach((n) => console.log(n));

As soon as we run the above code snippet, as expected the list is displayed.

Because the array is residing in the memory, so the loop is executed instantaneously.
Now the interesting thing about this is that Observables are also collections. In fact, I can take my list array and convert it into an observable.

import { from } from "rxjs";

const list = [1, 2, 3, 4, 5, 6];

from(list).forEach((n) => console.log(n));

We use from operator to convert our list array to an observable and can achieve the same result.

Why is this interesting?
Because Observables are asynchronous. They represent a number of values over any amount of time. Or in other words, we can iterate through pretty much any data stream using Observable.
To demonstrate this asynchronous behavior, let us consider a scenario where a number is emitted every 1 second. To imitate this we can use the interval function that increments a number and emits that.

import { interval, take } from "rxjs";

interval(1000)
  .pipe(take(6))
  .subscribe((x) => console.log("Next: ", x));

When we run this now, you'll see they come in over time.

The reason this is interesting is if we had a function that accepted an array, and did this to it, we could change that function to accept an observable instead and now all of a sudden, our function can handle things asynchronously.

Thank you for reading!

I hope this post was useful to you and helped you understand What are Observables and why we need them?
RxJS observable has a lot more higher-order functions such as concat, merge, map, scan, that we might find in a library like lodash making RxJS lodash for async events.

Feel free to reach out to me! 😊

💻 Github II ✨ Twitter II 💌 Email II 💡Linkedin

Server-Side Rendering in React 18

Nischal Dutt — Mon, 10 Oct 2022 17:10:39 +0000

Client-Side Rendering

In a standard React application, the browser receives an empty HTML from the server along with the JavaScript instructions to construct the UI. This is called Client-Side Rendering (CSR) because the initial rendering work happens on the user's device.

This process of rendering your components and attaching event handlers is known as “hydration”.

Or As per Dan Abramov

It’s like watering the “dry” HTML with the “water” of interactivity and event handlers.

However, CSR comes with well know issues associated with it as in,

The web page rankings suffer in the search engine index as an empty HTML is sent to the client initially that makes it difficult for the web crawlers to identify the content of the web page.
Initial load time of application is slow as complete Javascript has to be downloaded on the client first. If the client’s network is slow then it may even hang the browser for few seconds in the initial load.

Server-Side Rendering

To counter above mentioned issues, React provides another approach, Server-Side Rendering (SSR), where the rendering of HTML happens on the server itself instead of the client, and sends that HTML to our users.

SSR in React happen in following steps:

The key part is that each step had to finish for the entire app at once before the next step could start. This is not efficient if some parts of your app are slower than others, as is the case in pretty much every non-trivial app.

This indicates following major issues when working with SSR today:

All the data on the server should be collected before the server can start sending any HTML to the client because SSR does not allow components to “wait for data”.
All the Javascript should be loaded for all the components on the client before React can start the Hydration because the tree produced on the server must match the tree produced on the client otherwise React will remove (during hydration) a chunk of HTML whose Javascript is not yet loaded.
Every component on the client should be hydrated before user can start interacting with the web page.

Suspense to the rescue!

Previously, React did not support Suspense on the server, and it was only limited for lazy-loading the code on the client, this is changing in React 18.

There are two major SSR features in React 18 unlocked by Suspense:

Streaming HTML on the server
Selective Hydration

Streaming HTML on the server

With today’s SSR, rendering HTML and hydration is “all or nothing” process.

First you render all HTML on the server.

<main>
  <nav>
    <!--NavBar -->
    <a href="/">Home</a>
   </nav>
  <aside>
    <!-- Sidebar -->
    <a href="/profile">Profile</a>
  </aside>
  <article>
    <!-- Post -->
    <p>Hello world</p>
  </article>
  <section>
    <!-- Comments -->
    <p>First comment</p>
    <p>Second comment</p>
  </section>
</main>

The client eventually receives it then you load all the code and hydrate the entire app. But React 18 gives you a new possibility. You can wrap a part of the page with <Suspense></Supense>.

Let’s wrap the comment block and tell React that until it’s ready, React should display the <Spinner /> component:

<Layout>
  <NavBar />
  <Sidebar />
  <RightPane>
    <Post />
    <Suspense fallback={<Spinner />}>
      <Comments />
    </Suspense>
  </RightPane>
</Layout>

By wrapping <Comments> into <Suspense>, we tell React that it doesn’t need to wait for comments to start streaming the HTML for the rest of the page. Instead, React will send the placeholder (a spinner) instead of the Comments.

Moreover, Unlike traditional HTML streaming, it doesn’t have to happen in the top-down order. For example, if the Sidebar needs some data, you can wrap it in Suspense, and React will emit a placeholder and continue with rendering the post. Then, when the Sidebar's HTML is ready, React will stream it. There is no requirement that data loads in any particular order. You specify where the spinners should appear, and React figures out the rest.

Selective Hydration

We can send the initial HTML earlier, but we still have a problem. Until the JavaScript code for the comments widget loads, we can’t start hydrating our app on the client. If the code size is large, this can take a while.

To avoid large bundles, you would usually use "Code Splitting" in other words you would specify that a piece of code doesn't need to load synchronously, and your bundler will split it off into a separate <script> tag.

You can use code splitting with React.lazy to split off the comments code from the main bundle:

import { lazy } from 'react';

const Comments = lazy(() => import('./Comments.js'));

// ...

<Suspense fallback={<Spinner />}>
  <Comments />
</Suspense>

Previously, this did not work with server rendering.
But in React 18, <Suspense> lets you hydrate the other sections of the app before the comment widget has loaded.

This is an example of Selective Hidration by, wrapping Comments in <Suspense>, you told React that they shouldn’t block the rest of the page from streaming and, as it turns out, from hydrating, too! This means the second problem is solved i.e. you no longer have to wait for all the code to load in-order to start hydrating. React can hydrate parts as they’re being loaded.

Interacting with the page before all the components have hydrated

Last and but not the least, there is one more improvement that happened behind the scenes when we wrapped comments in a <Suspense>. Now their hydration no longer blocks the browser from doing other work.

For example, let’s say the user clicks the sidebar while the comments are being hydrated:

In React 18, hydrating content inside Suspense boundaries happens with tiny gaps in which the browser can handle events. Thanks to this, the click is handled immediately, and the browser doesn’t appear stuck during a long hydration on a low-end device.

In our example, only comments are wrapped in Suspense, so hydrating the rest of the page happens in a single pass. However, we could fix this by using Suspense in more places! For example, let’s wrap the sidebar as well:

<Layout>
  <NavBar />
  <Suspense fallback={<Spinner />}>
    <Sidebar />
  </Suspense>
  <RightPane>
    <Post />
    <Suspense fallback={<Spinner />}>
      <Comments />
    </Suspense>
  </RightPane>
</Layout>

Now both of them (Sidebar and Comments) can be streamed from the server after initial HTML containing other components are streamed to the client.

But this also has a consequence on hydration as well. Let’s say the HTML for both Sidebar and Comments has loaded but the code is not loaded yet. As soon as the code loads, React will start the hydration process starting with the first Suspense boundary it encounters, which is Sidebar in out case.

Now let’s say the user starts interacting with the Comments HTML which the hydration of Sidebar is going on,

Here React will synchronously hydrate the comments during the capture phase of the click event (How cool is that!).

As a result, comments will be hydrated just in time to handle the click and respond to interaction. Then, now that React has nothing urgent to do, React will hydrate the sidebar.

React starts hydrating everything as early as possible, and it prioritizes the most urgent part of the screen based on the user interaction.

This resolves the third problem, no need to wait for all components to hydrate before use can start interacting with the page. Selective Hydration will prioritize the components the user is interacting with, and hydrate them early.

Thank you for reading!

I hope this post was useful to you and helped you understand why Suspense is more than just a fancy loading spinner! 😉
This is just a high-level overview of the new SSR architecture and what problems Suspense solve, however if you want to dive deeper into this concept, you can read this superb discussion thread explained by React's team itself.
PS: This post was inspired by the discussion.

Feel free to reach out to me! 😊

💻 Github II ✨ Twitter II 💌 Email II 💡Linkedin

Mutations

Nischal Dutt — Sun, 02 Oct 2022 13:26:20 +0000

Over the past lessons, we went through the data fetching aspect of React Query now it's time to focus on the data hosting aspect i.e. interacting with the back-end of the application.

Unlike queries, mutations are typically used to create, update and delete data or perform server side-effects. These CRUD operations are pretty basic in any application that interacts with the back-end and React Query not only takes care of all such scenarios effectively but also goes the extra mile to make things simpler.

Here we’ll focus on how to perform a basic POST request and then gradually we’ll go through various features that are provided to perform these operations.

Consider from our previous example, /companies endpoint that returns a list of companies from the back-end. Now we will perform a POST request using Axios library, on this endpoint that will take the company’s name and its CEO’s name and will insert it into the list of companies.

For this purpose, React Query exports the useMutation hook.

import React from "react";
import axios from "axios";
import { Link } from "react-router-dom";
import { useMutation } from "@tanstack/react-query";

import CompaniesList from "./CompaniesList";

const addCompany = (newCompany) => {
  return axios.post("http://localhost:4000/companies", newCompany);
};

const Mutations = () => {
  const [name, setName] = React.useState("");
  const [ceo, setCeo] = React.useState("");
  const { mutate: insertNewCompnay } = useMutation(addCompany);

  const addCompanyData = () => {
    insertNewCompnay({ name, ceo });
  };

  return (
    <div>
      <h1>enter company details</h1>
      <h2>name</h2>
      <input
        type="text"
        onChange={(e) => setName(e.target.value)}
        value={name}
      />
      <h2>ceo</h2>
      <input type="text" onChange={(e) => setCeo(e.target.value)} value={ceo} />

            <br />
      <button type="submit" onClick={addCompanyData}>
        save
      </button>
            <br />
      <CompaniesList />
    </div>
  );
};

export default Mutations;

The useMutation hook takes a functions as its first argument and returns an asynchronous function called mutate which in-turn take our request body parameters and performs the insertion to the list of companies.

That’s how we perform CRUD operations using React Query, but there’s room for improvement. Notice each time we perform an insert we need to manually trigger a re-fetch for /companies by clicking on the button.

This is because the /companies query data is out of date but it will not get updated until its stale time is over. To overcome this we can manually inform that this particular query data is stale now and it needs to be updated.

For this scenario, the useMutation hook takes in a second argument object where we supply an onSuccess callback which will be called once the addCompany function is done executing.

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

const queryClient = useQueryClient();
const { mutate: insertNewCompnay } = useMutation(addCompany, {
    onSuccess: () => queryClient.invalidateQueries("companies"),
});

Now here we can make use of invalidateQueries function which is available via the queryClient object which takes in the query key that needs to be updated. When the invalidateQueries function is called, the stale time of the query is set to the EXPIRED state and the query is re-fetched automatically in the background.

Thank you for reading!

And that's a wrap for this series. Now we know why React Query is considered as The Missing data fetching Library.
Go ahead and start experimenting.

And as always, feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Happy Conding!

Paginated & Infinite Queries

Nischal Dutt — Sun, 02 Oct 2022 12:05:55 +0000

Paginated/Lagged Queries

Rendering paginated data is a very common UI pattern and in React Query, it "just works" by including the page information in the query key.

To perform paginated queries consider we have a list of colors, we can perform pagination as follows:

import React from "react";
import { useQuery } from "@tanstack/react-query";

const fetchColors = ({ queryKey }) => {
  const pageNumber = queryKey[1];
  return fetch(
    `http://localhost:4000/colors?_limit=2&_page=${pageNumber}`
  ).then((response) => response.json());
};

const Colors = () => {
  const [currPageNum, setCurrPageNum] = React.useState(1);

  const { data: colors, isFetching } = useQuery(
    ["colors", currPageNum],
    fetchColors,
    {
      keepPreviousData: true,
    }
  );

  return (
    <div>
      {colors?.map((color) => (
        <div key={color.id}>{color.name}</div>
      ))}

      <button
        onClick={() => setCurrPageNum((currPageNum) => currPageNum - 1)}
        disabled={currPageNum === 1}
      >
        previous
      </button>
      <button
        onClick={() => setCurrPageNum((currPageNum) => currPageNum + 1)}
        disabled={currPageNum === 5}
      >
        next
      </button>
      <div>{isFetching ? "loading..." : null}</div>
    </div>
  );
};

export default Colors;

One point to note here is that we’ve used keepPreviousData config to true. Let us see the significance of using it,

If we don’t use keepPreviousData

The UI jumps in and out of the success and loading states because each new page is treated like a brand new query.

If we use keepPreviousData

This time even though the data is being fetched each time, the loading state is not shown as the previous data is used on display while the background fetch is being performed and swapped once new data is available.

According to React Query docs,

By setting keepPreviousData to true we get a few new things:

The data from the last successful fetch is available while new data is being requested, even though the query key has changed.

When the new data arrives, the previous data is seamlessly swapped to show the new data.

isPreviousData is made available to know what data the query is currently providing you.

Infinite Queries

Infinite queries can be a great UX feature if it is performed efficiently. React Query supports a useful version of useQuery called useInfiniteQuery for querying such kind of lists.

Consider we have a list of games, and we want users to show 2 games at a time after which the user should click the fetch more button at the bottom to view the next 2 games.
Here's how we’ll perform this using the mighty useInfiniteQueries hook.

import React from "react";
import { useInfiniteQuery } from "@tanstack/react-query";

const fetchGames = async ({ pageParam = 1 }) => {
  return fetch(`http://localhost:4000/games?_limit=2&_page=${pageParam}`).then(
    (response) => response.json()
  );
};

const TopGames = () => {
  const {
    isLoading,
    data,
    isError,
    error,
    hasNextPage,
    isFetching,
    fetchNextPage,
    isFetchingNextPage,
  } = useInfiniteQuery(["games"], fetchGames, {
    getNextPageParam: (_lastPage, pages) => {
      return pages.length < 5 ? pages.length + 1 : undefined;
    },
  });

  if (isLoading) {
    return <h4>loading</h4>;
  }

  if (isError) {
    return <h4>{error.message}</h4>;
  }

  return (
    <div>
      {data?.pages.map((group, index) => {
        return (
          <div key={index}>
            {group.map((game) => {
              return <h3 key={game.id}>{game.name}</h3>;
            })}
          </div>
        );
      })}

      <button disabled={!hasNextPage} onClick={fetchNextPage}>
        load more
      </button>
      <div>{isFetching && isFetchingNextPage ? "loading..." : null}</div>
    </div>
  );
};

export default TopGames;

Thank you for reading!

Now that we have covered common use cases for fetching the information that developers face, let us learn about how to perform mutations i.e. CRUD operations with React Query.
Feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Till then happy coding!

Initial Query Data in React Query

Nischal Dutt — Sun, 02 Oct 2022 11:14:50 +0000

Another way we can improve the data fetching/viewing experience of the user is by providing Initial Query Data in config options to the useQuery hook. Let us first consider why we need it in the first place.

We know when we hit /companies endpoint we get a list of companies where each company looks like:

{
    "id": 1,
    "name": "Microsoft",
    "ceo": "Satya Nadela"
}

Now consider another /companyDetails endpoint that fetches the details of the company with companies looking as:

{
    "id": 1,
    "name": "Microsoft",
    "ceo": "Satya Nadela",
    "founder": "Bill Gates",
    "headQuarters": "Redmond, Washington, United States"
}

Note that some data like name, id, and ceo is common between the above 2 company objects.

Now let us use useQuery hook to fetch the company details using /companyDetails endpoint

const fetchCompanyDetails = ({ queryKey }) => {
  const id = queryKey[1];
  return fetch(`http://localhost:4000/companyDetails/${id}`).then((response) =>
    response.json()
  );
};

const { 
    isLoading, 
    data: companyDetails 
} = useQuery(["company-details", id], fetchCompanyDetails);

Note: For testing purposes, I have set the network throttling to Slow 3G in the network tab of Chrome Devtools.

From the above, we can note that each time the user clicks on the company name the loading state is shown and then complete company details are then displayed to the user.
This is where intialData can help. It prevents the loading state to be shown to the user by showing the user, already cached information thereby thus improving the overall data fetching/viewing experience.

Now that we know why we need initial query data let us see how to use it.

import React from "react";
import { useParams } from "react-router-dom";
import { useQuery, useQueryClient } from "@tanstack/react-query";

const fetchCompanyDetails = ({ queryKey }) => {
  const id = queryKey[1];
  return fetch(`http://localhost:4000/companyDetails/${id}`).then((response) =>
    response.json()
  );
};

const Company = () => {
  const { id } = useParams();
  const queryClient = useQueryClient();

  const {
    isLoading,
    data: companyData,
  } = useQuery(["company-details", id], fetchCompanyDetails, {
    initialData: () => {
      const cachedCompanyData = queryClient
        .getQueryData("companies")
        .find((cachedCompany) => cachedCompany.id === parseInt(id));
      console.log({ cachedCompanyData });
      return cachedCompanyData ? cachedCompanyData : undefined;
    },
  });

  if (isLoading) {
    return <h1>loading</h1>;
  }

  return (
    <div>
      <h2>name: {companyData.name}</h2>
      <h2>ceo: {companyData.ceo}</h2>
      <h2>founder: {companyData.founder}</h2>
      <h2>headquarters: {companyData.headQuarters}</h2>
    </div>
  );
};

export default Company;

We can provide initialData config to the useQuery hook which is a function, whatever we return from this function will serve as the initial data for the page but if we return undefined then react query sets our app in a hard loading state until the complete data is fetched thus preventing from errors.

In our case since we already have some data to be shown to the user, we get that data from the cache using queryClient.getQueryData("companies") this returns a list of companies in which we perform a search operation to find the clicked company using the id which is accessible using useParams hook if in case the cache is empty then we return undefined else we return the cached company data. Here’s what the result looks like

Notice how the loading state is not shown this time and the user is shown the cached information while the data is being fetched in the background and shown once done as if it is being fetched on the go.

Thank you for reading!

In the next lesson, we will tackle one of the most common UI pattern problem that every Frontend Developer has faced which is performing paginated and infinite queries.
We'll see how easy React Query makes it for us to perform such operations.

Feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Till then happy coding!

Querying data using React Query

Nischal Dutt — Sun, 02 Oct 2022 10:09:50 +0000

Querying By Id

Now that we know about working with useQuery hook and its configuration options to fetch the data, we can move forward to what is also pretty common operation i.e. to fetch any particular item details from a list of items based on its id.
Consider another endpoint /companies/:id that returns clicked company details.

<h1 key={company.id}>
    <Link to={`/companies/${company.id}`}>{company.name}</Link>
</h1>

import React from "react";
import { useParams } from "react-router-dom";
import { useQuery } from "@tanstack/react-query";

const fetchCompany = (id) => {
  return fetch(`http://localhost:4000/companies/${id}`).then((response) =>
    response.json()
  );
};

const Company = () => {
  const { id } = useParams();
  const {
    isLoading,
    data: companyData,
    isError,
    error,
  } = useQuery(["company", id], () => fetchCompany(id));

  if (isLoading) {
    return <h1>loading</h1>;
  }

  if (isError) {
    return <h1>{error.message}</h1>;
  }

  return (
    <div>
      <h2>{companyData.name}</h2>
      <h2>{companyData.ceo}</h2>
    </div>
  );
};

export default Company;

Let us understand what happened above,
First we define the fetchCompany function that takes in the id of the company, fetches the company details, and returns it.
Second, To get the clicked company’s id we can use useParams hook provided by react-router-dom that returns an object which contains all URL parameters, we just destructed id param.

Now lets look at the useQuery hook,

const {
  isLoading,
  data: companyData    
  isError
} = useQuery(["company", id], () => fetchCompany(id));

The hook has minor changes, the query key now constitutes of a string key and id param, this helps to uniquely identify the query. So the key takeaway from this is that the query key here is ["company", id].

Now in the second argument, we provide the callback function with the company id.

Result

It works!

Notice how we’re passing the id to the fetchCompnay function in the callback. Their’s an aleternative way to achieve that without passing the id in the callback in the useQuery hook.

React-Query will pass some meta information and query key as arguments to the fetch function implicitly, so in the fetch function we can de-structure the appropriate arguments to get the id of the company.

Since the query key is an array which gets passed in the queryKey props, from there we can get the id of the company.

const fetchCompany = ({ queryKey }) => {
  const id = queryKey[1];
  return fetch(`http://localhost:4000/companies/${id}`).then((response) =>
    response.json()
  );
};

const {
  isLoading,
  data: companyData    
  isError
} = useQuery(["company", id], fetchCompany);

Dynamic Parallel Queries

Now that we know how to fetch an item based on its id, consider a scenario where the requirement is to fetch multiple items based on their respective ids parallelly. Most developers (including me) might think of putting the useQuery hook in a loop and calling it multiple times but that is not something that is allowed as it violates the rule of hooks i.e. they cannot be called inside any conditional statements or for loops.

Hence to tackle this specific scenario react query provides a hook called useQueries, lets see how it works

import { useQueries } from "@tanstack/react-query";

const componyIds = [1, 2, 3];

const response = useQueries({
  queries: componyIds.map((id) => {
    return {
      queryKey: ["company", id],
      queryFn: fetchCompany,
      staleTime: Infinity
    };
  })
});

The useQueries hook accepts an options object with a queries key whose value is an array with query option objects identical to the useQuery hook

All queries run in parallel and a response is returned only after all companies are fetched.

Dependant Queries

Now that we know how to handle multiple queries parallely, we are also going to come across scenarios where we have to fetch the data sequentially i.e. when one query is dependent on another query before it can fetch the data.

Dependent (or serial) queries depend on previous ones to finish before they can execute. To achieve this, it's as easy as using the enabled option to tell a query when it is ready to run.

For this case let's say we have /githubUsers endpoint which returns a list of Github users, where each user being:

{
    "id": "jack@gmail.com",
    "githubId": "gf6ds5g4d5sf1g65dsf"
},

and we have /githubRepositories endpoint which returns the user data like:

{
  "id": "gf6ds5g4d5sf1g65dsf",
  "repositories": [
    "jack/react",
    "jack/next",
    "jack/angular",
    "jack/vue"
  ]
}

This is a simple scenario where dependent queries come into the picture. We cannot fetch the user repositories until we have the id of the user.

Using enabled config we choose to pause the execution of a query until the desired data is available.

const fetchGithubUser = ({ queryKey }) => {
  const userEmail = queryKey[1];
  return fetch(`http://localhost:4000/githubUsers/${userEmail}`).then(
    (response) => response.json()
  );
};

const fetchRepositories = ({ queryKey }) => {
  const userId = queryKey[1];
  return fetch(`http://localhost:4000/githubRepositories/${userId}`).then(
    (response) => response.json()
  );
};

const GihubUserRepos = () => {
    const userEmail = "jack@gmail.com";
    const { data: user } = useQuery(["github-user", userEmail], fetchGithubUser);

    const githubUserId = user?.githubId;
    const { data: userData } = useQuery(
      ["github-user-data", githubUserId], fetchRepositories, {
        enabled: !!githubUserId,
          }
        );

    const userRepos = userData?.repositories;
    console.log({ userRepos });

    return (
        <div>
            // map through the list of userRepos
        </div>
    );

Notice how we first fetch the Github user based on an email which in turn will not be immediately available so we use optional chaining to get the user id.

While fetching the repositories we provide the enabled config with value !!githubUserId, we use double negation to convert the id to a boolean value.

Initially, the user id is not available when the component mounts hence userId is kept as null, and react query tracks the query as disabled. Then once the githubId is available, that is used to fetch the user repositories.

That’s how dependant queries are managed by React Query.

Thank you for reading!

In this lesson, we went through a couple of ways using which we can tackle different data fetching problems that developers face while building applications.

In the next lesson, we will go through some advanced concepts which can enhance and improve the overall data fetching/viewing experience for users.

Feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Till then happy coding!

Configuring useQuery Hook

Nischal Dutt — Thu, 29 Sep 2022 19:02:24 +0000

Now that we have a basic understanding of useQuery hook, let's understand various ways through which we can configure our queries using the useQuery hook.

useQuery(’key’, function, { options go here }):

Lets dive in

`cacheTime`

Let's try re-fetching the query results without useQuery hook first i.e. with a simple useEffect hook.

You’ll notice, that every time we do a re-fetch, the loading state is encountered each time. This shows the results are not being cached and as a result, a hard reload happens for that particular query.

Now let us try this re-fetch with useQuery hook. You'll notice below that the loading state is not encountered every time a re-fetch occurs. This indicates that query responses are being cached by React-Query by default.

You can also view the cached content maintained by navigating to Query.cache.queries[0].state.data in the Query explorer section of devtools.
cacheTime takes in number of milliseconds a query responses must be saved in the cache after which, the cache will be cleared and the query will be re-fetched automatically in the background.
By default, cachTime is set to 5 minutes.
How cool is that! All the cache management is done by React-Query itself.

You might wonder how will we come to know if the background re-fetch is being done because the isLoading flag is not getting changed. For this specific reason React Query provides another flag isFetching which indicates the background fetching status of the query.
Also for re-fetching, a refetch function is returned that performs automatic re-fetch itself.

Below is the updated version of our code:

import React from "react";
import { useQuery } from "@tanstack/react-query";

async function fetchCompanies() {
  return await fetch(`http://localhost:4000/companies`).then((response) =>
    response.json()
  );
}

const Companies = () => {
  const {
    isLoading,
    data: companies,
    isError,
    error,
    isFetching,
    refetch,
  } = useQuery(["companies"], fetchCompanies, {
    cacheTime: 5000, // cache will be cleared after 5 seconds
  });

  if (isLoading) {
    return <h1>loading</h1>;
  }

  if (isError) {
    return <h1>{error.message}</h1>;
  }

  return (
    <div>
      {companies.map((company) => {
        return <h1 key={company.id}>{company.name}</h1>;
      })}
      <button onClick={refetch}>refetch</button>
    </div>
  );
};

Note that, isFetching indicates the background re-fetch status while isLoading indicates the normal ones.

`staleTime`

staleTime helps reduce the network requests to the server.

We specify staleTime in milliseconds after which the response from the query should be considered stale i.e. not fresh anymore.

By default staleTime is set to 0 milliseconds.

useQuery(["companies"], fetchCompanies, {
    staleTime: 10000,
});

For instance, consider the above call, the staleTime is 10 seconds, and the response will be marked fresh for the first 10 seconds, after which it will become stale.

So any changes in the list of companies for the first 10 seconds will not be reflected and no matter how many times we hit /companies endpoint no new network request will be generated, but once data becomes stale after 10 seconds updated list of companies will be fetched again in the background.

`refetchOnMount`

This option as the name suggests specifies whether to trigger re-fetch automatically when every time the component mounts. It can have 3 values:

true: re-fetches on mount of the component only if the data is stale
false: does not re-fetches on mount even if data is stale
always: re-fetches every time on mount of the component irrespective of whether data stale or not.

The default value is set to true and in most cases, it is best suited as well.

`refetchOnWindowFocus`

As the name suggests, a re-fetch occurs on focus of the window. This is similar to refetchonMount and the values are same as well.

useQuery(["companies"], fetchCompanies, {
    refetchOnMount: true,
    refetchOnWindow: true,
  });

`refetchInterval`

Sometimes we want to fetch the results from a query in regular intervals i.e. polling, we can do that by specifying the interval in milliseconds to this attribute.

Also by default, polling or automatic re-fetching is paused when the window loses focus, to prevent that from happening we can provide another config option called refetchIntervalInBackground and set it to true.

useQuery(["companies"\, fetchCompanies, {
    refetchInterval: 5000,
    refetchIntervalInBackground: true,
  });

Here query will be fetched every 5 seconds irrespective of whether window is focused or not.

Can it get more easier than this!!? :)

`enabled`

You might have noticed as soon our component mounts the query is fetched and we get the results, but what if we want to trigger the fetch only if we click a button. enabled prop will let us do that. By default it it set to true.

const Companies = () => {
  const {
    isLoading,
    data: companies,
    isError,
    error,
    isFetching,
    refetch,
  } = useQuery(["companies"], fetchCompanies, {
    enabled: false
  });

  if (isLoading) {
    return <h1>loading</h1>;
  }

  if (isError) {
    return <h1>{error.message}</h1>;
  }

  return (
    <div>
      {companies?.map((company) => {
        return <h1 key={company.id}>{company.name}</h1>;
      })}
      <button onClick={refetch}>fetch</button>
    </div>
  );
};

We use refetch function, pass it as an onClick handler to the button, and set enabled to false.
You can notice from devtools that initially when the component renders, the query key is marked as disabled hence no network request is triggered.

but when we click on the fetch button, the network request is fired and data is fetched.

`success` and `error` callback

After fetching the response from the query you might want to perform some side effects based on whether the query was successful or not. For this react query provides success and error callbacks which will run automatically after the query fetch is complete and thus, we can perform any sideEffects.

const onSuccess = (data) => {
    console.log(
      "performing the side-effect after successful fetch with response ==> ",
      data
    );
  };

  const onError = (error) => {
    console.log("encounter an error during fetching ==> ", error);
  };

  const { isLoading, data: companies, isError } = useQuery(
    ["companies"], 
    fetchCompanies, {
      onSuccess,
      onError,
    });

It is evident from above that, data and error objects are implicitly injected in onSuccess and onError callbacks respectively.

`select`

In select we define a function that is used to transform the data to our desirable format. For instance when we fetch the companies array, the response object looks like

{
   "id": 3,
   "name": "Apple",
   "founder": "Steve Jobs"
}

Now suppose we want to print the founders instead of company names, we can transform the array of company objects to array of founders using select function

const { isLoading, data, isError} = useQuery(["companies"], fetchCompanies, {
    select: (data) => {
      const founders = data.map((company) => company.founder);
      return founders;
    },
  });

Now the data returned from the useQuery hook will have only array of founders. We can perform manipulation like filtering, reducing an array etc as per our requirements.

Thank you for reading!

In the next section, we'll learn about some approaches for querying the data, which are pretty common in web development and we'll see how easy React Query makes it for us to handle such situations.

Feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Till then happy coding!

Getting Started with React Query

Nischal Dutt — Wed, 28 Sep 2022 18:53:21 +0000

The Missing Data Fetching Library

React-Query is often described as “The missing data fetching library” for React, because of the reason that React is a UI library that has no opinions on how we fetch the data from the server. The most basic form used by front-end developers to fetch the data is using Javascript’s fetch API, handling the requests with useEffect hook and managing the components states like loading, error, and resulting data using useState hook. Initially, the world is all fairyland but as soon as the project starts picking up stacks of complexity and we might require features like caching, synchronizing, and updating the server state, that’s when the reality hits hard and developers are left with the following options:

- Build your way to fetch and manage data: Since React applications do not come with an opinionated way of fetching or updating data from your components so developers end up building their ways of fetching data. This usually means cobbling together component-based states and effects using React hooks and keeping on building as things are. Though this is not a scalable approach and results in issues for which we are finding solutions in the first place.

- Using react management libraries: Another way is to use the state management libraries for React applications like Redux, Mobix, etc which store and provide asynchronous data throughout the app. While most traditional state management libraries are great for working with client states, they are not so great at working with async or server states. This is because the server state is completely different from the client state and remote as well.

According to React-Query docs, the server state:

Is persisted remotely in a location you do not control or own

Requires asynchronous APIs for fetching and updating

Implies shared ownership and can be changed by other people without your knowledge

Can potentially become "out of date" in your applications if you're not careful

Managing the server state with these libraries becomes even more challenging when the developers have to deal with caching, deduping multiple requests for the same data, updating stale data in the background, and performance optimizations like pagination and lazy loading data, etc.

The developers have to tackle all or most of these challenges and believe me we’re only scratching the surface here!

This is the hole that React-Query tries to fill up. It is one of the best if not the best, libraries for managing server state that works with zero-config and can be customized as per application needs.

According to React-Query docs, some advantages are as follows:

Reduction in Lines Of Code of your application

More emphasis on building new features instead of worrying about wiring up new server state data sources.

End-user satisfaction as data fetching is optimized and your application feels faster and more responsive.

Potentially help you save on bandwidth and increase memory performance

Installation

In your react app, You can install React Query via NPM

$ npm i @tanstack/react-query
# or
$ yarn add @tanstack/react-query

React query library module exports a provider component QueryClientProvider inside which we can wrap our App component.

import React from "react";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { ReactQueryDevtools } from '@tanstack/react-query-devtools'

const App = () => {
  return (
    <QueryClientProvider client={queryClient}>
       {/* The rest of your application */}

      <ReactQueryDevtools initialIsOpen={false} position="bottom-right" />
    </QueryClientProvider>
  );
};

Wrapping our app with the provider enables our app to leverage all the features that React-Query provides. We also need to instantiate the query client and pass it as a prop to the provider component. Now every child component wrapped inside the provider can fetch data using react query!
Also, React-Query provides out-of-the-box dedicated Devtools to facilitate debugging during the development. It helps in visualizing all of the inner workings of React Query and will likely save you hours of debugging if you find yourself in a pinch!

The devtools are a separate package that you need to install:

$ npm i @tanstack/react-query-devtools
# or
$ yarn add @tanstack/react-query-devtools

By default, React Query Devtools are only included in bundles when process.env.NODE_ENV === 'development', so you don't need to worry about excluding them during a production build.

Setting up async mock API

To emulate the data fetching process We are going to use the JSON-Server to create a /companies route that returns a list of companies.
Using a standard approach to fetch the data and display it on the web page we use React’s useEffect and useState hooks as follows:

import React, { useEffect } from "react";

async function fetchCompanies() {
  return await fetch(`http://localhost:4000/companies`).then((response) =>
    response.json()
  );
}

const Companies = () => {
  const [companies, setCompanies] = React.useState([]);
  const [isLoading, setIsLoading] = React.useState(true);
  const [isError, setIsError] = React.useState(false);

  useEffect(() => {
    fetchCompanies()
      .then((response) => {
        setCompanies(response);
        setIsLoading(false);
      })
      .catch((_error) => setIsError(true));
  }, []);

  if (isLoading) {
    return <div>loading</div>;
  }

  if (isError) {
    return <div>error occurred</div>;
  }

  return (
    <div>
      {companies.map((company) => {
        return <div key={company.id}>{company.name}</div>;
      })}
    </div>
  );
};

export default Companies;

It is evident from above that even for such a simple scenario we have to maintain 3 state variables to handle the application state.

Now let's try this with React-Query now

import React from "react";
import { useQuery } from "@tanstack/react-query";

async function fetchCompanies() {
  return await fetch(`http://localhost:4000/companies`).then((response) =>
    response.json()
  );
}

const Companies = () => {
  const {
    isLoading,
    data: companies,
    isError,
    error,
  } = useQuery(["companies"], fetchCompanies);

  if (isLoading) {
    return <div>loading</div>;
  }

  if (isError) {
    return <div>{error.message}</div>;
  }

  return (
    <div>
      {companies.map((company) => {
        return <h1 key={company.id}>{company.name}</h1>;
      })}
    </div>
  );
};

export default Companies;

Woah! What just happened? What’s this useQuery and what is it returning? Why aren’t we maintaining loading and error states separately?

Let us understand one thing at a time.

useQuery is the hook made available by React-Query that is used to fetch the data from external API resource. By definition, it can have 3 arguments

useQuery(”QUERY_KEY”, FETCH_FUNCTION, { …OPTIONS });

QUERY_KEY is just a key that can uniquely identify a query across your application. You might come up with why the identification of any query is required? It is required as the data from the API might get outdated or the query response gets invalid, React-Query will trigger a re-fetch automatically when any of the above happens so it needs to know which query to re-fetch.

As per React query docs:

React Query manages query caching for you based on query keys. Query keys have to be an Array at the top level, and can be as simple as an Array with a single string, or as complex as an array of many strings and nested objects. As long as the query key is serializable, and unique to the query's data, you can use it!

FETCH_FUNCTION your data fetching logic goes here
OPTIONS object here we can configure our query response like stale time, cache time, enabled, etc. More on this in the next lessons.

useQuery hook returns various methods and variables that represent the query request phases and response like:

data: (3) [{…}, {…}, {…}]
dataUpdatedAt: 1654966057499
error: null
errorUpdateCount: 0
errorUpdatedAt: 0
failureCount: 0
isError: false
isFetched: true
isFetchedAfterMount: true
isFetching: false
isIdle: false
isLoading: false
isLoadingError: false
isPlaceholderData: false
isPreviousData: false
isRefetchError: false
isRefetching: false
isStale: true
isSuccess: true
refetch: ƒ ()
remove: ƒ ()
status: "success"

You can go through these but at the moment we only require the isLoading and isError states. You can see here how react query internally handles all the states automatically without any issues.
For the query response you can have a look at React-Query Devtools as well, just click on the query key and the details of that query will be opened as below

Thank you for reading!

That’s how React-Query abstracts away a lot of data fetching and management logic from the component.
In the next chapter, we will dive into the configuration options that we can use to configure the query using the options parameter in the useQuery hook.

Feel free to reach out to me! 😊

💻 Github ✨ Twitter 💌 Email 💡Linkedin

Till then happy coding!