3 Essential Tips for Managing State in React Applications

Learn a few quick and essential tips on working with State in a React app to help you decide which option (like out-of-the-box, Redux or MobX) is right for your environment.

If you're new to React, or are getting ready to start a new React application, you're thinking a lot about the tools and libraries you want to use. You're considering Kendo UI, Bootstrap or Semantic UI for your visual components. You're debating the merits of Yarn and npm and trying to determine which is the best solution for package management.

(Also check out Bandon's 3 Performance Tips to Speed Up Your React Applications)

As you create a plan for your app, I'll bet you're also thinking about application state. You're trying to decide if you can use what React provides, out-of-the-box. Or whether to start with a state management solution, like Redux or MobX.

 

After all, it seems like every front-end developer you meet these days introduces themselves as a "React/Redux" or "React/MobX" dev, so doesn't that mean that you always need one of these libraries?

Fear not, intrepid developer! For I am here to provide a few quick and essential tips that you can use to help demystify how to start working with State in your a React app.

Don't be Afraid to Start with setState()

First things first, if you're new to React, or starting a new React app, start with React's built-in state functionality. Unless you are absolutely sure that new app is going to grow to be a complex behemoth, resist the urge to start with a state management solution. I have two reasons for making this recommendation. First, if you're new to React, you should focus on learning React’s ins and outs before you introduce an external dependency. Redux and MobX are great, but picking up a state solution at the same time you learn React will not only steepen your learning curve, but will muddy your understanding of both. Get comfortable with React, and then, when the time is right, add another piece to the puzzle.

The second reason is valid for both new and seasoned React developers: YAGNI. That's right, "You aren't gonna need it." You may think you do, whether in one week, a month or a year, but chances are, you don't need it now. Today. So, start with setState(), focus on "thinking in React" for as long as you can. If things change, grab a solution, and refactor away.

When Needed, Reach for Redux or MobX...

The app you're building might stay simple for a long time, and you may find setState() to be a fine solution to handling UI changes within and between components. So when is the right time to consider adding Redux or MobX to your app?

There's no hard and fast rule. Complexity tends to creep into our apps and rear its head suddenly. When you find yourself passing state between components over and over again or bubbling up child component state level after level so that a parent or higher-order component can use that state, you’ll know it's time for a solution.

Both Redux and MobX are organized around the principle of implementing one or more stores to manage state. Components then dispatch state changes to those stores and subscribe to state changes when they need access to state. These patterns introduce indirection and complexity into your app, but when the state of your app itself grows in complexity, it's a good idea to reach for one of these.

As for which solution is right for you, whether Redux, MobX or something else, my advice would be to kick the tires on both, pick one and move forward. Redux and MobX have their pros and cons, but they're both great and well-supported.

...But it's Okay to Keep Using setState()

Finally, if you do decide to implement a state management solution, feel free to continue using setState(), in certain circumstances.

Consider: does a button press in a child component that updates the UI of that component but has no impact elsewhere in the hierarchy really need to make its way into a state store?

Probably not.

One of the mistakes I made the first time I implemented Redux was putting everything into the Redux store, creating actions and reducers for every single UI change. This comes with its own form of creeping complexity that, when unchecked, might leave you wondering if you ever needed a state management solution in the first place.

There are many times where it's ok to keep using local component state, even when using a solution like Redux or MobX. My personal rule of thumb is to use local state UI interactions that are totally self-contained, or with components that are meant to be portable, therefore not reliant on a global store.

An example: In a recent project, we created a Map component that was used in several places in the app to display incident details, current locations and the like. The component relied on state (via Props) for the data it displayed, but we used local state to manage internal state, such as which map pin was selected, and whether an info window should be displayed. The constructor looked something like this:

 

Conclusion: Remember YAGNI

Bottom line: it's ok to use local state, especially if it helps you keep global state clean and organized.

When starting a new React app, whether you're a React newbie or a seasoned pro, it can be tempting to add a state management solution from the jump. Before you do, though, remember YAGNI and consider waiting until the time is right.

Learn More Tips

For more tips, tricks and considerations for starting a new React application, check out the “Planning a React Application” whitepaper.

Plan Your React App