State Management in React and beyond

You have already learned the basics of state management in React in the previous chapters. This chapter digs a bit deeper into the topic. You will learn best practices, how to apply them and why you could consider using a third-party state management library.

Lifting State

Only the App component is a stateful ES6 component in your application. It handles a lot of application state and logic in its class methods. Maybe you have noticed that you pass a lot of properties to your Table component. Most of these props are only used in the Table component. In conclusion one could argue that it makes no sense that the App component knows about them.

The whole sort functionality is only used in the Table component. You could move it into the Table component, because the App component doesn’t need to know about it at all. The process of refactoring substate from one component to another is known as lifting state. In your case, you want to move state that isn’t used in the App component into the Table component. The state moves down from parent to child component.

In order to deal with state and class methods in the Table component, it has to become an ES6 class component. The refactoring from functional stateless component to ES6 class component is straight forward.

Your Table component as a functional stateless component:

{title=”src/App.js”,lang=javascript}

  1. const Table = ({
  2.   list,
  3.   sortKey,
  4.   isSortReverse,
  5.   onSort,
  6.   onDismiss
  7. }) => {
  8.   const sortedList = SORTS[sortKey](list);
  9.   const reverseSortedList = isSortReverse
  10.     ? sortedList.reverse()
  11.     : sortedList;
  13.   return(
  14.     ...
  15.   );
  16. }

Your Table component as an ES6 class component:

{title=”src/App.js”,lang=javascript}

  1. # leanpub-start-insert
  2. class Table extends Component {
  3.   render() {
  4.     const {
  5.       list,
  6.       sortKey,
  7.       isSortReverse,
  8.       onSort,
  9.       onDismiss
  10.     } = this.props;
  12.     const sortedList = SORTS[sortKey](list);
  13.     const reverseSortedList = isSortReverse
  14.       ? sortedList.reverse()
  15.       : sortedList;
  17.     return(
  18.       ...
  19.     );
  20.   }
  21. }
  22. # leanpub-end-insert

Since you want to deal with state and methods in your component, you have to add a constructor and initial state.

{title=”src/App.js”,lang=javascript}

  1. class Table extends Component {
  2. # leanpub-start-insert
  3.   constructor(props) {
  4.     super(props);
  6.     this.state = {};
  7.   }
  8. # leanpub-end-insert
  10.   render() {
  11.     ...
  12.   }
  13. }

Now you can move state and class methods regarding the sort functionality from your App component down to your Table component.

{title=”src/App.js”,lang=javascript}

  1. class Table extends Component {
  2.   constructor(props) {
  3.     super(props);
  5. # leanpub-start-insert
  6.     this.state = {
  7.       sortKey: 'NONE',
  8.       isSortReverse: false,
  9.     };
  11.     this.onSort = this.onSort.bind(this);
  12. # leanpub-end-insert
  13.   }
  15. # leanpub-start-insert
  16.   onSort(sortKey) {
  17.     const isSortReverse = this.state.sortKey === sortKey && !this.state.isSortReverse;
  18.     this.setState({ sortKey, isSortReverse });
  19.   }
  20. # leanpub-end-insert
  22.   render() {
  23.     ...
  24.   }
  25. }

Don’t forget to remove the moved state and onSort() class method from your App component.

{title=”src/App.js”,lang=javascript}

  1. class App extends Component {
  3.   constructor(props) {
  4.     super(props);
  6.     this.state = {
  7.       results: null,
  8.       searchKey: '',
  9.       searchTerm: DEFAULT_QUERY,
  10.       error: null,
  11.       isLoading: false,
  12.     };
  14.     this.setSearchTopStories = this.setSearchTopStories.bind(this);
  15.     this.fetchSearchTopStories = this.fetchSearchTopStories.bind(this);
  16.     this.onDismiss = this.onDismiss.bind(this);
  17.     this.onSearchSubmit = this.onSearchSubmit.bind(this);
  18.     this.onSearchChange = this.onSearchChange.bind(this);
  19.     this.needsToSearchTopStories = this.needsToSearchTopStories.bind(this);
  20.   }
  22.   ...
  24. }

Additionally, you can make the Table component API more lightweight. Remove the props that are passed to it from the App component, because they are handled internally in the Table component now.

{title=”src/App.js”,lang=javascript}

  1. class App extends Component {
  3.   ...
  5.   render() {
  6. # leanpub-start-insert
  7.     const {
  8.       searchTerm,
  9.       results,
  10.       searchKey,
  11.       error,
  12.       isLoading
  13.     } = this.state;
  14. # leanpub-end-insert
  16.     ...
  18.     return (
  19.       <div className="page">
  20.         ...
  21. # leanpub-start-insert
  22.         <Table
  23.           list={list}
  24.           onDismiss={this.onDismiss}
  25.         />
  26. # leanpub-end-insert
  27.         ...
  28.       </div>
  29.     );
  30.   }
  31. }

Now in your Table component you can use the internal onSort() method and the internal Table state.

{title=”src/App.js”,lang=javascript}

  1. class Table extends Component {
  3.   ...
  5.   render() {
  6. # leanpub-start-insert
  7.     const {
  8.       list,
  9.       onDismiss
  10.     } = this.props;
  12.     const {
  13.       sortKey,
  14.       isSortReverse,
  15.     } = this.state;
  16. # leanpub-end-insert
  18.     const sortedList = SORTS[sortKey](list);
  19.     const reverseSortedList = isSortReverse
  20.       ? sortedList.reverse()
  21.       : sortedList;
  23.     return(
  24.       <div className="table">
  25.         <div className="table-header">
  26.           <span style={{ width: '40%' }}>
  27.             <Sort
  28.               sortKey={'TITLE'}
  29. # leanpub-start-insert
  30.               onSort={this.onSort}
  31. # leanpub-end-insert
  32.               activeSortKey={sortKey}
  33.             >
  34.               Title
  35.             </Sort>
  36.           </span>
  37.           <span style={{ width: '30%' }}>
  38.             <Sort
  39.               sortKey={'AUTHOR'}
  40. # leanpub-start-insert
  41.               onSort={this.onSort}
  42. # leanpub-end-insert
  43.               activeSortKey={sortKey}
  44.             >
  45.               Author
  46.             </Sort>
  47.           </span>
  48.           <span style={{ width: '10%' }}>
  49.             <Sort
  50.               sortKey={'COMMENTS'}
  51. # leanpub-start-insert
  52.               onSort={this.onSort}
  53. # leanpub-end-insert
  54.               activeSortKey={sortKey}
  55.             >
  56.               Comments
  57.             </Sort>
  58.           </span>
  59.           <span style={{ width: '10%' }}>
  60.             <Sort
  61.               sortKey={'POINTS'}
  62. # leanpub-start-insert
  63.               onSort={this.onSort}
  64. # leanpub-end-insert
  65.               activeSortKey={sortKey}
  66.             >
  67.               Points
  68.             </Sort>
  69.           </span>
  70.           <span style={{ width: '10%' }}>
  71.             Archive
  72.           </span>
  73.         </div>
  74.         { reverseSortedList.map((item) =>
  75.           ...
  76.         )}
  77.       </div>
  78.     );
  79.   }
  80. }

Your application should still work. But you made a crucial refactoring. You moved functionality and state closer into another component. Other components got more lightweight again. Additionally the component API of the Table got more lightweight because it deals internally with the sort functionality.

The process of lifting state can go the other way as well: from child to parent component. It is called as lifting state up. Imagine you were dealing with internal state in a child component. Now you want to fulfill a requirement to show the state in your parent component as well. You would have to lift up the state to your parent component. But it goes even further. Imagine you want to show the state in a sibling component of your child component. Again you would have to lift the state up to your parent component. The parent component deals with the internal state, but exposes it to both child components.

Exercises:

Revisited: setState()

So far, you have used React setState() to manage your internal component state. You can pass an object to the function where you can update partially the internal state.

{title=”Code Playground”,lang=”javascript”}

  1. this.setState({ foo: bar });

But setState() doesn’t take only an object. In its second version, you can pass a function to update the state.

{title=”Code Playground”,lang=”javascript”}

  1. this.setState((prevState, props) => {
  2.   ...
  3. });

Why should you want to do that? There is one crucial use case where it makes sense to use a function over an object. It is when you update the state depending on the previous state or props. If you don’t use a function, the internal state management can cause bugs.

But why does it cause bugs to use an object over a function when the update depends on the previous state or props? The React setState() method is asynchronous. React batches setState() calls and executes them eventually. It can happen that the previous state or props changed in between when you would rely on it in your setState() call.

{title=”Code Playground”,lang=”javascript”}

  1. const { fooCount } = this.state;
  2. const { barCount } = this.props;
  3. this.setState({ count: fooCount + barCount });

Imagine that fooCount and barCount, thus the state or the props, change somewhere else asynchronously when you call setState(). In a growing application, you have more than one ‘setState()’ call across your application. Since setState() executes asynchronously, you could rely in the example on stale values.

With the function approach, the function in setState() is a callback that operates on the state and props at the time of executing the callback function. Even though setState() is asynchronous, with a function it takes the state and props at the time when it is executed.

{title=”Code Playground”,lang=”javascript”}

  1. this.setState((prevState, props) => {
  2.   const { fooCount } = prevState;
  3.   const { barCount } = props;
  4.   return { count: fooCount + barCount };
  5. });

Now, lets get back to your code to fix this behavior. Together we will fix it for one place where setState() is used and relies on the state or props. Afterward, you are able to fix it at other places too.

The setSearchTopStories() method relies on the previous state and thus is a perfect example to use a function over an object in setState(). Right now, it looks like the following code snippet.

{title=”src/App.js”,lang=javascript}

  1. setSearchTopStories(result) {
  2.   const { hits, page } = result;
  3.   const { searchKey, results } = this.state;
  5.   const oldHits = results && results[searchKey]
  6.     ? results[searchKey].hits
  7.     : [];
  9.   const updatedHits = [
  10.     ...oldHits,
  11.     ...hits
  12.   ];
  14.   this.setState({
  15.     results: {
  16.       ...results,
  17.       [searchKey]: { hits: updatedHits, page }
  18.     },
  19.     isLoading: false
  20.   });
  21. }

You extract values from the state, but update the state depending on the previous state asynchronously. Now you can use the functional approach to prevent bugs because of a stale state.

{title=”src/App.js”,lang=javascript}

  1. setSearchTopStories(result) {
  2.   const { hits, page } = result;
  4. # leanpub-start-insert
  5.   this.setState(prevState => {
  6.     ...
  7.   });
  8. # leanpub-end-insert
  9. }

You can move the whole block that you have already implemented into the function. You only have to exchange that you operate on the prevState rather than this.state.

{title=”src/App.js”,lang=javascript}

  1. setSearchTopStories(result) {
  2.   const { hits, page } = result;
  4.   this.setState(prevState => {
  5. # leanpub-start-insert
  6.     const { searchKey, results } = prevState;
  8.     const oldHits = results && results[searchKey]
  9.       ? results[searchKey].hits
  10.       : [];
  12.     const updatedHits = [
  13.       ...oldHits,
  14.       ...hits
  15.     ];
  17.     return {
  18.       results: {
  19.         ...results,
  20.         [searchKey]: { hits: updatedHits, page }
  21.       },
  22.       isLoading: false
  23.     };
  24. # leanpub-end-insert
  25.   });
  26. }

That will fix the issue with a stale state. There is one more improvement. Since it is a function, you can extract the function for an improved readability. That’s one more advantage to use a function over an object. The function can live outside of the component. But you have to use a higher order function to pass the result to it. After all, you want to update the state based on the fetched result from the API.

{title=”src/App.js”,lang=javascript}

  1. setSearchTopStories(result) {
  2.   const { hits, page } = result;
  3.   this.setState(updateSearchTopStoriesState(hits, page));
  4. }

The updateSearchTopStoriesState() function has to return a function. It is a higher order function. You can define this higher order function outside of your App component. Note how the function signature changes slightly now.

{title=”src/App.js”,lang=javascript}

  1. # leanpub-start-insert
  2. const updateSearchTopStoriesState = (hits, page) => (prevState) => {
  3.   const { searchKey, results } = prevState;
  5.   const oldHits = results && results[searchKey]
  6.     ? results[searchKey].hits
  7.     : [];
  9.   const updatedHits = [
  10.     ...oldHits,
  11.     ...hits
  12.   ];
  14.   return {
  15.     results: {
  16.       ...results,
  17.       [searchKey]: { hits: updatedHits, page }
  18.     },
  19.     isLoading: false
  20.   };
  21. };
  22. # leanpub-end-insert
  24. class App extends Component {
  25.   ...
  26. }

That’s it. The function over an object approach in setState() fixes potential bugs yet increases readability and maintainability of your code. Furthermore, it becomes testable outside of the App component. You could export it and write a test for it as exercise.

Exercise:

  • read more about React using state correctly
  • refactor all setState() methods to use a function
    • but only when it makes sense, because it relies on props or state
  • run your tests again and verify that everything is up to date

Taming the State

The previous chapters have shown you that state management can be a crucial topic in larger applications. In general, not only React but a lot of SPA frameworks struggle with it. Applications got more complex in the recent years. One big challenge in web applications nowadays is to tame and control the state.

Compared to other solutions, React already made a big step forward. The unidirectional data flow and a simple API to manage state in a component are indispensable. These concepts make it easier to reason about your state and your state changes. It makes it easier to reason about it on a component level and to a certain degree on a application level.

In a growing application, it gets harder to reason about state changes. You can introduce bugs by operating on stale state when using an object over a function in setState(). You have to lift state around to share necessary or hide unnecessary state across components. It can happen that a component needs to lift up state, because its sibling component depends on it. Perhaps the component is far away in the component tree and thus you have to share the state across the whole component tree. In conclusion components get involved to a greater extent in state management. But after all, the main responsibility of components should be representing the UI, shouldn’t it?

Because of all these reasons, there exist standalone solutions to take care of the state management. These solutions are not only used in React. However, that’s what makes the React ecosystem such a powerful place. You can use different solutions to solve your problems. To address the problem of scaling state management, you might have heard of the libraries Redux or MobX. You can use either of these solutions in a React application. They come with extensions, react-redux and mobx-react, to integrate them into the React view layer.

Redux and MobX are outside of the scope of this book. When you have finished the book, you will get guidance on how you can continue to learn React and its ecosystem. One learning path could be to learn Redux. Before you dive into the topic of external state management, I can recommend to read this article. It aims to give you a better understanding of how to learn external state management.

Exercises:

{pagebreak}

You have learned advanced state management in React! Let’s recap the last chapters:

  • React
    • lift state management up and down to suitable components
    • setState can use a function to prevent stale state bugs
    • existing external solutions that help you to tame the state

You can find the source code in the official repository.