Chapter 4: Getting Started with Hooks
One of the most anticipated new features of React is Hooks, an API that allows your functional components to "hook" into React functionality. The overarching motivation for this feature is to simplify your components. For example, forcing React developers to use classes to define their components leads to the overuse of wrapper components to pass state around their apps. With Hooks, you can stick with simple functions to implement your components and have a clear picture of how everything fits together.
In this chapter, we'll cover the following topics:
- Maintaining state using Hooks
- Performing initialization and cleanup actions
- Sharing data using context Hooks
- Using reducer Hooks to scale state management
Technical requirements
The code present in this chapter can be found at https://github.com/PacktPublishing/React-and-React-Native-4th-Edition/tree/main/Chapter04.
Maintaining state using Hooks
The first React Hook API that we'll look at is called useState(), which enables your functional React components to be stateful. Before Hooks were introduced to React, our only option for creating stateful components was to use a class so that we could access the setState() method. In this section, you'll learn how to initialize state values and change the state of a component using Hooks.
Initial state values
When our components are first rendered, they probably expect some state values to be set. This is called the initial state of the component, and we can use the useState() Hook to set the initial state. Let's take a look at an example:
import * as React from "react";
export default function App() {
const [name] = React.useState("Adam");
const [age] = React.useState(35);
return (
<>
<p>My name is {name}</p>
<p>My age is {age}</p>
</>
);
}
The App component is a functional React component, a function that returns JSX markup. But it's also now a stateful component, thanks to the useState() Hook. This example initializes two pieces of state, name and age. This is why there are two calls to useState(), one for each state value.
You can have as many pieces of state in your component as you need. The best practice is to have one call to useState() per state value. You could always define an object as the state of your component using only one call to useState(), but this complicates things because you have to access state values through an object instead of directly. Updating state values is also more complicated using this approach. When in doubt, use one useState() Hook per state value.
When we call useState(), we get an array returned to us. The first value of this array is the state value itself. Since we've used array-destructuring syntax here, we can call the value whatever we want; in this case, it is name and age. Both of these constants have values when the component is first rendered because we passed the initial state values for each of them to useState(). Here's what the page looks like when it's rendered:
Figure 4.1 – Rendered output using values from state Hooks
Now that you've seen how to set the initial state values of your components, let's learn about updating these values.
Updating state values
React components use state for values that change over time. The state values used by components start off in one state, as we saw in the previous section, and then change in response to some event – for example, the server responds to an API request with new data, or the user has clicked a button or changed a form field.
With functional components that use the useState() Hook, state values are updated differently to class components that rely on the setState() method. Instead of using setState() to update every piece of component state, you have individual functions to set each state value. The useState() Hook returns an array. The first item is the state value and the second is the function used to update the value. Let's take a look at an example:
import * as React from "react";
function App() {
const [name, setName] = React.useState("Adam");
const [age, setAge] = React.useState(35);
return (
<>
<section>
<input
value={name}
onChange={(e) => setName(e.target.value)}
/>
<p>My name is {name}</p>
</section>
<section>
<input
type="number"
value={age}
onChange={(e) => setAge(e.target.value)}
/>
<p>My age is {age}</p>
</section>
</>
);
}
export default App;
Just like the example from the Initial state values section, the App component in this example has two pieces of state – name and age. Unlike the previous example, this component uses two functions to update each piece of state. These are returned from the call to useState(). Let's take a closer look:
const [name, setName] = React.useState("Adam");
const [age, setAge] = React.useState(35);
Now, we have two functions – setName() and setAge() – that can be used to update the state of our component. Let's take a look at the text input field that updates the name state:
<section>
<input
value={name}
onChange={(e) => setName(e.target.value)}
/>
<p>My name is {name}</p>
</section>
Whenever the user changes the text in the <input> field, the onChange event is triggered. The handler for this event calls setName(), passing it e.target.value as an argument. The argument passed to setName() is the new state value of name. The succeeding paragraph shows that the text input is also updated with the new name value every time the user changes the text input.
Next, let's look at the age number input field and how this value is passed to setAge():
<section>
<input
type="number"
value={age}
onChange={(e) => setAge(e.target.value)}
/>
<p>My age is {age}</p>
</section>
The age field follows the exact same pattern as the name field. The only difference is that we've made the input a number type. Any time the number changes, setAge() is called with the updated value in response to the onChange event. The following paragraph shows that the number input is also updated with every change that is made to the age state.
Here is what the two inputs and their two corresponding paragraphs look like when they're rendered on the screen:
Figure 4.2 – Using Hooks to change state values
In this section, you learned about the useState() Hook, which is used to add state to functional React components. Each piece of state uses its own Hook and has its own value variable and its own setter function. This greatly simplifies accessing and updating state in your components. Any given state value should have an initial value so that the component can render correctly the first time. To re-render functional components that use state Hooks, you can use the setter functions that useState() returns to update your state values as needed.
The next Hook that you'll learn about is used to perform initialization and cleanup actions.
Performing initialization and cleanup actions
Often, our React components need to perform actions when the component is created. For example, a common initialization action is to fetch API data that the component needs. Another common action is to make sure that any pending API requests are canceled when the component is removed. In this section, you'll learn about the useEffect() Hook and how it can help you with these two scenarios. You'll also learn how to make sure that the initialization code doesn't run too often.
Fetching component data
The useEffect() Hook is used to run "side-effects" in your component. Another way to think about side-effect code is that functional components have only one job – returning JSX content to render. If the component needs to do something else, such as fetching API data, this should be done in a useEffect() Hook. For example, if you were to just make the API call as part of your component function, you would likely introduce race conditions and other difficult-to-fix buggy behavior.
Let's take a look at an example that fetches API data using Hooks:
import * as React from "react";
function fetchUser() {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: 1, name: "Adam" });
}, 1000);
});
}
function App() {
const [id, setId] = React.useState("loading...");
const [name, setName] = React.useState("loading...");
React.useEffect(() => {
fetchUser().then((user) => {
setId(user.id);
setName(user.name);
});
});
return (
<>
<p>ID: {id}</p>
<p>Name: {name}</p>
</>
);
}
export default App;
The useEffect() Hook expects a function as an argument. This function is called after the component finishes rendering, in a safe way that doesn't interfere with anything else that React is doing with the component under the covers. Let's look at the pieces of this example more closely, starting with the mock API function:
function fetchUser() {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: 1, name: "Adam" });
}, 1000);
});
}
The fetchUser() function returns a promise. The promise resolves a simple object with two properties, id and name. The setTimeout() function delays the promise resolution for 1 second, so this function is asynchronous, just as a normal fetch() call would be.
Next, let's look at the Hooks used by the App component:
const [id, setId] = React.useState("loading...");
const [name, setName] = React.useState("loading...");
React.useEffect(() => {
fetchUser().then((user) => {
setId(user.id);
setName(user.name);
});
});
As you can see, we're using two Hooks in this component – useState() and useEffect(). Combining Hook functionality like this is powerful and encouraged. First, we set up the id and name states of the component. Then, useEffect() is used to set up a function that calls fetchUser() and sets the state of our component when the promise resolves.
Here is what the App component looks like when it's first rendered, using the initial state of id and name:
Figure 4.3 – Displaying the loading text until the data arrives
After 1 second, the promise returned from fetchUser() is resolved with data from the API, which is then used to update the ID and name states. This results in App being rerendered:
Figure 4.4 – The state changes, removing the loading text and displaying returned values
There is a good chance that your users will navigate around your application while an API request is still pending. The useEffect() Hook can be used to deal with canceling these requests.
Canceling requests and resetting state
There's a good chance that, at some point, your users will navigate your app and cause components to unmount before responses to their API requests arrive. When this happens, an error occurs because the component will attempt to update the state values of a component that has been removed.
Thankfully, the useEffect() Hook has a mechanism to clean up things such as pending API requests when the component is removed. Let's take a look at an example of this in action:
import * as React from "react";
import { Promise } from "bluebird";
Promise.config({ cancellation: true });
function fetchUser() {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: 1, name: "Adam" });
}, 1000);
});
}
function User() {
const [id, setId] = React.useState("loading...");
const [name, setName] = React.useState("loading...");
React.useEffect(() => {
const promise = fetchUser().then((user) => {
setId(user.id);
setName(user.name);
});
return () => {
promise.cancel();
};
});
return (
<>
<p>ID: {id}</p>
<p>Name: {name}</p>
</>
);
}
export default User;
This looks a lot like the component from the fetching component data example. It has the same state, it fetches data inside useEffect(), and it renders the same output. There are a couple of important differences though. Let's start by taking a closer look at the useEffect() Hook:
useEffect(() => {
const promise = fetchUser().then((user) => {
setId(user.id);
setName(user.name);
});
return () => {
promise.cancel();
};
});
Just like in the fetching component data example, this effect creates a promise by calling the fetchUser() API function. It also returns a function, which React runs when the component is removed. In this example, the promise that is created by calling fetchUser() is canceled by calling promise.cancel(). This prevents the component from trying to update its state after it has been removed.
Another important difference compared with the preceding example is that here, we're using the Bluebird library for promises since they support cancellation. There are many other ways that you can "cancel" asynchronous operations in the function returned by the useEffect() Hook, but I found Bluebird to be well worth the added dependency for this added capability.
Now, let's look at the App component, which renders and removes the User component:
import * as React from "react";
import User from "./User";
const ShowHideUser = ({ show }) => (show ? <User /> :
null);
function App() {
const [show, setShow] = React.useState(false);
return (
<>
<button onClick={() => setShow(!show)}>
{show ? "Hide User" : "Show User"}
</button>
<ShowHideUser show={show} />
</>
);
}
export default App;
The App component renders a button that is used to toggle the show state. This state value determines whether or not the User component is rendered but by using the ShowHideUser convenience component. If show is true, <User> is rendered; otherwise, User is removed, triggering our useEffect() cleanup behavior.
Here's what the screen looks like when it first loads:
Figure 4.5 – A button used to initiate the state change
The User component isn't rendered because the show state of the App component is false. Try clicking on the show user button. This will change the show state and render the User component:
Figure 4.6 – Displays the loading text when first clicked
The loading... strings are the two initial state values for the id and name states. These will be updated when the API promise resolves after 1 second:
Figure 4.7 – The loading strings are eventually replaced with new state data
You can click on the Hide User button once more to remove the User component. Now, click on the Show User button, and then click on Hide User before it finishes loading. Without the cleanup code that we added to useEffect(), this will trigger an error. In fact, you can test this by commenting out the call to promise.cancel().
Effects are run by React after every render. This might not be what you want, especially if your effect is something that is relatively slow, such as an asynchronous network request. Instead, we want to call the API after the first render, and that's it. We'll take a look at how to do this next.
Optimizing side-effect actions
By default, React assumes that every effect that is run needs to be cleaned up. This typically isn't the case. For example, you might have specific property or state values that require cleanup when they change. You can pass an array of values to watch as the second argument to useEffect() – for example, if you have a resolved state that requires cleanup when it changes, you would write your effect code like this:
const [resolved, setResolved] = useState(false);
useEffect(() => {
// ...the effect code...
return () => {
// ...the cleanup code that depends on "resolved"
}
}, [resolved]);
In this code, the cleanup function will only ever run if the resolved state value changes. If the effect runs and the resolved state hasn't changed, then the cleanup code will not run. Another common case is to never run the cleanup code, except for when the component is removed. In fact, this is what we want to happen in the example from the previous section. Right now, the cleanup code runs after every render. This means that we're repeatedly fetching the user API data when all we really want is to fetch it once when the component is first mounted.
Let's make some modifications to the User component from the canceling requests example:
import * as React from "react";
import { Promise } from "bluebird";
Promise.config({ cancellation: true });
function fetchUser() {
console.count("fetching user");
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: 1, name: "Adam" });
}, 1000);
});
}
function User() {
const [id, setId] = React.useState("loading...");
const [name, setName] = React.useState("loading...");
React.useEffect(() => {
const promise = fetchUser().then((user) => {
setId(user.id);
setName(user.name);
});
return () => {
promise.cancel();
};
}, []);
return (
<>
<p>ID: {id}</p>
<p>Name: {name}</p>
</>
);
}
export default User;
We've added a second argument to useEffect(), an empty array. This tells React that there are no values to watch and that we only want to run the cleanup code when the component is removed. We've also added console.count('fetching user') to the fetchUser() function. This makes it easier to look at the browser dev tools console and make sure that our component data is only fetched once. If you remove the [] argument that is passed to useEffect(), you'll notice that fetchUser() is called several times.
In this section, you learned about side effects in React components. Effects are an important concept, as they are the bridge between your React components and the outside world. One of the most common use cases for effects is to fetch data that the component needs, when it is first created, and then clean up after the component when it is removed.
Now, we're going to look at another way to share data with React components – context.
Sharing data using context Hooks
React applications often have a few pieces of data that are global in nature. This means that several components, possibly every component in an app, share this data – for example, information about the currently logged-in user might be used in several places. In cases like this, it makes sense to provide a context where this data can be easily accessed by components that are rendered in this context.
In this section, you'll learn how to consume context data using Hooks.
Sharing fetched data
Most of our components will directly fetch data that they and their children need. In other cases, our app has some API endpoint with data that is used by several components throughout the application. To share global data like this, you can use the React context API. As the name suggests, components that are rendered within a context are able to access the data provided by the context.
Let's build an example to help clarify what this means and how it relates to Hooks. Here is the UserContext context and the UserProvider component:
import * as React from "react";
export const UserContext = React.createContext();
function fetchUser() {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: 1, name: "Adam" });
}, 1000);
});
}
export function UserProvider({ children }) {
const [user, setUser] = React.useState({ name: "..." });
React.useEffect(() => {
fetchUser().then((user) => {
setUser(user);
});
}, []);
return (
<UserContext.Provider value={user}>
{children}
</UserContext.Provider>
);
}
First, we have the UserContext object, created by calling the createContext() React API. Next, we have the mock API function, fetchUser(). Finally, we have the UserProvider component. The job of this component is to call the fetchUser() API and set the user state as the response from the API when it arrives. To do this, we're using the useState() and useEffect() Hooks.
This component renders the <UserContext.Provider> component, passing in any children it receives. The value property is then made available to any child components of UserProvider. In this case, the value is the state that is set by calling the fetchUser() API. We've set ourselves up to be able to pass the user value to any component of our application. Let's see how this is done by creating a simple App component with three pages on it:
import * as React from "react";
import { UserProvider } from "./UserContext";
import { Page1, Page2, Page3 } from "./Pages";
function ChoosePage({ page }) {
const Page = [Page1, Page2, Page3][page];
return <Page />;
}
function App() {
const [page, setPage] = React.useState(0);
return (
<UserProvider>
<button onClick={() => setPage(0)} disabled=
{page === 0}>
Page 1
</button>
<button onClick={() => setPage(1)} disabled=
{page === 1}>
Page 2
</button>
<button onClick={() => setPage(2)} disabled=
{page === 2}>
Page 3
</button>
<ChoosePage page={page} />
</UserProvider>
);
}
export default App;
The App component renders three buttons that, when clicked, render their corresponding page component. The page state is used to control the page that is displayed and defaults to 0. When App is first rendered, the Page1 component is rendered. This happens with the help of ChoosePage, which renders the correct page based on the page state that is passed to it. Here's what you'll see when the page state first loads:
Figure 4.8 – The default view of our page
The Page 1 button is disabled because it is the currently active page. There's an ellipsis following the Logged in as message at the bottom of the page. This is because the UserProvider component is waiting for the fetchUser() API call to respond. When the response arrives and the context data is updated, the Page1 component is updated:
Figure 4.9 – The state changes when the fetch call resolves, updating the user name
Last but not least, let's take a look at the page components that use context Hooks:
import * as React from "react";
import { UserContext } from "./UserContext";
function Username() {
const user = React.useContext(UserContext);
return (
<p>
Logged in as <strong>{user.name}</strong>
</p>
);
}
export function Page1() {
return (
<>
<h1>Page 1</h1>
<Username />
</>
);
}
export function Page2() {
return (
<>
<h1>Page 2</h1>
<Username />
</>
);
}
export function Page3() {
return (
<>
<h1>Page 3</h1>
<Username />
</>
);
}
All three page components look pretty much the same, except for the text used in each. Let's focus on the Username component that is used by each page:
function Username() {
const user = React.useContext(UserContext);
return (
<p>
Logged in as <strong>{user.name}</strong>
</p>
);
}
This is where the useContext() Hook is used. The user context value is actually the state that is set by the UserProvider component when the API call responds. This means that the user context value is updated by the useContext() Hook whenever the user value changes.
Another important idea from this example is that the page components (Page1, Page2, and Page3) have no knowledge of this global user data. Instead of having to pass data down from the top-level component as property values, we can rely on useContext() when we need access to global data, no matter how deeply nested the component is in our JSX markup. For components that have nothing to do with the data, such as the page components in this example, there's no need to touch them.
Updating stateful context data
Global data that is shared throughout your application isn't limited to read-only API response data. Sometimes, components themselves need to update global state values. To enable this capability, we need to pass not only data from context producers but also a mechanism to update the data. Since data stored in a context provider is a state created with useState(), we can just pass along the setter function, along with the state value.
Let's illustrate these ideas by extending the sharing fetched data example. Instead of a user context, we'll add a status context. This way, components that are rendered within this context will have access to the status state value and the status state setter function. Here's what the StatusProvider component looks like:
import * as React from "react";
export const StatusContext = React.createContext();
export function StatusProvider({ children }) {
const value = React.useState("set a status");
return (
<StatusContext.Provider value={value}>
{children}
</StatusContext.Provider>
);
}
The StatusProvider component has a status state with a default string value. Recall that useState() returns an array of state value and a state setter function. This array is then passed to the value property of <StatusContext.Provider>. Now, let's take a look at the page components that display and update the status context data:
import * as React from "react";
import { StatusContext } from "./StatusContext";
function SetStatus() {
const [status, setStatus] =
React.useContext(StatusContext);
return (
<input
value={status}
onChange={(e) => setStatus(e.target.value)}
/>
);
}
export function Status() {
const [status] = React.useContext(StatusContext);
return <p>{status}</p>;
}
export function Page1() {
return (
<>
<h1>Page 1</h1>
<SetStatus />
</>
);
}
export function Page2() {
return (
<>
<h1>Page 2</h1>
</>
);
}
export function Page3() {
return (
<>
<h1>Page 3</h1>
<SetStatus />
</>
);
}
Let's take a closer look at the two utility components that consume context data with useContext():
function SetStatus() {
const [status, setStatus] =
React.useContext(StatusContext);
return (
<input
value={status}
onChange={(e) => setStatus(e.target.value)}
/>
);
}
export function Status() {
const [status] = React.useContext(StatusContext);
return <p>{status}</p>;
}
The SetStatus component is used to render an input so that the user can provide new values for the status context. When they do, the setStatus() function that comes from the context data array is used to update the context state. The Status component only renders status, so it doesn't need the setStatus() function that comes from useContext(). The Page2 component doesn't render the SetStatus component, but Page1 and Page2 do.
The Status component is used by the App component to display status on every page, including Page2. Let's see these pages in action now. Here is what the first page looks like when it first loads, using the default status context:
Figure 4.10 – Showing what the user is typing
The text input that sets the status is part of the Page1 component. The succeeding status label shows that the text input that displays the status is part of the App component and will be rendered on every page. Let's try changing the status:
Figure 4.11 – The display changes as the user types
The setStatus() function that was passed in context data is used to update the status state in the StatusProvider component. The new context data is propagated throughout the application components that use it, any time it changes. Let's see what the second page looks like after we've updated the status:
Figure 4.12 – The status update is visible on page 2
The Page2 component doesn't use the SetStatus component, which is why there's no input shown here. But the status label that is rendered by the App component hasn't changed. Lastly, let's take a look at the third page:
Figure 4.13 – Status changes are also reflected on page 3
As expected, the updated status context data is reflected here as well. In fact, since Page3 uses the SetStatus component, you can update the status again and navigate the pages again. The result will be the same, since the same mechanics are in place.
This section showed you how to create a context for global data that various components in your application need to share. One common scenario is an API endpoint with data that most components in the application need access to. You can implement a context provider component that performs this API data fetch and then shares it with other components. The components that require this global data can use the useContext() Hook, which feels a lot like using the useState() Hook.
You also learned that context data can be changed by different components. This involves passing a state setting function as part of the context data so that components can use it to update the context value. In the next section, we'll look at using reducer Hooks to help simplify complex state management.
Using reducer Hooks to scale state management
The useState() Hook is a great way to manage the state of your component. It can become a challenge to use this Hook when your component has a lot of related pieces of state. You end up with a lot of setter functions that you need to call individually, once you've figured out how a change in one state value affects another state value. With reducers, you have one dispatch() function that's used to update the state of your component.
In this section, you'll learn about the basics of reducer actions and how they update the state of your component. Then, we'll look at a more in-depth example that shows you how to handle updating state values that depend on other state values.
Using reducer actions
A reducer function in a React application is a function that takes the current state, an action, and any other arguments that are needed to update the state. It returns the new state of the component. The action argument tells the reducer function what new state to return and is often used in a switch statement. Let's look at an example now:
function reducer(state, action) {
switch (action.type) {
case "changeName":
return { ...state, name: action.value };
case "changeAge":
return { ...state, age: action.value };
default:
throw new Error('${action.type} is not a valid
action');
}
}
function App() {
const [{ name, age }, dispatch] =
React.useReducer(reducer, {
name: "",
age: "",
});
return (
<>
<input
placeholder="Name"
value={name}
onChange={(e) =>
dispatch({ type: "changeName", value:
e.target.value })
}
/>
<p>Name: {name}</p>
<input
placeholder="Age"
type="number"
value={age}
onChange={(e) =>
dispatch({ type: "changeAge", value:
e.target.value })
}
/>
<p>Age: {age}</p>
</>
);
}
Here, we have an App component that renders two fields and two labels. When the text value changes, it should update the corresponding label value. This is done by using two pieces of state, one for each field. Let's take a closer look at how state is set up with the useReducer() Hook:
const [{ name, age }, dispatch] =
React.useReducer(reducer, {
name: "",
age: "",
});
The useReducer() function takes two arguments – the reducer function that updates the state, and the initial state of the component. The return value of useReducer() is an array, with the state as the first element and the dispatcher function as the second. When we use reducers, we only have one object as the state of the component, instead of several smaller, unrelated state values. This is why we're destructuring the state object into name and age constants. Now, let's take a look at the reducer function itself:
function reducer(state, action) {
switch (action.type) {
case "changeName":
return { ...state, name: action.value };
case "changeAge":
return { ...state, age: action.value };
default:
throw new Error('${action.type} is not a valid
action');
}
}
The state argument is the current state of the component. The action argument is the argument that's passed to dispatch(). The action.type value is used to determine what to do. This reducer only has two possible actions – changeName and changeAge. Based on this, we use the object spread operator to return a new state object, made from the existing state and the updated state object values. In this case, based on the action.type value, either the name or age state values will be updated.
It's also important to have a default handler in place that throws an error when an unexpected action is passed to the reducer. It's highly likely that you will get this wrong at some point, and it's better to have the reducer complain loudly about the invalid action than to have to figure out why your component has the wrong state set on it.
Here is what the screen looks like when App is first rendered:
Figure 4.14 – The default input values
Here's what you'll see when you enter some text into these two inputs:
Figure 4.15 – The updated labels once text is added
This example used a reducer function to update two unrelated pieces of state. In other words, you probably could have used the useState() Hook just as easily. However, now that you have an idea of what reducers are and how they handle different actions that are dispatched to them, you're ready to look at a more complex example that involves state values that depend on other state values.
Handling state dependencies
When our components have one piece of state that depends on another, it's difficult to use the useState() Hook. This Hook comes with the assumption that when a state needs to be updated, it's one piece at a time. In real applications, there are often scenarios where updating one piece of state means that another piece of state needs to be updated as well, based on this new value.
Let's look at an example that allows the user to select an item and the quantity of that item. It then shows the cost. This means that whenever the quantity or item fields change, the total must also change. Here's the reducer code:
const initialState = {
options: [
{ id: 1, name: "First", value: 10 },
{ id: 2, name: "Second", value: 50 },
{ id: 3, name: "Third", value: 200 },
],
quantity: 1,
selected: 1,
};
function reduceButtonStates(state) {
return {
...state,
decrementDisabled: state.quantity === 0,
incrementDisabled: state.quantity === 10,
};
}
function reduceTotal(state) {
const option = state.options.find(
(option) => option.id === state.selected
);
return { ...state, total: state.quantity * option.value
};
}
function reducer(state, action) {
let newState;
switch (action.type) {
case "init":
newState = reduceTotal(state);
return reduceButtonStates(newState);
case "decrementQuantity":
newState = { ...state, quantity: state.quantity - 1 };
newState = reduceTotal(newState);
return reduceButtonStates(newState);
case "incrementQuantity":
newState = { ...state, quantity: state.quantity + 1 };
newState = reduceTotal(newState);
return reduceButtonStates(newState);
case "selectItem":
newState = { ...state, selected: Number(action.id) };
return reduceTotal(newState);
default:
throw new Error('${action.type} is not a valid
action');
}
}
Here's the App component that uses the reducer:
export default function App() {
const [
{
options,
selected,
quantity,
total,
decrementDisabled,
incrementDisabled,
},
dispatch,
] = React.useReducer(reducer, initialState);
React.useEffect(() => {
dispatch({ type: "init" });
}, []);
return (
<>
<section>
<button
disabled={decrementDisabled}
onClick={() => dispatch({ type:
"decrementQuantity" })}
>
-
</button>
<button
disabled={incrementDisabled}
onClick={() => dispatch({ type:
"incrementQuantity" })}
>
+
</button>
<input readOnly value={quantity} />
</section>
<section>
<select
value={selected}
onChange={(e) =>
dispatch({ type: "selectItem", id:
e.target.value })
}
>
{options.map((o) => (
<option key={o.id} value={o.id}>
{o.name}
</option>
))}
</select>
</section>
<section>
<strong>{total}</strong>
</section>
</>
);
}
Before jumping into code explanations, let's see what this code actually does. Here's what you'll see when the screen first loads:
Figure 4.16 – The default field values when the screen first loads
By default, the quantity is set to 1 and the First item is selected. The total cost is displayed beneath the two fields. When the page first loads, the total is 10, since the cost of the First item is 10 and the quantity is set to 1. Let's try changing the quantity value, using the increment and decrement buttons beside it:
Figure 4.17 – Incrementing the numeric field value
Here, we've changed the quantity to 5. As you can see, the total reflects this quantity by changing to 50. The quantity state has minimum (0) and maximum (10) restrictions, so if you increase the quantity value to 10, the increment button is disabled:
Figure 4.18 – The maximum allowed value
If you change the selected item, the total is reflected, based on the current quantity value:
Figure 4.19 – Changing the multiplier value
This example has several pieces of state that depend on one another in moderately complex ways. This is a perfect opportunity to put the useReducer() Hook into action. Let's break down what's going on in the code. We'll start by looking at the initial state:
const initialState = {
options: [
{ id: 1, name: "First", value: 10 },
{ id: 2, name: "Second", value: 50 },
{ id: 3, name: "Third", value: 200 },
],
quantity: 1,
selected: 1,
};
The options array is the items that the user can select from; the initial quantity value is 1, and the selected value represents which item is selected. Later on, this component will set several other state values, but these are all that are needed for the initial render. Next, let's take a closer look at the reducer functions that maintain the state of this component:
function reduceButtonStates(state) {
return {
...state,
decrementDisabled: state.quantity === 0,
incrementDisabled: state.quantity === 10,
};
}
function reduceTotal(state) {
const option = state.options.find(
(option) => option.id === state.selected
);
return { ...state, total: state.quantity * option.value
};
}
function reducer(state, action) {
let newState;
switch (action.type) {
case "init":
newState = reduceTotal(state);
return reduceButtonStates(newState);
case "decrementQuantity":
newState = { ...state, quantity: state.quantity - 1 };
newState = reduceTotal(newState);
return reduceButtonStates(newState);
case "incrementQuantity":
newState = { ...state, quantity: state.quantity + 1 };
newState = reduceTotal(newState);
return reduceButtonStates(newState);
case "selectItem":
newState = { ...state, selected: Number(action.id) };
return reduceTotal(newState);
default:
throw new Error('${action.type} is not a valid
action');
}
}
The reducer() function is passed to useReducer() and is responsible for handling different action paths. This particular reducer handles the following actions:
- init: When the component first mounts.
- decrementQuantity: The decrement quantity button was pressed.
- incrementQuantity: The increment quantity button was pressed.
- selectItem: The selected item was changed.
Every one of these actions has the potential to change the total state, which is why the code to compute the total was moved into its own function – reduceTotal(). For example, if the quantity changes or the item changes, we need to compute a new total. When the component first mounts, we also need to compute the total because we don't want to have a default state for something that's derived from other state values. Instead, we introduce the init action and use the useEffect() Hook to call it once when the component is first mounted.
The state of the increment and decrement buttons is dependent on the quantity value. So, the incrementDisabled and decrementDisabled state values are computed in the reduceButtonStates() function, which is used by the init, decrementQuantity, and incrementQuantity actions.
At first glance, it might seem like there's a lot going on in the reducer() function, and you'd be right – there is. But in this example, the goal is to keep related state operations close to one another, since they're related. The perfect place to do this is in a reducer function. Developers look at our code and follow the action flow without much trouble. We also managed to factor out common reducer behavior into its own functions. All of this results in a functional component that doesn't have to directly perform any complex state updates. Instead, it just needs to make dispatch() calls, keeping the component itself focused on markup and event handling.
In this section, you learned that the useReducer() Hook is similar to the useState() Hook in that they are both React state management APIs. Using a reducer function is helpful when you want to keep your component state together as a single object so that you can update it more easily when the updates are complex due to dependencies.
Summary
This chapter introduced you to the new React Hooks API. You started by using the useState() Hook, which is fundamental for using state in functional React components. Then, you learned about useEffect(), which enables life cycle management in functional React components, such as fetching API data when a component is mounted and cleaning up any pending async operations when it is removed. Then, you learned how to use the useContext() Hook in order to access global application data. Lastly, you learned about the useReducer() Hook – an effective replacement for useState() when your component state grows too big or too complex for useState().
In the following chapter, you'll learn about event handling in React components.
blank - a minimal app as clean as an empty canvas
Your project is ready!
