Some Rules for Reducers

[00:00:00]
>> We didn't initially bring this up. But we saw that if you mutate an object, it's very hard for JavaScript to know that it changed and it's a new value which makes react very sad. So, a lot of times you noticed we did just a plus sign plus sign, the value, we swapped it out with a brand new object with a brand new number.

[00:00:20]
The other one is we have that return state at the bottom. If none of those conditionals are hit, we still need to return something. That's just a JavaScript function. But to kind of look at that question is, let's say I had a deeply nested object, right? So here we've got an angry blog post that I wrote.

[00:00:36]
And it's got a title, a content, and author. Those are all pretty easy to change in one reducer. You could have update title as an action type, update content as an action type, update. Author gets a little tricky, right? Cuz what if I want to just update the location that I'm in?

[00:00:54]
Well, I have to kind of, and this was worse before year six, right? Year six I had to use the use object dot assign or build new objects with a for loop or so on and so forth, right? But I have to make sure that I'm constantly spreading each part as I navigate down the object, right?

[00:01:10]
And so this is kind of towards the question. I'm gonna ask me, which is, what do you do in this case? Well, there's nothing stopping you from being able to either, when you create the, say to aim for the flattest possible option or to kind of break it down to reduce as well.

[00:01:27]
You might have a location that just points to a number that's in a different piece of the state that just manages all the locations. And we'll actually see that in a later example as well. Mark.
>> Does it ever make sense to have multiple stores?
>> No, it's actually an anti pattern to have multiple stores, right?

[00:01:44]
There's usually one provider and there are some deep level kind of hooks if you're trying to create a third party library. That might use Redux, that doesn't wanna clash with the other one. But generally speaking, you will have one store and you'll just kinda have one giant set of your data.

[00:01:59]
And there's some reasons why this is actually helpful on top of it, just because they said it was an anti pattern, right? Having your state split between multiple stores means they kind of the what it takes to put your app in that, not to overuse the word state is now split up, right?

[00:02:15]
Having one JavaScript object that represents the state. We'll actually see this in the Redux DevTools. You can then, let's say, if a customer has a problem, they got themselves in some weird state, you can actually serialize the entire state of the application, get it as a JSON object and then load it in and development and work with it, right?

[00:02:34]
So having everything in one store is both practical for debugging but also becomes problematic with like different stores clashing with each other. The React Redux tools is expecting one context that is the register route, so on and so forth, right? Otherwise our useReducer will get very confused or our useSelect and useDispatch will get very confused, so on and so forth.

[00:02:54]
So generally speaking, one store, but we might split up into many reducers. Question.
>> Yeah, let's see, I had a question. So, if you have a deeply nested object that you're getting from your back end or whatever, and so you have to mutate it right in your Redux store at some point over time.

[00:03:14]
Would you recommend breaking that hierarchy into like a flatter structure when storing it in your store?
>> Absolutely. So the question was like, let's say, I don't control the API and I'm getting a deeply nested object from the API, but I have to manage it on the client side, right?

[00:03:30]
For that, actually, we do this in some of the applications I've worked on Twilio, where we'll have at the API layer, we're making the requests. We will say, neat, this is what the API gave me. We will translate it into a flatter structure that works really well for the way that we see both because the UI might be very different than the API, right?

[00:03:49]
A lot of times we use public APIs, which some of them were initially developed for the on the send grid side for sending emails, I mean, your server side. They're not necessarily built to build our UIs. But sometimes you don't totally control the API. So what we'll do is, as the JSON payload comes in from the server, we will reformat as we need it, and as we make the POST requests, we'll have a layer that just translates it back and forth each way so that we have the state that works the way that we want it to.

[00:04:16]
The other really great advantage of that is, if the API changes, you don't have to go everywhere there was line on the structure shape like that, you change it where you were doing the translation from the API. And to the API, you trick it so you go back to where the UI expects and it is a lot easier to work with as well.