Intro to React State Management

Module 9, State Management in Complex Apps. We've come along where since firing up our very first React app and generating a simple welcome message for our visitors. Now that we've arrived at one of the most complex topics you'll come across in React, Redux. We'll learn about the specifics of the Redux state management pattern in the next lesson, but first we need to talk a little more about why Redux came about. We need to understand state management and why it matters. When we talk about state, in this sense, we're really talking about the set of values that are persisted for the lifetime of our app. Across multiple page views or activities. Out of the box React and indeed JavaScript itself provide a very limited idea of state. We've already seen this in action with features like the use state hook, where we can store some state in top level components, and we can send it down to child components, and these child components themselves can have their own state values. All of this is fine, but it doesn't scale very well and can become very cumbersome to manage. For example, within a localized state model there is a tight coupling between what the user does, their interactions, and changes in state. A change in one place, e.g. Marking and Notification is read, has an impact on the other areas of the app, e.g. in the header notification areas or their messages view. In real-world apps that grow in size and complexity we need a better way to dec ouple some of this dependency between user interactions, parent components, children and state, as well as being able to persist any global state values into a centralized cross-app location. There's also a discussion to be had around whether you have one large centralized state or several smaller but still global slices, each representing areas of interest, e.g. you might have a user's state or an account state. Local state has its place of course, if you're dealing with some data or set of values that are only specific to a couple of components, then it doesn't make sense to hoist it up to an app-wide global level. But we need to ensure a single source of truth. Being able to move particular values into a centralized state location means that we no longer have to be concerned with data becoming stale or conflicted with other identical local components state. We've effectively introduced a single source of truth that other components can subscribe to for values they need. One of the downsides is that we now have centralized areas of state with multiple components trying to make changes to it. The problem with state management is that it can be very complex to handle and we don't want to tie components directly to it. We need some sort of mechanism that will act as our state concierge of sorts, handling changes instead, keeping interested parties up to date with these changes and yet keeping that direct link with how state is affected away from components. To solve this issue and other complex architectural problems, Facebook invented a pattern called Flux. We're not going to get into Flux in this course, but it formed the foundation of Redux, which we'll now look at in the very next lesson. [ sense of silence ]