Transcript from the "Some Rules for Reducers" Lesson
[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: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.