Data Fetching Patterns in Single-Page Applications

Implementing Asynchronous State Handler in React with hooks

The pattern can be implemented in different frontend libraries. For
instance, we could distill this approach into a custom Hook in a React
application for the Profile component:

import { useEffect, useState } from "react";
import { get } from "../utils.ts";

const useUser = (id: string) => {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState();
  const [user, setUser] = useState();

  useEffect(() => {
    const fetchUser = async () => {
      try {
        setLoading(true);
        const data = await get(`/users/${id}`);
        setUser(data);
      } catch (e) {
        setError(e as Error);
      } finally {
        setLoading(false);
      }
    };

    fetchUser();
  }, tag:martinfowler.com,2024-05-23:Code-Splitting-in-Single-Page-Applications);

  return {
    loading,
    error,
    user,
  };
};

Please note that in the custom Hook, we don’t have any JSX code –
meaning it’s totally UI free but sharable stateful logic. And the
useUser launch data automatically when called. Within the Profile
component, leveraging the useUser Hook simplifies its logic:

import { useUser } from './useUser.ts';
import UserBrief from './UserBrief.tsx';

const Profile = ({ id }: { id: string }) => {
  const { loading, error, user } = useUser(id);

  if (loading || !user) {
    return 
Loading...
;
  }

  if (error) {
    return 
Something went wrong...
;
  }

  return (
    <>
      {user && }
    >
  );
};

Generalizing Parameter Usage

In most applications, fetching different types of data—from user
details on a homepage to product lists in search results and
recommendations beneath them—is a common requirement. Writing separate
fetch functions for each type of data can be tedious and difficult to
maintain. A better approach is to abstract this functionality into a
generic, reusable hook that can handle various data types
efficiently.

Consider treating remote API endpoints as services, and use a generic
useService hook that accepts a URL as a parameter while managing all
the metadata associated with an asynchronous request:

import { get } from "../utils.ts";

function useService(url: string) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState();
  const [data, setData] = useState();

  const fetch = async () => {
    try {
      setLoading(true);
      const data = await get(url);
      setData(data);
    } catch (e) {
      setError(e as Error);
    } finally {
      setLoading(false);
    }
  };

  return {
    loading,
    error,
    data,
    fetch,
  };
}

This hook abstracts the data fetching process, making it easier to
integrate into any component that needs to retrieve data from a remote
source. It also centralizes common error handling scenarios, such as
treating specific errors differently:

import { useService } from './useService.ts';

const {
  loading,
  error,
  data: user,
  fetch: fetchUser,
} = useService(`/users/${id}`);

By using useService, we can simplify how components fetch and handle
data, making the codebase cleaner and more maintainable.

Variation of the pattern

A variation of the useUser would be expose the
fetchUsers function, and it does not trigger the data
fetching itself:

import { useState } from "react";

const useUser = (id: string) => {
  // define the states

  const fetchUser = async () => {
    try {
      setLoading(true);
      const data = await get(`/users/${id}`);
      setUser(data);
    } catch (e) {
      setError(e as Error);
    } finally {
      setLoading(false);
    }
  };

  return {
    loading,
    error,
    user,
    fetchUser,
  };
};

And then on the calling site, Profile component use
useEffect to fetch the data and render different
states.

const Profile = ({ id }: { id: string }) => {
  const { loading, error, user, fetchUser } = useUser(id);

  useEffect(() => {
    fetchUser();
  }, []);

  // render correspondingly
};

The advantage of this division is the ability to reuse these stateful
logics across different components. For instance, another component
needing the same data (a user API call with a user ID) can simply import
the useUser Hook and utilize its states. Different UI
components might choose to interact with these states in various ways,
perhaps using alternative loading indicators (a smaller spinner that
fits to the calling component) or error messages, yet the fundamental
logic of fetching data remains consistent and shared.

Implementing Parallel Data Fetching in React

Upon application launch, data fetching begins, abstracting the
fetching process from subcomponents. For example, in Profile component,
both UserBrief and Friends are presentational components that react to
the passed data. This way we could develop these component separately
(adding styles for different states, for example). These presentational
components normally are easy to test and modify as we have separate the
data fetching and rendering.

We can define a custom hook useProfileData that facilitates
parallel fetching of data related to a user and their friends by using
Promise.all. This method allows simultaneous requests, optimizing the
loading process and structuring the data into a predefined format known
as ProfileData.

Here’s a breakdown of the hook implementation:

import { useCallback, useEffect, useState } from "react";

type ProfileData = {
  user: User;
  friends: User[];
};

const useProfileData = (id: string) => {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(undefined);
  const [profileState, setProfileState] = useState();

  const fetchProfileState = useCallback(async () => {
    try {
      setLoading(true);
      const [user, friends] = await Promise.all([
        get(`/users/${id}`),
        get(`/users/${id}/friends`),
      ]);
      setProfileState({ user, friends });
    } catch (e) {
      setError(e as Error);
    } finally {
      setLoading(false);
    }
  }, tag:martinfowler.com,2024-05-23:Code-Splitting-in-Single-Page-Applications);

  return {
    loading,
    error,
    profileState,
    fetchProfileState,
  };

};

This hook provides the Profile component with the
necessary data states (loading, error,
profileState) along with a fetchProfileState
function, enabling the component to initiate the fetch operation as
needed. Note here we use useCallback hook to wrap the async
function for data fetching. The useCallback hook in React is used to
memoize functions, ensuring that the same function instance is
maintained across component re-renders unless its dependencies change.
Similar to the useEffect, it accepts the function and a dependency
array, the function will only be recreated if any of these dependencies
change, thereby avoiding unintended behavior in React’s rendering
cycle.

The Profile component uses this hook and controls the data fetching
timing via useEffect:

const Profile = ({ id }: { id: string }) => {
  const { loading, error, profileState, fetchProfileState } = useProfileData(id);

  useEffect(() => {
    fetchProfileState();
  }, [fetchProfileState]);

  if (loading) {
    return 
Loading...
;
  }

  if (error) {
    return 
Something went wrong...
;
  }

  return (
    <>
      {profileState && (
        <>
          
          
        >
      )}
    >
  );
};

This approach is also known as Fetch-Then-Render, suggesting that the aim
is to initiate requests as early as possible during page load.
Subsequently, the fetched data is utilized to drive React’s rendering of
the application, bypassing the need to manage data fetching amidst the
rendering process. This strategy simplifies the rendering process,
making the code easier to test and modify.

And the component structure, if visualized, would be like the
following illustration

Figure 8: Component structure after refactoring

And the timeline is much shorter than the previous one as we send two
requests in parallel. The Friends component can render in a few
milliseconds as when it starts to render, the data is already ready and
passed in.

Figure 9: Parallel requests

Note that the longest wait time depends on the slowest network
request, which is much faster than the sequential ones. And if we could
send as many of these independent requests at the same time at an upper
level of the component tree, a better user experience can be
expected.

As applications expand, managing an increasing number of requests at
root level becomes challenging. This is particularly true for components
distant from the root, where passing down data becomes cumbersome. One
approach is to store all data globally, accessible via functions (like
Redux or the React Context API), avoiding deep prop drilling.

Implementing Fallback Markup in React with Suspense

Suspense in React is a mechanism for efficiently handling
asynchronous operations, such as data fetching or resource loading, in a
declarative manner. By wrapping components in a Suspense boundary,
developers can specify fallback content to display while waiting for the
component’s data dependencies to be fulfilled, streamlining the user
experience during loading states.

While with the Suspense API, in the Friends you describe what you
want to get and then render:

import useSWR from "swr";
import { get } from "../utils.ts";

function Friends({ id }: { id: string }) {
  const { data: users } = useSWR("/api/profile", () => get(`/users/${id}/friends`), {
    suspense: true,
  });

  return (
    

      
Friends
      

        {friends.map((user) => (
          
        ))}
      
    
  );
}

And declaratively when you use the Friends, you use
Suspense boundary to wrap around the Friends
component:

}>
  

Suspense manages the asynchronous loading of the
Friends component, showing a FriendsSkeleton
placeholder until the component’s data dependencies are
resolved. This setup ensures that the user interface remains responsive
and informative during data fetching, improving the overall user
experience.

Use the pattern in Vue.js

It’s worth noting that Vue.js is also exploring a similar
experimental pattern, where you can employ Fallback Markup using:

Upon the first render, attempts to render
its default content behind the scenes. Should it encounter any
asynchronous dependencies during this phase, it transitions into a
pending state, where the fallback content is displayed instead. Once all
the asynchronous dependencies are successfully loaded,
moves to a resolved state, and the content
initially intended for display (the default slot content) is
rendered.

Deciding Placement for the Loading Component

You may wonder where to place the FriendsSkeleton
component and who should manage it. Typically, without using Fallback
Markup, this decision is straightforward and handled directly within the
component that manages the data fetching:

const Friends = ({ id }: { id: string }) => {
  // Data fetching logic here...

  if (loading) {
    // Display loading indicator
  }

  if (error) {
    // Display error message component
  }

  // Render the actual friend list
};

In this setup, the logic for displaying loading indicators or error
messages is naturally situated within the Friends component. However,
adopting Fallback Markup shifts this responsibility to the
component’s consumer:

}>
  

In real-world applications, the optimal approach to handling loading
experiences depends significantly on the desired user interaction and
the structure of the application. For instance, a hierarchical loading
approach where a parent component ceases to show a loading indicator
while its children components continue can disrupt the user experience.
Thus, it’s crucial to carefully consider at what level within the
component hierarchy the loading indicators or skeleton placeholders
should be displayed.

Think of Friends and FriendsSkeleton as two
distinct component states—one representing the presence of data, and the
other, the absence. This concept is somewhat analogous to using a Speical Case pattern in object-oriented
programming, where FriendsSkeleton serves as the ‘null’
state handling for the Friends component.

The key is to determine the granularity with which you want to
display loading indicators and to maintain consistency in these
decisions across your application. Doing so helps achieve a smoother and
more predictable user experience.

Leveraging the Dynamic Import Operator

The dynamic import operator in JavaScript streamlines the process of
loading modules. Though it may resemble a function call in your code,
such as import("./user-detail-card.tsx"), it’s important to
recognize that import is actually a keyword, not a
function. This operator enables the asynchronous and dynamic loading of
JavaScript modules.

With dynamic import, you can load a module on demand. For example, we
only load a module when a button is clicked:

button.addEventListener("click", (e) => {

  import("/modules/some-useful-module.js")
    .then((module) => {
      module.doSomethingInteresting();
    })
    .catch(error => {
      console.error("Failed to load the module:", error);
    });
});

The module is not loaded during the initial page load. Instead, the
import() call is placed inside an event listener so it only
be loaded when, and if, the user interacts with that button.

You can use dynamic import operator in React and libraries like
Vue.js. React simplifies the code splitting and lazy load through the
React.lazy and Suspense APIs. By wrapping the
import statement with React.lazy, and subsequently wrapping
the component, for instance, UserDetailCard, with
Suspense, React defers the component rendering until the
required module is loaded. During this loading phase, a fallback UI is
presented, seamlessly transitioning to the actual component upon load
completion.

import React, { Suspense } from "react";
import { Popover, PopoverContent, PopoverTrigger } from "@nextui-org/react";
import { UserBrief } from "./user.tsx";

const UserDetailCard = React.lazy(() => import("./user-detail-card.tsx"));

export const Friend = ({ user }: { user: User }) => {
  return (
    
      
        
          
        
      
      
        Loading...