Immer Solution

[00:00:00]
>> All right, so our mission was to kinda take a little bit of the approach that we did here and modify it so that it also works with the quantity, kinda just to again reaffirm that muscle memory here. We're gonna return produce, we'll say state, and we'll get that draft state again.

[00:00:22]
And that draft state, we're gonna basically need to find the item one more time, so we'll grab that. We might abstract that out to a function, but it needs to know, it needs the draft state that's in the closure. So I'd have to use a little bit of functional programming to make that happen, which seems a bit much for this use case.

[00:00:38]
We'll just change the item quantity, action.payload.uid. Now, there might be a little voice in your head that's saying, do I have to do this for everything? This is also a little bit tedious, right?. Again, that's the voice that we want to listen to. One of the biggest pieces of advice I give these engineers is listen to that voice, cuz it will usually guide you in the right direction.

[00:01:08]
I think it's a Larry Wall quote, he's a creative pro, which is the three fundamental traits of a engineer is laziness and patience and hubris, right? Those things that are tedious, listen to them cuz they're usually the sign that there's probably a better way forward. So if you think about it, really in each one of these conditionals we are modifying the state immutably and returning it.

[00:01:33]
What if we just had the entire reducer go through Emmer, right? That would work, right? We can just like, cool, pass the state and the action in, let me do my thing immutably and then figure it all out at the end. We can totally do that, the syntax is a little bit different, so let's talk about it.

[00:01:49]
Here, in this case, we are immediately giving it the state, and then we are mutating it and it's applying the mutation. We can also use produce to create a function that will automatically pass it into Emmer. It's just the syntax is a little bit different with the curried function.

[00:02:08]
So let's just take a look at what that might look like for us. So we'll actually, we will say produce, In this case, and we'll wrap the entire function, but then as the second argument, it will take some kind of initial state As well and this will return a function that we can use as our reducer.

[00:02:32]
I called it initial items, hold on. All right, so we've got that in place. And now we just need to do really at this point, we're just simplifying, we don't need to wrap everything and produce anymore. So state is going be effectively that draft state at this point.

[00:02:49]
So we can go ahead and reduce a lot of this. We could take all that out. This is now state. This one can stay, if you return, it'll actually work as well. We can get rid of this. Now this has become state as well over here over here.

[00:03:17]
We're gonna basically just treat it as if this entire time, everything we said about mutability wasn't the case. And we don't even have to return state cuz this will automatically, it's gonna apply this stuff anyway. So it'll actually take care of that fallback for us as well. Let's go try it out to make sure I didn't make any obvious error.

[00:03:39]
All right, everything loads. Item price updated, let's see, but it seems, got a little bit of an issue. EUID price is 14, we got to do that percent or not. Coming in there as well, let's see. 143, 13 but we're loading in slightly wrong.
>> You're reversing the EUID instead of [CROSSTALK]-

[00:04:09]
>> Good catch, that'll do it because the EUID of that one was one. So in this case we'll do price. In this case we will do quantity. Yeah, so we'll find the right item. And we'll refresh and there we go. Now everything works as expected, right? So this becomes a much cleaner syntax, and it becomes easy to correct.

[00:04:36]
If we had this one nested object, we can just treat it like we could work down. Now be clear, this solves for the tedium with immutability and creating new objects as you go through. However, it doesn't necessarily save you from the fact that even if you have a deeply nested object and any one of those becomes undefined.

[00:04:56]
You either need to check all the way down or use some of the new operators that will return undefined if anything in the entire chain. And sometimes yes, that will save you from your app blowing up. But it might also not be what you wanted. The flatter you keep your data structures, not just for the tedium of writing immutable updates to your code.

[00:05:15]
The advantages to keeping your flat data object is it's just also easier to maintain. So I would say use this in conjunction with normalizing your data and figuring out a data structure that works for the UI you're trying to build. But this is a another way on top of that to also reduce the amount of boilerplate and tedious code that you need to write.