This course has been updated! We now recommend you take the State Management with Redux & MobX course.
Transcript from the "Closing Thoughts / Final Q&A: State Tree Structure" Lesson
>> Steve Kinney: So let's talk about kind of a basic conclusion and some of the kind of like high order takeaways to think about. I think a natural question is, MobX versus Redux. Which one should I use? And it's not really a MobX versus Redux thing as much as it is, like a dependency graphs versus immutable state trees issue, right?
[00:00:23] Both of these approaches have, again, like most things in this workshop, trade-offs. And you've got to kind of be the one that makes the choice based on the needs of your application. There's not gonna just be like, here is the answer, use what up the newest library is, right?
[00:00:37] Unfortunately, we're in the position where we have to think about these architectural decisions and make some choices. Dependency graphs are really easy to update, we saw that, just change the thing, and everything works. The nodes can all refer to each other, right? The item can talk to the lists.
[00:00:53] The lists can talk to the item. If it's built out more and more, we can have different models talk to each other. We just need to wire them up in a graph. And I really like the fact that the actions are simple, and they're co-located with the data.
[00:01:05] It's not like they have these actions in this one file, the tree in this other file, I'm communicating across them. I've got a line in the wrong order, even though it's not doing super great on spelling mistakes, on methods there, without auto-complete. You've learned something about me. And the idea is that we know the object.
[00:01:20] We have it by it's identity. And we can compare it rather than look for one that has the same idea or some other kind of thing. But, that's not to say that immutable state trees does not have big advantages as well. When you have one big state tree, taking a snapshot of that entire tree.
[00:01:35] And implementing like a global undo and redo for everything that happened is way easier. Then trying to figure out all the things you changed in different graph nodes and trying to unset them to the previous example. It's a simple tree structure. You can json.stringify the entire tree, and just store it in local storage, or send it to the server.
[00:01:56] And you don't have to worry about two objects being the exact same. You could just be like, do they have properties that I care about, right? So there's some really big advantages to think about. There are a few things that we didn't talk about with immutable state trees, I just wanna cover real quick.
[00:02:11] Again, cuz they fall into the how you think about your code, and how you think about managing state, rather than a given library. And so one thing that we kind of didn't get a chance to talk over as we were getting our hands dirty with. Reduxs and sagas and flux and all of those things is about normalizing our data, right?
[00:02:27] There's a certain part that's not view layer or reacts specific but just how we kind of think about it. We mentioned a little bit earlier on, we say like, yeah, let's just iterate through this array. What happens if your tree has an array that is a thousand, ten thousand items long?
[00:02:42] Are you going to filter through it every time you need to need to remove something, or you just wanna like snip off that node on the tree, right? That will be a lot easier in this case. So the way we've kind of being doing it, because it's like easy as we learn a whole bunch of things, is have things in race, right?
[00:02:58] But again, if you wanna remove item with the idea four, you're gonna need to go through that all right. Also when you have to think about relations, right? You can have one part of the tree reach over and touch a node on the other part where you can count with dependency graph, right?
[00:03:15] And so we see that like we have an owner and then we can reference the owner's table. And we have to, it's on us to keep those things in sync. Right and I don't think there's a big problem with this. Six or seven months ago, I came here and did a class on Firebase and React.
[00:03:33] Firebase uses this tree structure and it works incredibly effectively. But it comes with it's tradeoff that you need to manage. On the one hand, it's a simple tree that you can manipulate. On the other hand, you're in charge of a little bit more than manipulation. So if we're to normalize the data, we'd have it by key.
[00:03:47] And you can just snip off the 4 key on the items. And you can kind of work with bigger data. Cuz basically you can go right in and find the one you're looking for rather than have to filter through all of them. But the really cool thing is because this is all still an emerging field, you don't always have to choose.
[00:04:05] So it's like should I used MobX, or an immutable state tree and like Redux? You could use both. So this is kind of taking a lot of the patterns from Redux and trying them out in MobX. And I think it's a theme that we can learn from. All right, we've looked at a whole bunch of approaches, and we've looked at sometimes, in the context of libraries.
[00:04:26] But how can we mix and match them, how can we solve unique problems for us? Is it possible to implement the undo/redo pattern outside of Redux? Hint, it is, you could theoretically store previous state in a regular react component. You definitely could do that as well, could you figure out how to do it in MobX?
[00:04:44] Probably you could do that as well as you could just hook into each one of those methods. Could you have an action reducer pattern if that was helpful? We saw that you can with MobX state trade. I like this idea of sagas but like I'd rather use promises and async a way to do it.
[00:05:00] Like these are things that once you understand the general patterns of hey. I want to wait and I wanna separate my user interface actions out from the asynchronous parts, you can begin to implement those things. You're not beholden to what a given library is doing. You can start to mix and match and solve the different issues that you need to worry about.
[00:05:18] Like whether you would like undo for API requests like the send the opposite or send the new data like you can build the abstractions around that. You now know the kind of approaches and interests like how some of these patterns work under the hood. You have a really good sense of the lay of the land now I hope.
[00:05:34] But I want you to know that even the people who have a lot of experience are still figuring this stuff out. This is a tweet from Dan Abramov, the creator of Redux. It's basically saying I wasn't super happy with the React state model, so I tried Redux. But maybe we should just fix the React state model.
[00:05:48] We don't always need this. We're all still as a community figuring this out and trying to come up with the best approaches. So I would just as a final cautionary note. I ask you to not say this is the silver bullet, the right thing, the absolute best possible way to do it.
[00:06:05] Because for any given view, there's probably the opposite view on that, right? So my big hope is that you realized that this is not a solved problem. And your now on the team to help figure out these really, really hard issues, congratulations, that's it.
>> Group: [APPLAUSE]
>> Speaker 3: Do you have any thoughts around, you know when you have this really large state object grabbing parts of the tree.
[00:06:34] And interacting with that instead of always pulling down the entire state?
>> Steve Kinney: Yeah, so with the map state to prop, you get to do that, right? But I think there's something to be said that, what I caution with that is, if you find yourself doing it by hand too much.
[00:06:51] It's time to give yourself a better abstraction, like a function or something that handles these things, and have it be tested. The nice part about the tree is you can pass in what you need and never tell it. I'm gonna like, I'm just going to remember every time I implement this to like manage this one thing and the other thing.
[00:07:06] You can pull in how you arrange that tree like you know talk about the firebase one. Unfortunately, with a treelike structure where you can't have interdependencies, a lot of times you duplicate data a lot. You for instance in a chatroom, if you wanted a list of every chatroom.
[00:07:25] You might want to just have chatrooms, right list and that's just the title and the number of people in it. You don't wanna have every message in there cuz then if you just wanted the notes on a tree that where all the chatrooms. You would get every single message in each one two.
[00:07:40] So you might store the list of chatrooms in two places, the chatrooms and then like another reference to the part that has all the messages. So in a tree, you find yourself definitely like storing stuff multiple places. So you can get like the version that you need in a given place versus like yeah yeah yeah this tree is going to have all the chatrooms.
[00:07:58] And all the chatrooms are going to have all the messages in them and then they're going to have references to all of the users. You can't get like whenever you get something like towards the top of the tree, you get everything after it. You can't just like pick out the bottom part.
[00:08:10] So a lot of the times it is trying to keep your tree as flat as possible. And a lot of times the way that you have to do that is by duplicating data repeatedly.
>> Steve Kinney: And then building ourself function so that you're not doing that by hand. [LAUGH] Right, cuz you will screw it up invariably, yeah.
[00:08:34] Like where, like not very good at this as a like animals. [LAUGH], right? Anything repetitive and boring, make the computer do for you. Don't do it yourself, you're going to be bad at it. I mean, you're all great, but you know what I mean.