Store vs Atomic Libraries

[00:00:00]
>> David Khourshid: One big thing that comes up with state management in React is when do I actually use a third party state management library? And the short answer is that you should use it when the built in patterns that React has doesn't really scale. And remember I talked about in the very beginning, that scale isn't just about the number of lines of code or the number of features you have, but it is about how maintainable and sustainable is this code base when the application grows.

[00:00:31]
And so when things get hairy and all spaghetti y then you have to question like is what I'm doing with React enough, because when you look at other frameworks and libraries such as Svelte or Solid, they have different state management approaches which avoid a lot of the complexity, the accidental complexity that React introduces just because with state management React is a lot more limited, believe it or not.

[00:01:02]
Like this might be controversial, but you can't rely just on React's built in hooks all the time for all use cases of state. Which is why libraries like Redux became so popular. And now there's other libraries like Zustan and Jotai and XState and things like that which people have had to use to sort of smooth over React's incomplete handling of states.

[00:01:29]
And so places that we see this are like when you're over relying on context. So if you have multiple providers or if you have just providers everywhere and it could really be condensed like we heard about earlier, the prop drilling we saw earlier and also of course scattered state logic where there is no central place for specific domains in your app where you could see here's the state, here's how it updates and here's the different actions or events that can change that state.

[00:02:01]
So that's why third party state management libraries exist and that's why you should consider using them when it's rights to I'm not saying that you should replace all of your state management with these libraries, but it is very useful to understand when to use them and how to use them.

[00:02:22]
So in here I outlined just a few ways where it gets really messy. With React states of course we saw prop drilling. There's also state synchronization issues, especially when you have multiple components needing to read the same state and you realize that and you're like well I could either prop drill or move it up to the parents and then do some more prop drilling or use context and suffer the re rendering issue which leads to the context performance problems.

[00:02:55]
Because with context, context was meant for states that wasn't like, that isn't going to frequently change. And so that's why the typical example of context is themes, like a theme or just a user preference or something very simple like that that needs to propagate down to all the components, but is not going to change that often.

[00:03:19]
So that leaves us in an odd spot where we have state that might change a lot, but context is going to just cause a lot of re renders. And of course, like I talked about, state logic is scattered everywhere, especially when you're using hooks, even even when you're using context, unless you're using useReducer, which it has its own problems with boilerplate.

[00:03:43]
It gets really messy. And so that's why there's two types of third party state management libraries. There's the store based approach and the atomic or the signal based approach. And both of these are actually useful. It doesn't need to be an either or. So a store based solution uses a centralized approach.

[00:04:05]
You could think of a store as basically a reducer container. So you have some states and then you have actions or events, depending on what they call them, that can operate on the state and cause that state to transition to a new state. I really like using a store based solution because this is what I call indirect state management.

[00:04:29]
And what that means is you are not directly mutating or updating the state, even if it is immutable. You're not just saying I'm going to change the state whenever I want, however I want, because that's very problematic. And you might have some centralized app logic where the state needs to be in a consistent way.

[00:04:51]
You don't want impossible states, you want to manage things like, for example, a number must have a max value. Or when I'm in the state of results, I need to show the results and I need to be sure that they exist, et cetera. And then there's atomic solutions.

[00:05:08]
So in atom, it's not really well defined atoms and signals, but you could think of them as pieces of data that can change from pretty much anywhere. And so they don't have the restrictions of store based solutions. You can literally just update an atom and just subscribe to its value, so that's where there's libraries like Jotai, Recoil and xdatestore, which I'm going to talk about soon, that do make use of these atoms.

[00:05:42]
And the other cool thing about atoms is that they're reactive. So you could combine two different atoms and when one of them updates, it's going to combine the value of those atoms and update them. So it handles automatic subscriptions and things like that. Again, there's pretty much two different approaches.

[00:06:00]
You should have stores when you have complex logic requirements. When you don't want a piece of state or a piece of data to just change from anywhere, then use a store, because it's going to give you a much more controlled way of managing that state. And you can choose atoms if you want.

[00:06:19]
If you have just state where it's like, I know this can change from anywhere, I really don't care. It's just somewhere where it might change externally, or it's something that we don't necessarily need to have strict control over, and we also want it to be reactive so that we could subscribe to it, et cetera.

[00:06:40]
And again, you could use both of them hand in hand.