State Management in Pure React, v2 Types of State
This course has been updated! We now recommend you take the React Performance course.
Transcript from the "Types of State" Lesson
>> There's a lot of different kinds of state. The kind of one that we talked about originally was what I call model data, right? Which is the kind of nouns in our application, the things, right? If it is a catalog of products, it is the list of products, each individual product, the price or description, or something along those lines, that's probably stored on the server, right?
[00:00:23] So on and so forth, it's a given order. It's a to-do on a to-do list. It is a email campaign in marketing campaign's product, right? It doesn't, yeah, it is the actual thing that we're kinda persisting, that we're working with in the application. But there's other kinds of state as well.
[00:00:38] There is this kinda view level UI state, right? Which is, we have the list of all of your reports, right? Now, is that list sorted in ascending or descending order? Are they currently filtering it, right? There's all these different kinda things based on we have the nouns in our application, but there's some extra information about how we view it.
[00:00:56] And we don't normally store that it in the database, or anything along those lines. But we do need to keep track of it in our application. We have the session states. Is the user logged in? Which user are they? Can they see this, so on and so forth, right?
[00:01:08] That is another state of the application, logged in, logged out, able to access the given resource, so on so forth. Communication, right? As we go and get that model data from the API, what is the state of that? Are we currently loading it? Has it loaded? Are we updating it?
[00:01:28] Was there an error? There's some state, and even the kind of time based metric of how we go to get other pieces of state, right, if we're doing something. And finally, location. Where are we in the application, right? The traditional model of the web, which is you had a URL that loaded an HTML page, right?
[00:01:49] And it's like, okay, where on the server was that page? Now, we know that for a lot of robust client-side applications, the URL is, a lot of times, there's one index.html page. We do a bunch of tomfoolery with client-side routing, to kind of load different controllers in the application, and so on and so forth.
[00:02:06] So where are we? Are we looking at a given product in the catalog? Are we in the shopping cart? Well, that's a different state of the application. In a perfect world, yeah, I'm not gonna shame any applications. But we all have known the ones where we're like, we find one with some dank meme, and we wanna send it to our friends.
[00:02:23] We drop it into the mess, and they get the homepage, right? And that's kind of base level table stakes for a client side application these days, right? But it could go a little bit further, right? What if they navigate away from the descendant lease ascending the sorted list of products, go to a product description, and come back, right?
[00:02:42] We could choose to store that in the URL. Or they could say, okay, I wanna send you the list of all these reports that have been filtered by this client, sorted by this date. As long as the user is logged in, they should see that exact same one.
[00:02:54] If we store that in the URL, then we have the ability to kind of persist that without storing the database, and not losing it when the page is refreshed, right? So it's another form of state that we might need to deal with. Now, it's really hard to talk about five or more pieces of state.
[00:03:09] So generally speaking, when I reference the kind of different ways we might deal with state, I'm probably just going to boil it down into two, effectively model state and everything else, right? This more ephemeral state that we're not keeping anywhere, or do anything like that. And we're gonna look at a bunch of different approaches.
[00:03:28] And like I said before, sometimes we're gonna solve a problem, and then we're gonna recreate a problem. At the end of the day, there is not necessarily a silver bullet. One of the things that I like to say, right, my own fortune cookie piece of wisdom here, is that anything that has clear rules, we can abstract out to the framework.
[00:03:47] We can abstract out to the compiler, or something along those lines. We're left with the tough choices, so that's why they pay us. So for a lot of these things is to understand the trade-offs, and then apply them to the very specific and unique problems in your application.
[00:04:01] So we're just gonna talk about some of the kind of general approaches. But there isn't always do this, or never do that, right? Cuz we actually already baked those in. We're only left with the tough choices, and the kind of tricky trade-offs.