Managing state in modern React web applications

Editor's Notes

• #5: State is what makes your application interesting.
• #6: When discussing, ”Many, many more” be sure to mention that there is a list of the most popular libraries on a Hackernoon post called ‘The React State Museum” (https://hackernoon.com/the-react-state-museum-a278c726315) What do I mean when I talk about Local State? I’m specifically talking about using the function `setState`, which comes out of the box with React Local state refers to state which is contained inside a single component, usually in a container/dumb component relationship Local state has been a part of React *forever* Context API was experimental until 16.3 when a new revised version was released. React-Redux is a thin wrapper over the legacy Context API. Context API is hierarchical by design, so only applies to a component and all its children. You can put Context API at the root of the application, but if you have multiple applications running on the same page they wont be able to share stata. And also, for everything more than the most basic applications, I see this becoming un-wiedly very quickly. Redux keeps the state of your application in a single place, called the store. The store is immutable and cannot be updated directly. To update the store, you call a function (called a reducer) which makes the changes, which updates the store, which causes your application to re-render. State is the data, store is where the data is kept.
• #7: One does not simply choose a state management tool Know your API’s / libraries There is no reason why you can’t have local state, Redux & Context API all working together in a single application You probably wouldn’t want to choose multiple tools such as Redux, MobX and Unstated in a single React application, because that would add several paradigms and increase complexitity.
• #8: One does not simply choose a state management tool. Know your tools Local State is perfect for normal forms such as log in forms, registration forms, your e-commerce sites checkout, etc. I like to use local state when I’m handling data that isn’t final yet. Context API has a Provider/Consumer pattern. At the root of a component hierarchy (or the root of your application) sits a provider component which contains the state and functions to change the state. The consumer is used on a component anywhere in the same hierarchy, meaning that state doesn’t have to be passed down the tree (called prop drilling) Redux is strikingly similar to Context API in that it effectively has a Provider/Consumer pattern, although its less obvious. The main difference is that instead of having potentially many different states, there is a single state contained within a global store, that can be accessed using a function called `connect`, which can be used to access the state and pass that state through to the component.
• #10: setState is only asynchronous when passed a function, which returns the current state. When called with an object, the function call is executed synchronously. In the interest of future proofing your code (I’m thinking about React Fiber here), you should write your code to work asynchronously. What is the hidden pain? This is a fairly contrived example where we are passing an initial state object to the registration form. What happens, if, after the form has been rendered the first time, the initialState object gets changed, causing a re-rendering? Answer: The registration form will not be reflect the changes, because the local state never gets updated. We used to have a component lifecycle method called ComponentWillReceiveProps, which would pass you the local state and the updated props so you could update your component accordingly, but this lifecycle method has recently been deprecated and will be removed entirely from React in the next major version release.
• #12: Context API to me is really just a wrapper around setState. To use Context API, I wrap the Provider up in a React component, which also carries the state and functions to update the state. Then I use a Consumer to acess the state and those functions to change the state when there is some kind of interaction from the user. Can tidy the code because you don’t have calls to setState all over the place, you get given a state object, which you can deconstruct off you state manipulation functions. No need to say ‘this.state.myProp’ either, just ‘myProp’., which reduces noise. This pattern is easy to conceptualise and reason about, making it approachable to developers of all levels. I have a few complaints. Almost all examples will show usages of the Conumer with ES6 arrow functions and destructuring. Also because of JSX we have to throw in an extra set of curly braces. This makes it syntactically fiddly, even with editor tools such as ‘Indent Rainbow’ and ‘Bracket Pair Colorizer’ I still find myself awkwardly trying to get my brackets to match up. Mention that Enzyme test framework has poor support for Context API currently, although there are workarounds, and this will likely improve in upcoming major releases.
• #14: Why is unit testing straight forward? Your component is often just a stateless functional component, which takes props and has no other external dependencies. In short, your component is a function that takes input and returns output in a simple way. Usually your component will have a default export that connects your component to the Redux store. However, for the sake of unit testing you can simply export your function as-is, avoiding any complete set up, mocking of stores, providers etc, resulting in smaller, cleaner test suite.