00:00 So this time, I'm actually not going to change this right away because we're going to be moving this logic. So I want to handle those use cases first, and then you can see how we just are moving logic. So our action is actually going to be pretty different. It's no longer going to accept the state at all.

00:16 And instead, it's going to have two different types. We'll have type increment and type decrement. I think in the example before, I had this all caps, and it doesn't really actually matter. It's just some very defined value there

00:33 that's unique across all the different action types. So in any case, each of these is going to accept a step. So the amount that we want to have incremented or decremented. Now, we need to update our reducer to handle that action type. And so let's come over here.

00:51 And actually, I'm going to multiline this thing. We don't want to do this all in one line anymore. So we're going to switch on the action type. I'm going to actually grab the type and the step from the action. We'll switch on that type. And for our first case, we'll go with our increment case.

01:09 We're going to return a merging of the state that we had, like we were doing before. But then our logic that we had before, that's going to come up. So we'll come here, say count is whatever the current state is. So state.count plus the step. So we're taking all of the properties from state,

01:28 merging those with our count. Now, again, our state just has a single value or property in this object. But merging these states together is pretty typical. You're going to have multiple elements of state. You're like, yeah, I don't care about the other ones. Just keep them along. Here's the one that I'm changing,

01:48 or here are the couple that I'm changing. So that takes care of increments. And then our AI assistant can probably help us with the rest of this one. We're going to take that logic that we had down here, move that up here. And now, with this, we don't need to worry about the default case, because TypeScript is saying, hey, it could only be increment or decrement.

02:07 There's no default case anyway. So we're not going to even bother with that. OK, great. So we've got our count reducer, which I'm going to change to a named function, since we're not doing an immediately returned function or an implicit return arrow function.

02:26 I just like function declarations. Sue me. And now we're going to change set state to dispatch. And now, instead of having this logic right here, we're just going to say the type is increment. And here's our step. And we'll do the same with this. Type is decrement.

02:48 And here's our step. And so now, there's actually no logic going on in here. We're just passing an action. And all the logic resides in our reducer here. And so that makes it really easy to debug. Like, why is this happening? Who is dispatching these events? You put a debugger in there. You can step back.

03:07 Yeah, all of this stuff can help a lot as we are building increasingly complex components with increasingly complex state management needs. Having these actions spelled out and the different cases

03:26 handled makes this really nice. If it gets really complicated, you could test this in isolation. I've never actually done that, because once it gets that complicated, I'm usually using xstate. And then it's a totally different thing at that point. And you're testing that in isolation and stuff.

03:43 But some people do like to be able to test this in isolation. And I can appreciate the value there. And yeah, you definitely can do that. So there is your typical reducer. You've got your state. You've got an action with the type property. But you know that there are so many other ways that you could write this reducer. And so your brain is unlocked.

04:03 And you can write however it makes the most sense for what you're building.