This course has been updated! We now recommend you take the State Management with Redux & MobX course.

Check out a free preview of the full Advanced State Management in React (feat. Redux and MobX) course:
The "What is Application State" Lesson is part of the full, Advanced State Management in React (feat. Redux and MobX) course featured in this preview video. Here's what you'd learn in this lesson:

React is built for one-way data flow. State stays in the component unless it's passed down.

Get Unlimited Access Now

Transcript from the "What is Application State" Lesson

>> Steve Kinney: So, we're talking about this in about nine parts if you don't count the conclusion as a part. Talking about understanding state, and then we'll kinda move through some of the libraries that we saw in the beginning, right? And so this is not necessarily react specific. This is, again, what does state even mean?

[00:00:22] Is it a state of mind? Is it the data? Is it where they are? What is state? The answer is it's all of those things, right? So we need better definitions. We need better terms that we can touch on as we go through this course together. So, the main job of React, React is famously just a view layer.

[00:00:41] It's not an MVC framework, that's gonna handle your models, and your controllers, and your views. It is simply, a view layer, which is, you give it some view logic, you give it some state, and it turns it into a user interface, right? Which means it is very unopinionated on how you manage that state.

[00:00:59] And there are different patterns that you can bring in and things that you can do. And it's kind of on you to think about these things, which is why we are either in this room watching live or watching the recording later on. It was just because, I'm in charge of these things now.

[00:01:12] There isn't a prescribed way to do it. I need to think about it. And one of the things that I, kind of like go back to a lot. And I think many of us like looked at it when we first saw the React documentation, but haven't thought of it too much lately.

[00:01:27] Is in the React docs there is this kind of piece that multiple parts point to, which is this thinking in React, right? As far as I know I haven't done the difs of the history of it. But it hasn't changed much since the time I started using React a few years ago.

[00:01:45] So I'm gonna do everyone's favorite thing, which is, kind of like redo some parts and look at some quotes from that. To kind of like frame, what does the React team think React's job is in managing state, right? What is the React philosophy on these things. So here is one kinda quote.

[00:02:05] The key here is not to repeat yourself. It's to figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand, right? And that's something that we are gonna see as we go through, walking up each approach. Which is, what things do we need to manage by hand and what things can we figure out from the state we have?

[00:02:24] What other pieces of UI and state can we derive, right? A really kind of core examples is, like a full name, right? What you don't want to be in charge of, is every time the first name or the last name changes you having to go in manually and set the state of the full name.

[00:02:43] You have all the pieces of information that you need, in order to derive that full name. You have the first name and you have the last name. You have a space key on your keyboard, right. You can do this. Because if you end up trying to do these things by hand.

[00:02:56] You end up eventually messing it up, right? Most of the bugs on our application and in just right in the JavaScript are like, we got the wrong type and we didn't get really think about it. Most of the problems in our React applications, which is, we somehow messed up the state of the world, right?

[00:03:13] We've got an out sink with state. So one of the core tenants here, and we'll actually see it from some other quotes later on in this workshop, which is, think about what is the bare minimum amount of state that you need and deriving everything else from that. Cool.

[00:03:32] What is state? Is it passed from a parent via props? It's probably not state. Does it remain unchanged over time? Then it's not state, it's just like static mark up in this case, right. It's like, the copy or somethings part of your code. And again, can you compute it based on other state or profits in your component if so it's not state.

[00:03:50] So it's again, going back to that first one of, what is the bare minimum state that you need? Because the less, the best way to get good at state management is to manage as little state as possible, right? The less of it that you manage, the less of it you have to worry about.

[00:04:04] The easier it is to do. So that will be a kind of a recurring thing. And again, that reaction is all about one way data flow. And we're gonna kind of like break that rule at some points, right? It's we'll always have a one way data flow, cuz that's unavoidable.

[00:04:19] But this second part of like, the flow down the component hierarchy, right? If you have played with Redux, you know that you don't have to pass everything in from the very top. And we'll kind of look at how maybe that part doesn't always apply. But there is this, a lot of times in React applications, this one-way flow.

[00:04:39] A lot of times it's from our state into our views, right? Where the user can do something, right? And most of these libraries is gonna trigger what we call an action, which will change the state, which will then re-render the view. But it's always that kind of like, circle, right?

[00:04:54] Between state goes in to the views, unless the user does a thing, then we change to state exchange the views. All right, and so it's always sort of one way, we can't go both ways in this case. And this is definitely not always easy to wrap your head around, right?

[00:05:13] Ideally if, it's even hard to think about that the event is actually going back and changing the state, which is then rendering the view versus I change an input field, my state changed, right? That's the two way connection. A lot of times it's not and we'll get to explore that a little bit.

[00:05:29] I do wanna harp a little bit on props vs state, cuz I know the thinking and React it says like, okay, props aren't necessarily state. But they are usually someone else's state. They're not necessarily the state of that component if you're encapsulating it. But a lot of times they are the state of a parent component, right.

[00:05:48] That are passed in, right. This is still, cuz if it wasn't something you passed in, then a lot of time this would be static content, right? This is not something that maybe changes in your application. And we're gonna kind of take a very liberal approach and say like, things that can change in your application based on user input, are things that we have to worry about, in terms of state management.

[00:06:06] But, just to kind of clarify these terms a little bit. Because, when we think of both props and state as being forms of state, it's problematic because one of those is called state [LAUGH], right? So we're trying to come up with this more robust working definition, but there is a thing, right?

[00:06:24] We have this.state, and this.state in React components. So it's always hard when we're trying to come up with this broader definition of state to have a thing. That is, when we type it into the computer the word state. So we know the state is created in the component and stays in the component unless it's passed down to its children.

[00:06:42] So here's an example, we have a counter, and then this very ridiculous double count, which is going to just take it in. So, in this case, double count, which is a second counter. Is gonna take in the state of it's parent. It's a child, right? So it's not necessarily the state of the double count, but it is definitely some bodies state, right?

[00:07:04] It just depends on who owns that, right? We think about, state a lot of times in terms of like, which actual component owns it but, clearly we know that the stuff can be passed down the component hierarchy tree.