Learning Objectives
By the end of this chapter, you will be able to do the following:
Use React Router to fetch or send data without using useEffect() or useState()
Share data between different routes without using React's context feature
Update the UI based on the current data submission status
Create page and action routes
Improve the user experience by deferring the loading of non-critical data
Introduction
In the preceding chapter, you learned how to use React Router to load different components for different URL paths. This is an important feature as it allows you to build multipage websites while still using React.
Routing is a crucial feature for many web applications, and React Router is therefore a very important package. But just as most websites need routing, almost all websites need to fetch and manipulate data. For example, HTTP requests in most websites are sent to load data (such as a list of products or blog posts) or to mutate data (for example, to create a product or a blog post).
In Chapter 8, Handling Side Effects, you learned that you can use the useEffect() Hook and various other React features to send HTTP requests from inside a React application. But if you're using React Router (specifically, version 6.4. or higher), you get some new, even more powerful tools for working with data.
This chapter will explore which new features are added by React Router 6.4 and how they may be used to simplify the process of fetching or sending data.
Data Fetching and Routing Are Tightly Coupled
As mentioned previously, most websites do need to fetch (or send) data and most websites do need more than one page. But it's important to realize that these two concepts are typically closely related.
Whenever a user visits a new page (such as /posts), it's likely that some data will need to be fetched. In the case of a /posts page, the required data is probably a list of blog posts that is retrieved from a backend server. The rendered React component (such as Posts) must therefore send an HTTP request to the backend server, wait for the response, handle the response (as well as potential errors) and, ultimately, display the fetched data.
Of course, not all pages need to fetch data. Landing pages, "About Us" pages, or "Terms & Use" pages probably don't need to fetch data when a user visits them. Instead, data on those pages is likely to be static. It might even be included in the source code as it doesn't change frequently.
But many pages do need to get data from a backend every time they're loaded—for instance, "Products", "News", "Events" pages, or other infrequently updated pages like the "User Profile".
And data fetching isn't everything. Most websites also contain features that require data submission—be it a blog post that can be created or updated, product data that's administered, or a user comment that can be added. Hence, sending data to a backend is also a very common use case.
And beyond requests, components might also need to interact with other browser APIs, such as localStorage. For example, user settings might need to be fetched from storage as a certain page loads.
Naturally, all these interactions happen on pages. But it might not be immediately obvious how tightly data fetching and submission are coupled to routing.
Most of the time, data is fetched when a route becomes active, i.e., when a component (the page component) is rendered for the first time. Sure, users might also be able to click a button to refresh the data, but while this is optional, data fetching upon initial page load is almost always required.
And when it comes to sending data, there is also a close connection to routing. At first sight, it's not clear how it's related because, while it makes sense to fetch data upon page load, it's less likely that you will need to send some data immediately (except perhaps tracking or analytics data).
But it's very likely that after sending data, you will want to navigate to a different page, meaning that it's actually the other way around and instead of initiating data fetching as a page loads, you want to load a different page after sending some data. For example, after an administrator entered some product data and submitted the form, they should typically be redirected to a different page (for example, from /products/new to the /products page).
The connection between data fetching, submission, and routing can therefore be summarized by the following points:
- Data fetching often should be initiated when a route becomes active (if that page needs data)
- After submitting data the user should often be redirected to another route
Because these concepts are tightly coupled, React Router (since version 6.4) provides extra features that vastly simplify the process of working with data.
Sending HTTP Requests without React Router
Working with data is not just about sending HTTP requests. As mentioned in the previous section, you may also need to store or retrieve data via localStorage or perform some other operation as a page gets loaded. But sending HTTP requests is an especially common scenario and will therefore be the main use case considered for the majority of this chapter. Nonetheless, it's vital to keep in mind that what you learn in this chapter is not limited to sending HTTP requests.
As you will learn in this chapter, React Router (6.4 or higher) provides various features that help with sending HTTP requests (or using other data fetching and manipulation APIs) and routing, but you can also send HTTP requests (or interact with localStorage or other APIs) without these features. Indeed, Chapter 8, Handling Side Effects, already taught you how HTTP requests can be sent from inside React components.
The following snippet exemplifies how a given list of blog posts could be fetched and displayed:
import { useState, useEffect } from 'react';
function Posts() {
const [loadedPosts, setLoadedPosts] = useState();
const [isLoading, setIsLoading] = useState(false);
const [error, setError] = useState();
useEffect(() => {
async function fetchPosts() {
setIsLoading(true);
try {
const response = await fetch(
'https://jsonplaceholder.typicode.com/posts'
);
if (!response.ok) {
throw new Error('Fetching posts failed.');
}
const resData = await response.json();
setLoadedPosts(resData);
} catch (error) {
setError(error.message);
}
setIsLoading(false);
}
fetchPosts();
}, []);
let content = <p>No posts found.</p>;
if (isLoading) {
content = <p>Loading...</p>;
}
if (error) {
content = <p>{error}</p>;
}
if (loadedPosts) {
content = (
<ul className="posts">
{loadedPosts.map((post) => (
<li key={post.id}>{post.title}</li>
))}
</ul>
);
}
return (
<main>
<h1>Your Posts</h1>
{content}
</main>
);
}
This example component uses the same dummy backend server (returning dummy data) that was used in Chapter 8, Handling Side Effects: https://jsonplaceholder.typicode.com.
Note
You can find the complete code on GitHub at https://packt.link/hlXz6.
This backend returns a list of blog posts, which are then displayed as list items by the Posts component. However, these items are only displayed if the following statements are true:
- The HTTP request is done (i.e., isLoading is false)
- There is no error (i.e., error is undefined or null)
The request is sent via useEffect(). The fetchPosts() function defined in useEffect() is called when the component renders for the first time. That's the case because useEffect() has an empty list of dependencies. It therefore only executes once.
This example contains no new concepts. Instead, all these topics (and a very similar example) were covered in Chapter 8, Handling Side Effects. But even though it's a relatively basic example, where only one request is sent and the response data can be used without any further transformations, quite a bit of code is required to implement this functionality.
And that's where React Router (6.4. or higher) comes in.
Loading Data with React Router
With React Router, the example from the previous chapter can be simplified down to this code snippet:
import { useLoaderData } from 'react-router-dom';
function Posts() {
const loadedPosts = useLoaderData();
return (
<main>
<h1>Your Posts</h1>
<ul className="posts">
{loadedPosts.map((post) => (
<li key={post.id}>{post.title}</li>
))}
</ul>
</main>
);
}
export default Posts;
export async function loader() {
const response = await fetch('https://jsonplaceholder.typicode.com/posts');
if (!response.ok) {
throw new Error('Could not fetch posts');
}
return response;
}
Believe it or not, it really is that much less code than in the previous example. Though, to be fair, the content that should be displayed in case of an error is missing here. It's in a separate file (which will be shown later), but it would only add three extra lines of code.
Note
Don't try pasting the preceding example into an existing React app—even if that app has React Router 6.4 installed. A special route definition syntax (introduced later in this chapter) is required to enable these new React Router features.
In the preceding code snippet, you see a couple of new features that haven't been covered yet in the book. The loader() function and the useLoaderData() Hook are added by React Router. These features, along with many others that will be explored throughout this chapter, have been available since version 6.4 of the React Router package.
With that version (or a more recent one) installed, you can set an extra loader prop on your route definitions. This prop accepts a function that will be executed by React Router whenever this route is activated:
<Route path="/posts" element={<Posts />} loader={() => {...}} />
This function can be used to perform any data fetching or other tasks required to successfully display the page component. The logic for getting that required data can therefore be extracted from the component and moved into a separate function.
Since many websites have dozens or even hundreds of routes, adding these loader functions inline on the <Route /> element can quickly lead to complex and confusing route definitions. For this reason, you will typically add (and export) the loader() function in the same file that contains the component that needs the data.
When setting up the route definitions, you can then import the component and its loader function and use it like this:
import Posts, { loader as postsLoader } from './components/Posts';
// … other code …
<Route path="/posts" element={<Posts />} loader={postsLoader} />
Assigning an alias (postsLoader, in this example) to the imported loader function is optional but recommended since you most likely have multiple loader functions from different components, which would otherwise lead to name clashes.
With this loader defined, React Router will execute the loader() function whenever a route is activated. To be precise, the loader() function is called before the component function is executed (that is, before the component is rendered).
Figure 13.1: The Posts component is rendered after the loader is executed
This also explains why the Posts component example at the beginning of this section contained no code that handled any loading state. This is simply because there was no loading state since a component function is only executed after its loader has finished (and the data is available). React Router won't finish the page transition until the loader() function has finished its job (though, as you will learn towards the end of this chapter, there is a way of changing this behavior).
The loader() function can perform any operation of your choice (such as sending an HTTP request, or reaching out to browser storage via the localStorage API). Inside that function, you should return the data that should be exposed to the component function. It's also worth noting that the loader() function can return any kind of data. It may also return a Promise object that then resolves to any kind of data. In that case, React Router will automatically wait for the Promise to be fulfilled before executing the related route component function. The loader() function can thus perform both asynchronous and synchronous tasks.
Note
It's important to understand that the loader() function, like all the other code that makes up your React app, executes on the client side (that is, in the browser of a website visitor). Therefore, you may perform any action that could be performed anywhere else (for example, inside useEffect()) in your React app as well.
You must not try to run code that belongs to the server side. Directly reaching out to a database, writing to the file system, or performing any other server-side tasks will fail or introduce security risks, meaning that you might accidentally expose database credentials on the client side.
Of course, the component that belongs to a loader (that is, the component that's part of the same <Route /> definition) needs the data returned by the loader. This is why React Router offers a new Hook for accessing that data: the useLoaderData() Hook.
When called inside a component function, this Hook yields the data returned by the loader that belongs to the component. If that returned data is a Promise, React Router (as mentioned earlier) will automatically wait for that Promise to resolve and provide the resolved data when useLoaderData() is called.
The loader() function may also return an HTTP response object (or a Promise resolving to a response). This is the case in the preceding example because the fetch() function yields a Promise that resolves to a response. In that instance, useLoaderData() automatically extracts the response body and provides direct access to the data that was attached to the response.
Note
If a response should be returned, the returned object must adhere to the standard Response interface, as defined here: https://developer.mozilla.org/en-US/docs/Web/API/Response.
Returning responses might be strange at first. After all, the loader() code is still executed inside the browser (not on a server). Therefore, technically, no request was sent, and no response should be required (since the entire code is executed in the same environment, that is, the browser).
For that reason, you don't have to return a response; you may return any kind of value. But Remix supports the usage of a response object (as a "data vehicle") as an alternative.
useLoaderData() can be called in any component rendered by the currently active route component. That may be the route component itself (Posts, in the preceding example), but it may also be any nested component.
For example, useLoaderData() can also be used in a PostsList component that's included in the Posts component (which has a loader added to its route definition):
import { useLoaderData } from 'react-router-dom';
function PostsList() {
const loadedPosts = useLoaderData();
return (
<main>
<h1>Your Posts</h1>
<ul className="posts">
{loadedPosts.map((post) => (
<li key={post.id}>{post.title}</li>
))}
</ul>
</main>
);
}
export default PostsList;
For this example, the Posts component file looks like this:
import PostsList from '../components/PostsList';
function Posts() {
return (
<main>
<h1>Your Posts</h1>
<PostsList />
</main>
);
}
export default Posts;
export async function loader() {
const response = await fetch('https://jsonplaceholder.typicode.com/posts');
if (!response.ok) {
throw new Error('Could not fetch posts');
}
return response;
}
This means that useLoaderData() can be used in exactly the place where you need the data. The loader() function can also be defined wherever you want but it must be added to the route where the data is required.
You can't use useLoaderData() in components where no loader is defined for the currently active route.
Enabling These Extra Router Features
If you want to use these data-related React Router features, it's not enough to have version 6.4 or higher installed. This is an important prerequisite, but you also must tweak your route definition code a little bit.
In Chapter 12, Multipage Apps with React Router, you learned that routes can be defined as follows:
import { BrowserRouter, Routes, Route } from 'react-router-dom';
import Posts from './pages/Posts';
import Welcome from './pages/Welcome';
function App() {
return (
<BrowserRouter>
<Routes>
<Route index element={<Welcome />} />
<Route path="/posts" element={<Posts />} />
</Routes>
</BrowserRouter>
);
}
You can still do that with version 6.4, but you won't be able to use React Router's new data-related features. Instead, to enable these features, the preceding route definition code must be changed to look like this:
import {
createBrowserRouter,
createRoutesFromElements,
Route,
RouterProvider,
} from 'react-router-dom';
import Posts, { loader as postsLoader } from './pages/Posts';
import Welcome from './pages/Welcome';
const router = createBrowserRouter(
createRoutesFromElements(
<>
<Route path="/" element={<Welcome />} />
<Route path="/posts" element={<Posts />} loader={postsLoader} />
</>
)
);
function App() {
return <RouterProvider router={router} />;
}
Instead of returning <BrowserRouter> (which includes the route definitions, wrapped by <Routes>), you must now create a router object by calling createBrowserRouter().
This function then accepts an array of route definition objects. You can create this array on your own (shown later) or get a valid list of objects by executing createRoutesFromElements() and passing your route definition JSX code to that function.
Note that createRoutesFromElements() only takes a single element, such as a fragment (see Chapter 2, Understanding React Components and JSX), as used in this example, or a <Route> element. This single element is wrapped around all other <Route> elements.
The created router object is then passed as a value for the router prop to the <RouterProvider> component.
As an alternative to createRoutesFromElements(), you can also define your route objects manually, like this:
const router = createBrowserRouter([
{ path: '/', element: <Welcome /> },
{ path: '/posts', element: <Posts />, loader: postsLoader },
]);
This approach is a bit more concise, though it may be unfamiliar. Essentially, instead of using React components (such as <Route>) to define routes, you would use plain JavaScript objects (grouped into an array) for this method.
You can use whichever approach you prefer. Conceptually and feature-wise there is no difference between the two.
Loading Data for Dynamic Routes
For most websites, it's unlikely that static, pre-defined routes alone will be sufficient to meet your needs. For instance, if you created a blogging site with exclusively static routes, you would be limited to a simple list of blog posts on /posts. To add more details about a selected blog post on routes such as /posts/1 or /posts/2 (for posts with different id values) you would need to include dynamic routes.
As you learned in the previous chapter, dynamic routes can be defined like this:
<Route path="/posts/:id" element={<PostDetails />} />
This code still works (when using createRoutesFromElements()), though you can also use the alternative approach of defining route objects, as mentioned earlier, and define a dynamic route (via createBrowserRouter()), as shown here:
const router = createBrowserRouter([
// … other routes
{ path: '/posts/:id', element: <PostDetails /> }
]);
Of course, React Router also supports data fetching with help of the loader() function for dynamic routes.
The PostDetails component can be implemented like this:
import { useLoaderData } from 'react-router-dom';
function PostDetails() {
const post = useLoaderData();
return (
<main id="post-details">
<h1>{post.title}</h1>
<p>{post.body}</p>
</main>
);
}
export default PostDetails;
export async function loader({ params }) {
const response = await fetch(
'https://jsonplaceholder.typicode.com/posts/' + params.id
);
if (!response.ok) {
throw new Error('Could not fetch post for id ' + params.id);
}
return response;
}
If it looks very similar to the Posts component in the "Loading Data with React Router" section, that's no coincidence. Because the loader() function works in exactly the same way, there is just one extra feature being used to get hold of the dynamic path segment value: a params object that's made available by React Router.
When adding a loader() function to a route definition, React Router calls that function whenever the route becomes active, right before the component is rendered. When executing that function, React Router passes an object that contains extra information as an argument to loader().
This object passed to loader() includes two main properties:
- A request property that contains an object with more details about the request that led to the route activation
- A params property that yields an object containing a key-value map of all dynamic route parameters for the active route
The request object doesn't matter for this example and will be discussed in the next section. But the params object contains an id property that carries the id value of the post for which the route is loaded. The property is named id because, in the route definition, /posts/:id was chosen as a path. If a different placeholder name had been chosen, a property with that name would have been available on params (for example, for /posts/:postId, this would be params.postId). This behavior is similar to the params object yielded by useParams(), as explained in Chapter 12, Multipage Apps with React Router.
With help of the params object and the post id, the appropriate post id can be included in the outgoing request URL (for the fetch() request), and hence the correct post data can be loaded from the backend API. Once the data arrives, React Router will render the PostDetails component and expose the loaded post via the useLoaderData() Hook.
Loaders, Requests, and Client-Side Code
In the preceding section, you learned about a request object being provided to the loader() function. Getting such a request object might be confusing because React Router is a client-side library—all the code executes in the browser, not on a server. Therefore, no request should reach the React app (as HTTP requests are sent from the client to the server, not between JavaScript functions on the client side).
And, indeed, there is no request being sent via HTTP. Instead, React Router creates a request object via the browser's built-in Request interface to use it as a "data vehicle." This request is not sent via HTTP, but it's used as a value for the request property on the data object that is passed to your loader() function.
Note
For more information on the built-in Request interface, visit https://developer.mozilla.org/en-US/docs/Web/API/Request.
This request object will be unnecessary in many loader functions, but there are occasional scenarios in which you can extract useful information from that object—information that might be needed in the loader to fetch the right data.
For example, you can use the request object and its url property to get access to any search parameters (query parameters) that may be included in the currently active page's URL:
export async function loader({ request }) {
// e.g. for localhost:3000/posts?sort=desc
const sortDirection = new URL(request.url).searchParams.get('sort');
// Example: Fetch sorted posts, based on local 'sort' query param value
const response = await fetch(
'https://example.com/posts?sorting=' + sortDirection
);
return response;
}
In this code snippet, the request value is used to get hold of a query parameter value that's used in the React app URL. That value is then used in an outgoing request.
However, it is vital that you keep in mind that the code inside your loader() function, just like all your other React code, always executes on the client side (at least, as long as you don't combine React with any other frameworks like NextJS or Remix).
Note
These frameworks are beyond the scope of this book. Both NextJS and Remix build up on top of React and, for example, add server-side rendering of React components. Visit https://nextjs.org or https://remix.run for more information. In addition, the author also offers courses for both frameworks. For NextJS, visit https://acad.link/nextjs and, for Remix, visit https://acad.link/remix.
Layouts Revisited
React Router supports the concept of layout routes. These are routes that contain other routes and render those other routes as nested children, and as you may recall, this concept was introduced in Chapter 12, Multipage Apps with React Router.
With React Router 6.4, a layout route can be defined like this:
const router = createBrowserRouter([
{
path: '/',
element: <Root />,
children: [
{ index: true, element: <Welcome /> },
]
}
]);
The index route is a child route of the / route, which in turn is the layout route in this example. The Root component could look like this:
function Root() {
return (
<>
<header>
<MainNavigation />
</header>
<Outlet />
</>
);
}
As mentioned, layout routes were introduced in the previous chapter. But when using the extra data capabilities offered by React Router, there are two noteworthy changes:
- Unlike with <BrowserRouter />, if you need some shared layout, you can't wrap a React component around your route definitions. createBrowserRouter() only accepts React fragments and <Route /> elements—no other components. For that reason, you must use a layout route as shown in the previous example instead.
- Layout routes can also be used to share data across routes without using React's context feature.
Because of the first point, you'll typically use more layout routes than you did prior to the release of React Router 6.4. Before that version, you could simply wrap any component you wanted around your route definitions. For example, the following code works without issue:
import { BrowserRouter, Routes, Route } from 'react-router-dom';
import Layout from './components/shared/Layout';
import Dashboard from './routes/Dashboard';
import Orders from './routes/Orders';
function App() {
return (
<BrowserRouter>
<Layout>
<Routes>
<Route path="/" element={<Dashboard />} />
<Route path="/orders" element={<Orders />} />
</Routes>
</Layout>
</BrowserRouter>
);
}
export default App;
Since BrowserRouter does not support the extra data capabilities (such as the loader() function) you must use createBrowserRouter() instead. But createBrowserRouter() does not accept anything but route definitions. That's why shared layouts must be implemented via layout routes instead of wrapper components.
The second point is the more interesting one, though. Layout routes can be used for sharing data across routes.
Consider this example website:
Figure 13.2: A website with a header, a sidebar, and some main content
This website has a header with a navigation bar, a sidebar showing a list of available posts, and a main area that displays the currently selected blog post.
Note
The dummy data shown in Figure 13.2 is fetched from https://jsonplaceholder.typicode.com/posts. You will find the complete source code for this example at https://packt.link/Ef8LS.
This example includes two layout routes:
- The root layout route, which includes the top navigation bar that is shared across all pages
- A posts layout route, which includes the sidebar and the main content of its child routes (for example, the details for a selected post)
The route definitions code looks like this:
const router = createBrowserRouter([
{
path: '/',
element: <Root />, // main layout, adds navigation bar
children: [
{ index: true, element: <Welcome /> },
{
path: '/posts',
element: <PostsLayout />, // posts layout, adds posts sidebar
loader: postsLoader,
children: [
{ index: true, element: <Posts /> },
{ path: ':id', element: <PostDetails />, loader: postDetailLoader },
],
},
],
},
]);
With this setup, both the <Posts /> and the <PostDetails /> components are rendered next to the sidebar (since the sidebar is part of the <PostsLayout /> element).
The interesting part is that the /posts route (i.e., the layout route) loads the post data, as it has the postsLoader assigned to it, and so the PostsLayout component file looks like this:
import { Outlet, useLoaderData } from 'react-router-dom';
import PostsList from '../components/PostsList';
function PostsLayout() {
const loadedPosts = useLoaderData();
return (
<div id="posts-layout">
<nav>
<PostsList posts={loadedPosts} />
</nav>
<main>
<Outlet />
</main>
</div>
);
}
export default PostsLayout;
export async function loader() {
const response = await fetch('https://jsonplaceholder.typicode.com/posts');
if (!response.ok) {
throw new Error('Could not fetch posts');
}
return response;
}
Since layout routes are also regular routes, you can add loader() functions and useLoaderData() just as you could in any other route. But because layout routes are activated for multiple child routes, their data is also displayed for different routes. In the preceding example, the list of blog posts is always displayed on the left side of the screen, no matter if a user visits /posts or /posts/10:
Figure 13.3: The same layout and data are used for different child routes
In this screenshot, the layout and data used do not change as different child routes are activated. React Router also avoids unnecessary data refetching (for the blog posts list data) as you switch between child routes. It's smart enough to realize that the surrounding layout hasn't changed.
Reusing Data across Routes
Layouts do not just help you share data by sharing components that use data (such as the sidebar in the previous example). They also allow you to load data in a layout route and use it in a child route.
For example, the PostDetails component (that is, the component that's rendered for the /posts/:id route) needs the data for a single post, and that data can be retrieved via a loader attached to the /posts/:id route:
export async function loader({ params }) {
const response = await fetch(
'https://jsonplaceholder.typicode.com/posts/' + params.id
);
if (!response.ok) {
throw new Error('Could not fetch post for id ' + params.id);
}
return response;
}
This example was discussed earlier in this chapter in the Loading Data for Dynamic Routes section. This approach is fine, but in some situations, this extra HTTP request can be avoided.
In the example from the previous section, the PostsLayout route already fetched a list of all posts. That layout component is also active for the PostDetails route. In such a scenario, fetching a single post is unnecessary, since all the data has already been fetched for the list of posts. Of course, refetching would be required if the request for the list of posts didn't yield all the data required by PostDetails.
But if all the data is available, React Router allows you to tap into the loader data of a parent route component via the useRouteLoaderData() Hook.
This Hook can be used like this:
const posts = useRouteLoaderData('posts');
useRouteLoaderData() requires a route identifier as an argument. It requires an identifier assigned to the ancestor route that contains the data that should be reused. You can assign such an identifier via the id property to your routes as part of the route definitions code:
const router = createBrowserRouter([
{
path: '/',
element: <Root />, // main layout, adds navigation bar
children: [
{ index: true, element: <Welcome /> },
{
path: '/posts',
id: 'posts', // the id value is up to you
element: <PostsLayout />, // posts layout, adds posts sidebar
loader: postsLoader,
children: [
{ index: true, element: <Posts /> },
{ path: ':id', element: <PostDetails />, loader: postDetailLoader },
],
},
],
},
]);
The useRouteLoaderData() Hook then returns the same data useLoaderData() yields in that route to which you added the id. In this example, it would provide a list of blog posts.
In PostDetails, this list can be used like this:
import { useParams, useRouteLoaderData } from 'react-router-dom';
function PostDetails() {
const params = useParams();
const posts = useRouteLoaderData('posts');
const post = posts.find((post) => post.id.toString() === params.id);
return (
<main id="post-details">
<h1>{post.title}</h1>
<p>{post.body}</p>
</main>
);
}
export default PostDetails;
The useParams() Hook is used to get access to the dynamic route parameter value, and the find() method is used on the list of posts to identify a single post with a fitting id property. In this example, you would thus avoid sending an unnecessary HTTP request by reusing data that's already available.
Handling Errors
In the first example at the very beginning of this chapter (where the HTTP request was sent with help of useEffect()), the code did not just handle the success case but also possible errors. In all the React Router-based examples since then, error handling was omitted. Error handling was not discussed up to this point because while React Router plays an important role in error handling, it's vital to first gain a solid understanding of how React Router 6.4 works in general and how it helps with data fetching. But, of course, errors can't always be avoided and definitely should not be ignored.
Thankfully, handling errors is also very straightforward and easy when using React Router's data capabilities. You can set an errorElement property on your route definitions and define the element that should be rendered when an error occurs:
// ... other imports
import Error from './components/Error';
const router = createBrowserRouter([
{
path: '/',
element: <Root />,
errorElement: <Error />,
children: [
{ index: true, element: <Welcome /> },
{
path: '/posts',
id: 'posts',
element: <PostsLayout />,
loader: postsLoader,
children: [
{ index: true, element: <Posts /> },
{ path: ':id', element: <PostDetails /> },
],
},
],
},
]);
This errorElement property can be set on any route definition of your choice, or even multiple route definitions simultaneously. React Router will render the errorElement of the route closest to the place where the error was thrown.
In the preceding snippet, no matter which route produced an error, it would always be the root route's errorElement that was displayed (since that's the only route definition with an errorElement). But if you also added an errorElement to the /posts route, and the :id route produced an error, it would be the errorElement of the /posts route that was shown on the screen, as follows:
const router = createBrowserRouter([
{
path: '/',
element: <Root />,
errorElement: <Error />, // used for any errors not handled by nested routes
children: [
{ index: true, element: <Welcome /> },
{
path: '/posts',
id: 'posts',
element: <PostsLayout />,
// used if /posts or /posts/:id throws an error
errorElement: <PostsError />,
loader: postsLoader,
children: [
{ index: true, element: <Posts /> },
{ path: ':id', element: <PostDetails /> },
],
},
],
},
]);
This allows you, the developer, to set up fine-grained error handling.
Inside the component used as a value for the errorElement, you can get access to the error that was thrown via the useRouteError() Hook:
import { useRouteError } from 'react-router-dom';
function Error() {
const error = useRouteError();
return (
<>
<h1>Oh no!</h1>
<p>An error occurred</p>
<p>{error.message}</p>
</>
);
}
export default Error;
With this simple yet effective error-handling solution, React Router allows you to avoid managing error states yourself. Instead, you simply define a standard React element (via the element prop) that should be displayed when things go right and an errorElement to be displayed if things go wrong.
Onward to Data Submission
Thus far, you've learned a lot about data fetching. But as mentioned earlier in this chapter, React Router also helps with data submission.
Consider the following example component:
function NewPost() {
return (
<form id="post-form">
<p>
<label htmlFor="title">Title</label>
<input type="text" id="title" name="title" />
</p>
<p>
<label htmlFor="text">Text</label>
<textarea id="text" name="text" rows={3} />
</p>
<button>Save Post</button>
</form>
);
}
export default NewPost;
This component renders a <form> element that allows users to enter the details for a new post. Due to the following route configuration, the component is displayed whenever the /posts/new route becomes active:
const router = createBrowserRouter([
{
path: '/',
element: <Root />,
errorElement: <Error />,
children: [
{ index: true, element: <Welcome /> },
{
path: '/posts',
id: 'posts',
element: <PostsLayout />,
loader: postsLoader,
children: [
{ index: true, element: <Posts /> },
{ path: ':id', element: <PostDetails /> },
{ path: 'new', element: <NewPost /> },
],
},
],
},
]);
Without React Router's data-related features, you would typically handle form submission like this:
function NewPost() {
const titleInput = useRef();
const textInput = useRef();
const navigate = useNavigate();
async function submitHandler(event) {
event.preventDefault(); // prevent the browser from sending a HTTP request
const enteredTitle = titleInput.current.value;
const enteredText = textInput.current.value;
const postData = {
title: enteredTitle,
text: enteredText
};
await fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
body: JSON.stringify(postData),
headers: {'Content-Type': 'application/json'}
});
navigate('/posts');
}
return (
<form onSubmit={submitHandler}>
<p>
<label htmlFor="title">Title</label>
<input type="text" id="title" ref={titleInput} />
</p>
<p>
<label htmlFor="text">Text</label>
<textarea id="text" rows={3} ref={textInput} />
</p>
<button>Save Post</button>
</form>
);
}
Just as before when fetching data, this requires a lot of code and logic added to the component. You must manually handle the form submission, input data extraction, sending the HTTP request, and transitioning to a different page after sending the HTTP request. All these things happen inside the component. In addition, you might also need to manage loading state and potential errors (excluded in the preceding example).
Again, React Router offers some help. Where a loader() function can be added to handle data loading, an action() function can be defined to handle data submission.
When using the new action() function, the preceding example component looks like this:
import { Form, redirect } from 'react-router-dom';
function NewPost() {
return (
<Form method="post" id="post-form">
<p>
<label htmlFor="title">Title</label>
<input type="text" id="title" name="title" />
</p>
<p>
<label htmlFor="text">Text</label>
<textarea id="text" rows={3} name="text" />
</p>
<button>Save Post</button>
</Form>
);
}
export default NewPost;
export async function action({ request }) {
const formData = await request.formData();
const postData = Object.fromEntries(formData);
await fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
body: JSON.stringify(postData),
headers: { 'Content-Type': 'application/json' },
});
return redirect('/posts');
}
This code is shorter and, most importantly, simpler (even though it might not look simpler yet, since it includes a couple of new features).
Besides the addition of the action() function, the example code snippet includes the following important changes and features:
- A <Form> component that's used instead of <form>.
- The method prop is set on the <Form> (to "post"), and the onSubmit event handler was removed.
- The form input elements have names assigned to them (via the name prop), and the refs were removed.
- In the action, the entered data is extracted via a formData() method (combined with Object.fromEntries()).
- The user is redirected via a newly added redirect() function (instead of useNavigate() and navigate()).
But what are these elements about?
Working with action() and Form Data
Just like loader(), action() is a special function that can be added to route definitions, as follows:
import NewPost, { action as newPostAction } from './components/NewPost';
// ...
{ path: 'new', element: <NewPost />, action: newPostAction },
With the action prop set on a route definition, the assigned function is automatically called whenever a <Form> targeting this route is submitted. Form is a component provided by React Router that should be used instead of the default <form> element.
Internally, Form uses the default <form> element but prevents the browser default of creating and sending an HTTP request upon form submission. Instead, React Router creates a FormData object and calls the action() function defined for the route that's targeted by the <Form>, passing a request object, based on the built-in Request interface, to it. The passed request object contains the form data generated by React Router.
Note
For further reading on React Router's FormData object, visit https://developer.mozilla.org/en-US/docs/Web/API/FormData.
The form data object that is created by React Router includes all form input values entered into the submitted form. To be registered, an input element such as <input>, <select>, or <textarea> must have the name attribute assigned to it. The values set for those name attributes can later be used to extract the entered data.
The Form component also sets the HTTP method of the request object to the value assigned to the method prop. It's important to understand that the request is not sent via HTTP since action(), just like loader() or the component function, still executes in the browser rather than the server. React Router simply uses this request object as a "data vehicle" for passing information (such as the form data or chosen method) to the action() function.
The action() function then receives an object with a request property that contains the created request object with the included form data:
export function action({ request }) {
// do something with 'request' (e.g., extract data)
}
The method property could be used inside the action() function to perform different actions for different forms. For example, one form could generate and pass a POST request via <Form method="post">, whereas another form might yield a DELETE request via <Form method="delete">. The same action could handle both form submissions and perform different tasks based on the value of the method property:
export function action({ request }) {
if (request.method === 'DELETE') {
// do something, e.g., send a "delete post" request to backend API
}
if (request.method === 'POST') {
// do something, e.g., send a "create new post" request to backend API
}
}
But while using the method for performing different tasks for different forms can be very useful, the form data that's attached to the request object is often even more important. The request object can be used to extract the values entered into the form input fields like this:
export async function action({ request }) {
const formData = await request.formData();
const postData = Object.fromEntries(formData);
// ...
}
The built-in formData() method yields a Promise that resolves to an object that offers a get() method that could be used to get an entered value by its identifier (that is, by the name attribute value set on the input element). For example, the value entered into <input name="title"> could be retrieved via formData.get('title').
Alternatively, you can follow the approach chosen in the preceding code snippet and convert the formData object to a simple key-value object via Object.fromEntries(formData). This object (postData, in the preceding example) contains the names set on the form input elements as properties and the entered values as values for those properties (meaning that postData.title would yield the value entered in <input name="title">).
The extracted data can then be used for any operations of your choice. That could be an extra validation step or an HTTP request sent to some backend API, where the data may get stored in a database or file:
export async function action({ request }) {
const formData = await request.formData();
const postData = Object.fromEntries(formData);
await fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
body: JSON.stringify(postData),
headers: { 'Content-Type': 'application/json' },
});
return redirect('/posts');
}
Finally, once all intended steps were performed, the action() function should return a value—any value of any type. Though, as with the loader() function, you may also return a response.
Indeed, for actions, it's highly likely that you will want to navigate to a different page once the action has been performed (that is, once the HTTP request to an API has been sent). This may be required to navigate the user away from the data input page to a page that displays all available data entries (for example, from /posts/new to /posts).
To simplify this common pattern, React Router provides a redirect() function that yields a response object that causes React Router to switch to a different route. You can therefore return the result of calling redirect() in your action() function to ensure that the user is navigated to a different page. It's the equivalent of calling navigate() (via useNavigate()) when manually handling form submissions.
Returning Data Instead of Redirecting
As mentioned, your action() functions may return anything. You don't have to return a response object. And while it is quite common to return a redirect response, you may occasionally want to return some raw data instead.
One scenario in which you might not want to redirect the user is after validating the user's input. Inside the action() function, before sending the entered data to some API, you may wish to validate the provided values first. If an invalid value (such as an empty title) is detected, a great user experience is typically achieved by keeping the user on the route with the <Form>. The values entered by the user shouldn't be cleared and lost; instead, the form should be updated to present useful validation error information to the user. This information can be passed from the action() to the component function so that it can be displayed there (for example, next to the form input fields).
In situations like this, you can return a "normal" value (that is, not a redirect response) from your action() function:
export async function action({ request }) {
const formData = await request.formData();
const postData = Object.fromEntries(formData);
let validationErrors = [];
if (postData.title.trim().length === 0) {
validationErrors.push('Invalid post title provided.')
}
if (postData.text.trim().length === 0) {
validationErrors.push('Invalid post text provided.')
}
if (validationErrors.length > 0) {
return validationErrors;
}
await fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
body: JSON.stringify(postData),
headers: { 'Content-Type': 'application/json' },
});
return redirect('/posts');
}
In this example, a validationErrors array is returned if the entered title or text values are empty.
Data returned by an action() function can be used in the route component (or any other nested component) via the useActionData() Hook:
import { Form, redirect, useActionData } from 'react-router-dom';
function NewPost() {
const validationErrors = useActionData();
return (
<Form method="post" id="post-form">
<p>
<label htmlFor="title">Title</label>
<input type="text" id="title" name="title" />
</p>
<p>
<label htmlFor="text">Text</label>
<textarea id="text" name="text" rows={3} />
</p>
<ul>
{validationErrors &&
validationErrors.map((err) => <li key={err}>{err}</li>)}
</ul>
<button>Save Post</button>
</Form>
);
}
useActionData() works a lot like useLoaderData(), but unlike useLoaderData(), it's not guaranteed to yield any data. This is because while loader() functions always get called before the route component is rendered, the action() function only gets called once the <Form> is submitted.
In this example, useActionData() is used to get access to the validationErrors returned by action(). If validationErrors is truthy (that is, is not undefined), the array will be mapped to a list of error items that are displayed to the user:
Figure 13.4: Validation errors are output below the input fields
The action() function is therefore quite versatile in that you can use it to perform an action and redirect away as well as to conduct more than one operation and return different values for different use cases.
Controlling Which <Form> Triggers Which Action
In Chapter 12, Multipage Apps with React Router, you learned that when <Form> is used instead of <form>, React Router will execute the targeted action() function. But which action() function is targeted by <Form>?
By default, it's the action() function assigned to the route that also renders the form. Consider this route definition:
{ path: '/posts/new', element: <NewPost />, action: newPostAction }
With this definition, the newPostAction() function would be triggered whenever any <Form> inside of the NewPost component (or any nested component) is submitted.
In many cases, this default behavior is exactly what you want. But you can also target action() functions defined on other routes, and these can be triggered by setting the action prop on <Form> to the path of the route that contains the action() that should be executed:
// form rendered in a component that belongs to /posts
<Form method="post" action="/save-data">
...
</Form>
This form would lead to the action belonging to the /save-data route to be executed—even though the <Form> component is rendered as part of a component that belongs to a different route (e.g., /posts).
It is worth noting, though, that targeting a different route will lead to a page transition to that route's path, even if your action does not return a redirect response. In a later section of this chapter, entitled "Behind-the-Scenes Data Fetching and Submission", you will learn how that behavior could be avoided.
Reflecting the Current Navigation Status
After submitting a form, the action() function that's triggered may need some time to perform all intended operations. Sending HTTP requests to APIs in particular can take up to a few seconds.
Of course, it's not a great user experience if the user doesn't get any feedback about the current data submission status. It's not immediately clear if anything happened at all after the submit button was clicked.
For that reason, you might want to show a loading spinner or update the button caption while the action() function is running. Indeed, one common way of providing user feedback is to disable the submit button and change its caption like this:
Figure 13.5: The submit button is grayed out
You can get the current React Router status (that is, whether it's currently transitioning to another route or executing an action() function) via the useNavigation() Hook. This Hook provides a navigation object that contains various pieces of routing-related information.
Most importantly, this object has a state property that yields a string describing the current navigation status. This property is set to one of the following three possible values:
- submitting: If an action() function is currently executing
- loading: If a loader() function is currently executing (for example, because of a redirect() response)
- idle: If no action() or loader() functions are currently being executed
You can therefore use this state property to find out whether React Router is currently navigating to a different page or executing an action(). Hence, the submit button can be updated as shown in the preceding screenshot via this code:
import { Form, redirect, useActionData, useNavigation } from 'react-router-dom';
function NewPost() {
const validationErrors = useActionData();
const navigation = useNavigation();
const isSubmitting = navigation.state !== 'idle';
return (
<Form method="post" id="post-form">
<p>
<label htmlFor="title">Title</label>
<input type="text" id="title" name="title" />
</p>
<p>
<label htmlFor="text">Text</label>
<textarea id="text" name="text" rows={3} />
</p>
<ul>
{validationErrors &&
validationErrors.map((err) => <li key={err}>{err}</li>)}
</ul>
<button disabled={isSubmitting}>
{isSubmitting ? 'Saving...' : 'Save Post'}
</button>
</Form>
);
}
In this example, the isSubmitting constant is true if the current navigation state is anything but 'idle'. This constant is then used to disable the submit button (via the disabled attribute) and adjust the button's caption.
Submitting Forms Programmatically
In some cases, you won't want to instantly trigger an action() when a form is submitted—for example, if you need to ask the user for confirmation first such as when triggering actions that delete or update data.
For such scenarios, React Router allows you to submit a form (and therefore trigger an action() function) programmatically. Instead of using the Form component provided by React Router, you handle the form submission manually using the default <form> element. As part of your code, you can then use a submit() function provided by React Router's useSubmit() Hook to trigger the action() manually once you're ready for it.
Consider this example:
import {
redirect,
useParams,
useRouteLoaderData,
useSubmit,
} from 'react-router-dom';
function PostDetails() {
const params = useParams();
const posts = useRouteLoaderData('posts');
const post = posts.find((post) => post.id.toString() === params.id);
const submit = useSubmit();
function submitHandler(event) {
event.preventDefault();
const proceed = window.confirm('Are you sure?');
if (proceed) {
submit(
{ message: 'Your data, if needed' },
{
method: 'delete',
}
);
}
}
return (
<main id="post-details">
<h1>{post.title}</h1>
<p>{post.body}</p>
<form onSubmit={submitHandler}>
<button>Delete</button>
</form>
</main>
);
}
export default PostDetails;
// action must be added to route definition!
export async function action({ request }) {
const formData = await request.formData();
console.log(formData.get('message'));
console.log(request.method);
return redirect('/posts');
}
In this example, the action() is manually triggered by programmatically submitting data via the submit() function provided by useSubmit(). This approach is required as it would otherwise be impossible to ask the user for confirmation (via the browser's window.confirm() method).
Because data is submitted programmatically, the default <form> element should be used and the submit event handled manually. As part of this process, the browser's default behavior of sending an HTTP request must also be prevented manually.
Typically, using <Form> instead of programmatic submission is preferable. But in certain situations, such as the preceding example, being able to control form submission manually can be useful.
Behind-the-Scenes Data Fetching and Submission
There also are situations in which you may need to trigger an action or load data without causing a page transition.
A "Like" button would be an example. When it's clicked, a process should be triggered in the background (such as storing information about the user and the liked post), but the user should not be directed to a different page:
Figure 13.6: A like button below a post
To achieve this behavior, you could wrap the button into a <Form> and, at the end of the action() function, simply redirect back to the page that is already active.
But technically, this would still lead to an extra navigation action. Therefore, loader() functions would be executed and other possible side-effects might occur (the current scroll position could be lost, for example). For that reason, you might want to avoid this kind of behavior.
Thankfully, React Router offers a solution: the useFetcher() Hook, which yields an object that contains a submit() method. Unlike the submit() function provided by useSubmit(), the submit() method yielded by useFetcher() is meant for triggering actions (or loader() functions) without starting a page transition.
A "Like" button, as described previously, can be implemented like this (with help of useFetcher()):
import {
// ... other imports
useFetcher,
} from 'react-router-dom';
import { FaHeart } from 'react-icons/fa';
function PostDetails() {
// ... other code & logic
const fetcher = useFetcher();
function likePostHandler() {
fetcher.submit(null, {
method: 'post',
action: `/posts/${post.id}/like`, // targeting an action on another route
});
}
return (
<main id="post-details">
<h1>{post.title}</h1>
<p>{post.body}</p>
<p>
<button className="icon-btn" onClick={likePostHandler}>
<FaHeart />
<span>Like this post</span>
</button>
</p>
<form onSubmit={submitHandler}>
<button>Delete</button>
</form>
</main>
);
}
The fetcher object returned by useFetcher() has various properties. For example, it also contains properties that provide information about the current status of the triggered action or loader (including any data that may have been returned).
But this object also includes two important methods:
- load(): To trigger the loader() function of a route (e.g., fetcher.load('/route-path'))
- submit(): To trigger an action() function with the provided data and configuration
In the code snippet above, the submit() method is called to trigger the action defined on the /posts/<post-id>/like route. Without useFetcher() (i.e., when using useSubmit() or <Form>), React Router would switch to the selected route path when triggering its action. With useFetcher(), this is avoided, and the action of that route can be called from inside another route (meaning the action defined for /posts/<post-id>/like is called while the /posts/<post-id> route is active).
This also allows you to define routes that don't render any element (that is, in which there is no page component) and instead only contain a loader() or action() function. For example, the /posts/<post-id>/like route file looks like this:
export function action({ params }) {
console.log('Triggered like action.');
console.log(`Liking post with id ${params.id}.`);
// Do anything else
// May return data or response, including redirect() if needed
}
It's registered as a route as follows:
import { action as likeAction } from './pages/like';
// ...
{ path: ':id/like', action: likeAction },
This works because this action() is only triggered via the submit() method provided by useFetcher(). <Form> and the submit() function yielded by useSubmit() would instead initiate a route transition to /posts/<post-id>/like. Without the element property being set on the route definition, this transition would lead to an empty page, as shown here:
Figure 13.7: An empty (nested) page is displayed, along with a warning message
Because of the extra flexibility it offers, useFetcher() can be very useful when building highly interactive user interfaces. It's not meant as a replacement for useSubmit() or <Form> but rather as an additional tool for situations where no route transition is required or wanted.
Deferring Data Loading
Up to this point in the chapter, all data-fetching examples have assumed that a page should only be displayed once all its data has been fetched. That's why there was never any loading state that would have been managed (and hence no loading spinner that would have been displayed).
In many situations, this is exactly the behavior you want as it does not often make sense to show a loading spinner for a fraction of a second just to then replace it with the actual page data.
But there are also situations in which the opposite behavior might be desirable—for example, if you know that a certain page will take quite a while to load its data (possibly due to a complex database query that must be executed on the backend) or if you have a page that loads different pieces of data and some pieces are much slower than others.
In such scenarios, it may make sense to render the page component even though some data is still missing. React Router also supports this use case by allowing you to defer data loading, which in turn enables the page component to be rendered before the data is available.
Deferring data loading is as simple as using the defer() function provided by React Router like this:
import { defer } from 'react-router-dom';
// ... other imports
export async function loader() {
return defer({
posts: getPosts(),
});
}
In this example, getPosts() is a function that returns a (slow) Promise:
async function getPosts() {
const response = await fetch('https://jsonplaceholder.typicode.com/posts');
await wait(3); // utility function, simulating a slow response
if (!response.ok) {
throw new Error('Could not fetch posts');
}
const data = await response.json();
return data;
}
React Router's defer() function takes an object as an argument. This object contains one key-value pair for every data fetching operation that's part of the loader() function. The values in this object are of type Promise; otherwise, there wouldn't be anything to defer.
Inside the component function where useLoaderData() is used, you must also use a new component provided by React Router: the Await component. It's used like this:
import { Suspense } from 'react';
import { Await } from 'react-router-dom';
// ... other imports
function PostsLayout() {
const data = useLoaderData();
return (
<div id="posts-layout">
<nav>
<Suspense fallback={<p>Loading posts...</p>}>
<Await resolve={data.posts}>
{(loadedPosts) => <PostsList posts={loadedPosts} />}
</Await>
</Suspense>
</nav>
<main>
<Outlet />
</main>
</div>
);
}
The <Await> element takes a resolve prop that receives a value from the loader data. It's wrapped by the < Suspense> component provided by React.
The value passed to resolve is a Promise. It's one of the values stored in the object that was passed to defer(). For that reason, you use the key names defined in the object that was passed to defer() to access the data in the component function (meaning that data.posts is used because of defer({posts: getPosts()})).
Await automatically waits for the Promise to resolve before then calling the function that's passed to <Await> as a child (that is, the function passed between the <Await> opening and closing tags). This function is executed by React Router once the data of the deferred operation is available. Therefore, inside that function, loadedPosts is received as a parameter, and the final user interface elements can be rendered.
The Suspense component that's used as a wrapper around <Await> defines some fallback content that is rendered as long as the deferred data is not yet available. In the "Lazy Loading" section of the previous chapter, the Suspense component was used to show some fallback content until the missing code was downloaded. Now, it's used to bridge the time until the required data is available.
When using defer() (and <Await>) like this, you would still load other parts of the website while waiting for the posts data:
Figure 13.8: Post details are already visible while the list of posts is loading
Another big advantage of defer() is that you can easily combine multiple fetching processes and control which processes should be deferred and which ones should not. For example, a route might be fetching different pieces of data. If only one process tends to be slow, you could defer only the slow one like this:
export async function loader() {
return defer(
{
posts: getPosts(), // slow operation => deferred
userData: await getUserData() // fast operation => NOT deferred
}
);
}
In this example, getUserData() is not deferred because the await keyword is added in front of it. Therefore, JavaScript waits for that Promise (the Promise returned by getUserData()) to resolve before returning from loader(). Hence, the route component is rendered once getUserData() finishes but before getPosts() is done.
Summary and Key Takeaways
- React Router can help you with data fetching and submission.
- You can register loader() functions for your routes, causing data fetching to be initialized as a route becomes active.
- loader() functions return data (or responses, wrapping data) that can be accessed via useLoaderData() in your component functions.
- loader() data can be used across components via useRouteLoaderData().
- You can also register action() functions on your routes that are triggered upon form submissions.
- To trigger action() functions, you must use React Router's <Form> component or submit data programmatically via useSubmit() or useFetcher().
- useFetcher() can be used to load or submit data without initiating a route transition.
- When fetching slow data, you can use defer() to defer loading some or all of a route's data.
What's Next?
Fetching and submitting data are extremely common tasks, especially when building more complex React applications.
Typically, those tasks are closely connected to route transitions, and React Router is the perfect tool for handling this kind of operation. With the release of version 6.4, the React Router package offers powerful data management capabilities that vastly simplify these processes.
In this chapter, you learned how React Router assists you with fetching or submitting data and which advanced features help you handle both basic and more complex data manipulation scenarios.
This chapter also concludes the list of core React features you must know as a React developer. Of course, you can always dive deeper to explore more patterns and third-party libraries. The next (and last) chapter will share some resources and possible next steps you could dive into after finishing this book.
Test Your Knowledge!
Test your knowledge of the concepts covered in this chapter by answering the following questions. You can then compare your answers to the examples found at https://packt.link/cbDjn:
- How are data fetching and submission related to routing?
- What is the purpose of loader() functions?
- What is the purpose of action() functions?
- What is the difference between <Form> and <form>?
- What is the difference between useSubmit() and useFetcher()?
- What is the idea behind defer()?
Apply What You Learned
Apply your knowledge about routing, combined with data manipulation, to the following activity.
Activity 13.1: A To-Dos App
In this activity, your task is to create a basic to-do list web app that allows users to manage their daily to-do tasks. The finished page must allow users to add to-do items, update to-do items, delete to-do items and view a list of to-do items.
The following paths must be supported:
- /: The main page, responsible for loading and displaying a list of to-do items
- /new: A page, opened as a modal above the main page, allowing users to add a new to-do item
- /:id: A page, also opened as a modal above the main page, allowing users to update or delete a selected to-do item
If no to-do items exist yet, a fitting info message should be shown on the / page. If users try to visit /:id with an invalid to-do ID, an error modal should be displayed.
Note
For this activity, there is no backend API you could use. Instead, use localStorage to manage the to-dos data. Keep in mind that the loader() and action() functions are executed on the client side and can therefore use any browser APIs, including localStorage.
You will find example implementations for adding, updating, deleting, and getting to-do items from localStorage at https://packt.link/XCbu0.
Also, don't be confused by the pages that open as modals above other pages. Ultimately, these are simply nested pages, styled as modal overlays. In case you get stuck, you can use the example Modal wrapper component found at https://packt.link/qPIvp.
For this activity, you can write all CSS styles on your own if you so choose. But if you want to focus on the React and JavaScript logic, you can also use the finished CSS file from the solution at https://packt.link/G0IKW.
If you use that file, explore it carefully to ensure you understand which IDs or CSS classes might need to be added to certain JSX elements of your solution.
To complete the activity, perform the following steps:
- Create a new React project and install the React Router package (make sure it's version 6.4 or later).
- Create components (with the content shown in the preceding screenshots) that will be loaded for the three required pages. Also add links (or programmatic navigation) between these pages.
- Enable routing and add the route definitions for the three pages.
- Create loader() functions to load (and use) all the data needed by the individual pages.
- Add action() functions for adding, updating, and deleting to-dos.
- Add error handling in case data loading or saving fails.
The finished pages should look like this:
Figure 13.9: The main page displaying a list of to-dos
Figure 13.10: The /new page, opened as a modal, allowing users to add a new to-do
Figure 13.11: The /:id page, also opened as a modal, allowing users to edit or delete a to-do
Figure 13.12: An info message, displayed if no to-dos were found
Note
The solution to this activity can be found via this link.
';
';
';
';
';
';
