Check out a free preview of the full Complete Intro to React v2 (feat. Router v4 and Redux) course:
The "Managing State" Lesson is part of the full, Complete Intro to React v2 (feat. Router v4 and Redux) course featured in this preview video. Here's what you'd learn in this lesson:

Brian introduces how state is managed in a React application. As data is changed inside a component, React has a controlled process of getting, storing, and modifying the current state. The first instance of a mutable state will be in the Search component where Brian adds and input field for the search term. - https://github.com/btholt/complete-intro-to-react/tree/v2-9

Get Unlimited Access Now

Transcript from the "Managing State" Lesson

[00:00:00]
>> Brian Holt: So we're gonna talk about React State now. So so far, there's no statefulness to this app, right? If you look at this, we've just taken data, and we just display it. There's nothing happening. There's no interaction, right? And I'll say first of all that state is the enemy of all apps.

[00:00:18] In the sense that, if you have a bug, it's almost always a function of state, right? That you have some state somewhere going haywire.
>> Brian Holt: So React specifically tries to address this by reducing the amount of places that you can modify state. And by kind of tying one hand behind your back, you're helping yourself out a lot.

[00:00:41] And this goes back to my analogy of-
>> Brian Holt: Or assertion that, if you see a bug on a page with React, you know where to start. And the reason for that is the only thing that can modify the state of a component is the component itself. Nothing else, no parent, no child, no external forces.

[00:01:02] There's no sideways modification of state in React. That if you have a problem with state, the only place it could have originated from is within the component itself.
>> Brian Holt: Okay, so going back to React State.
>> Brian Holt: Yeah, the way that React limits its ability to have bugs, maybe just limit the surface area where you can have bugs.

[00:01:23] It says, if you want to change the state, it must happen in the component itself.
>> Brian Holt: So if I have like a child component, so for example, if I have state inside of search, right? ShowCard cannot modify the state in search. If we have a problem with search, right, and something's going wrong with the state inside of search.

[00:01:46] It definitely didn't come from ShowCard, because ShowCard has no ability to reach into its parent and modify its state. It didn't come from client app, which is what's including it. Because client app cannot reach into search and modify its state. The only problem that it can have if it's a state problem comes from search itself.

[00:02:05]
>> Brian Holt: Right? And another peculiar way of doing things that react that's kind of, I wouldn't say pioneered, but certainly has pioneered on the front end space. So we have search, and search passes data down into ShowCard via props, right? But notice ShowCard doesn't pass anything back up. And that's by design, and it's on purpose, and there's actually really no way to do it, right?

[00:02:34] So if I have something in ShowCard that needs to get to search, there's no way to push data up. Data only flows down. This is called one way data flow. So if you hear the term as applied to React, and now is being applied to Ember and some of these other libraries.

[00:02:48] This is the idea of one way data flow that data only flows down and never flows up. So what happens if I have data inside of ShowCard that search needs to know about? Well, the way that you deal with that is you take the data out of ShowCard and you put it in search.

[00:03:02] And then you pass it down into ShowCard, right? So basically, if you have two components that need to share some sort of amount of data, the common ancestor is where that data is going to live. So if I had another thing called, I don't know, ratings, right? And both of them needed data, then it would have to live inside of search, right?

[00:03:24] Because there's no way to push into siblings or push it up, it only flows down. This will become more concrete as we actually write code with this, but just know that that's what's happening.
>> Brian Holt: So you might ask yourself, well, what happens if I have a button that needs to modify the state of its parent, right?

[00:03:48] So I have a button that lives in a form. And the form is a child of some parent greater form, right? Cuz that happens, right? That's obviously a real case that we cannot side step. Well, the answer is we basically say, okay child, here is a function. Call this function with the data that you get, and then I will modify my own save personally.

[00:04:13] So basically, you have the child that says, hey parent, I called your callback function with this data cuz I had some event. Now it's your problem, right? I'm not gonna modify your state. You modify your own state. Well this will become more apparent again as we write these sort of things.

[00:04:32] But for right now, we're going to go to search JS. And we're going to make search JS start having a bit of state.
>> Brian Holt: Okay? So I'm in search JS right now. And what I'm gonna do here is, inside of search, before the pre-load part, I'm going to add a header.

[00:04:55]
>> Brian Holt: And I'm going to give it an h1 with svideo.
>> Brian Holt: Come on.
>> Brian Holt: And an input with type='text' and placeholder='Search'.
>> Brian Holt: Okay, so all I did was put a header on the page.
>> Speaker 2: Creation, I know we haven't gotten to Redux yet. But does the paradigm change once we get there?

[00:05:32] Or can we think about it the same way?
>> Brian Holt: Nope, it changes.
>> Speaker 2: And after you, sorry, no. That's a response to someone else, never mind.
>> Brian Holt: Okay.
>> Speaker 2: Carry on.
>> Brian Holt: Okay, so we put this header on the page. And if we save that, go back over here, and refresh.

[00:05:50] Everything broke, cuz I stopped my server again. It should just have, anyway
>> Brian Holt: Refresh, okay, so now I have a nice looking header on the page.
>> Brian Holt: What did I, that's the other thing I had to do. Is I have to put that inside of a div, yep.

[00:06:10] So that your preload shows, just put that inside of a div.
>> Brian Holt: Cuz we don't want those necessarily to be siblings for styling reasons. Cuz used Flexbox, cuz I was lazy.
>> Brian Holt: That's the real reason for that. Okay, so yeah, if you put inside of this div, then you should still have your nice looking styling.

[00:06:40]
>> Brian Holt: Okay.
>> Brian Holt: So you have the search box on here. You can type things in it. But it's one of those things, like if a tree falls in the forest, does it make a sound if no one was there? No one's listening to the events coming off this input.

[00:06:55] No one's keeping track of it. So this is just literally an input box in the page that no one cares about.