Transcript from the "MobX vs Redux" Lesson
>> Steve Kinney: MobX seems great, Redux seems great, right? They are different solutions to the same problem. But as I kind of opened this course with, it is not about the library. It is about the different approaches, right? Our MobX app was still relatively simple, right? There was just one level of dependency.
[00:00:29] And we had the individual item talking to the list of items so on and so forth, right? But it's not really about MobX versus Redux, it's about dependency graphs versus immutable state trees, right? Redux is effectively an immutable state tree, at the end of the day, right? You go, these actions come in, they are easily testable.
[00:01:19] Cuz Redux-Observable had a lot of rules, a lot of structure, and my team keeps growing, right? We were four people when I started on that team. We are, I think, 11 frontend engineers now and we just hired a whole bunch of more, right? I have to keep getting bigger rooms for the frontend architecture guild.
[00:01:35] So having some consistency instead of rules and deterministic ways of doing things are I think really, really important, right? So there are advantages and disadvantages, some of the advantages of a dependency graph. It's super easy to update, it was really easy to implement that, the different objects can just point to each other.
[00:01:55] It's not like, all right, I need to find the one with the ID of this. Well, arrays are stinky for this, so I'm actually gonna have to use. I mean I could just literally say, hey, are you the object I'm looking for? I don't have to find the ID, so on and so forth.
[00:02:06] The actions are simpler and they're co-located with the data, right? We wrote a bunch of computer properties. We had the observable properties in the constructor, we could toggle them right then in there, right? We didn't have to separate, all right, actions over here, producers over there, or initial state, separating out the ability to fetch.
[00:02:25] If you needed to fire an AJAX call, right, we didn't do this, but you can say, hey, if I don't listen, you need to talk to an API, totally cool. The constructor can say, hey, when this object is created, go make the API call, and then update this property on this object, right?
[00:02:41] You could create a method called reload, all right, [LAUGH] that will then fire off that request again. You can have a loading equals false that's observable, and you can set it to true as you're loading and turn it back off to false. It's really easy to have these things there.
[00:03:13] Or setting up as your debugging, and just saying, hey, at the end of the day, your Redux state is one giant JSON object, right? The ability to just rehydrate based off of that is incredibly powerful, right? It's a simple tree structure, right? The dom's a tree structure, my React hierarchy is a tree structure, right?
[00:03:35] We use a lot of ASTs and run a lot of our HTML through hand-built parser's and stuff like that. It is a skill set that was very good for us to navigate trees. We're doing it in other parts of our code base that are not state management. We have a bunch of helper functions that we've written for navigating all sorts of trees.
[00:03:55] It was easy for us to re-leverage those tools. All you need to know is the string of the ID and you can find the thing. Yeah, like I said, you can serialize it, get it from support, so on and so forth. Turns out if you're interested, you can have your cake and eat it too, right?
[00:04:13] There is a library called MobX state tree, which is giving you MobX, and then also a tree-like data structure where you manipulate it. And so instead of maybe arrays, it enforces kind of a normalization that we saw in Redux, right, where we have this tree, all the items.
[00:04:34] Whenever you're dealing with a tree, prefer objects over arrays whenever possible. So this is pure objects all the way down. So you can say items 1 value and you're gonna get everything you need, right then and there.