Transcript from the "Types of State" Lesson
>> Steve Kinney: And that all state is not created equal. The problem with state is that it is a very broad term. And a lot of times even in mono space font the word state, there are a lot of pieces to it, right. There's a lot of different interpretations of it.
[00:00:18] We have our model data. So in the email client I work in the list of campaigns or the number of modules in each campaign, the tweets in a Twitter feed, be restaurants in a Yelp page, rIght? That is model data that is usually coming from the database. And like for a lot of backhand engineers, right?
[00:00:36] And it's a friendly masters course, I can pick on backend engineers, right, no one is gonna get fully offended. When we think about HTTP where you send a request, the only state happening is the database, right? The server springs a life answers the request, sends the response, your kind of interaction is over at that point.
[00:00:56] When we are client side engineers the user opens the application and it's just state until they leave, right? It's where they are in the application is technically state. Whether or not they've sorted the list of restaurants in ascending or descending order based on reviews, that is a form of state, even though we're not changing the restaurants themselves, right?
[00:01:19] How we view it, that is a form of state that has changed. Figuring out if we're telling the user, hey, we're going loading these restaurants, or if we actually have them already, is a form of state. Where are we in the process of getting the model data? And in the case of single page applications, where we are in the app is state, right?
[00:01:40] This is not just a separate index.html page is being rendered. But this is literally we're using the URL to a lot of times, signify the state of the application, right, whether or not they are at a given specific tweet versus a user's page, right? That is also like state.
[00:01:55] So we need to get a little bit more specific as well. The only thing I wanna think about is Is long-lasting state versus what I'm gonna call ephemeral state. And when we talked about, you might not just take one approach, right? Even if you're like, I'm using Redux.
[00:02:12] There might be times that you still use component state, right. Because depending on the state that you're working with, it might make sense to handle it differently, right? Model state is usually like long-lasting state. It's what the user's working with while they're in the application, right? They're in Gmail, it's a list of emails that they're looking at, right?
[00:02:30] However, what they're currently typing in an input field before they hit Enter, if they're adding in a new to-do or if they're searching their inbox in Gmail, that's definitely more like short lived state. And we're gonna kinda go back and forth a few times with this today. We're going to sometimes we're gonna keep that ephemeral state in a Redux store.
[00:02:48] We're gonna use a flux architecture but then keep it in a component state, right, and kind of, get a feel for both of these to figure out which one works better in different situations and sometimes it's a personal choice, right. Which one are you more comfortable with, right?
[00:03:02] There's a certain beauty to having all of the state of your application in one serializable object that you can store in local storage or send back to the server but there are costs, right. Not just performance costs but complexity cost, right, indirection cost that you have to think about and deal with so we're gonna take a look at both of those.
[00:03:21] So as we look at different components over the next day or two, as we try different approaches, I want you to ask yourself a few questions. Does an input field need the same kind of state management as your model data, right? Again, we're gonna try it both ways.
[00:03:36] It's kind of up to you to figure out, in the application that you work on a day to day basis or is your general life philosophy, how you feel about this. I personally have gone back and forth six times on this topic, right. Put everything in the Redux Store, right, and then it's all in one place.
[00:03:53] Versus do I really need to fire an action to a reducer to change the store because they typed something in a form, right. I've gone back and forth about this I don't now if there's a always do this answer, right, even overtime, right, your thoughts and, I think a lot of this is still in evolving art form.
[00:04:17] So think about input fields, formed validation, storing it all in one place, versus compartmentalizing your data across multiple stores, right? There are advantages and disadvantages to both, right? And what our job over the next day or two is to explore those differences, right? To understand what are the trade-offs, and what, for the given thing that I'm trying to solve, is a better choice.
[00:04:38] Because spoiler alert there is not a silver bullet. We're gonna see, kind of, through out this and towards the end that even people in the community, I won't name it at this point, but you had it like you would associate them with given library or project. It's not always clear that they've even bought into it.
[00:04:58] There's always one way to do things, right. So it's interesting that I don't know we're in a position to do that as well, so part of our job is to explore this, talk about this, figure it out, weigh the trade offs and ultimately shrug and be slightly undecided.
[00:05:14] Because like most of the community right now is undecided as well and I like to think I'm smarter than everyone, that's probably not true. My wife would agree with that.