Request Status Custom Feature

[00:00:00]
>> Alex Okrushko: OK, so now, since we know a bit of how our signal store is structured in this simple example, let's remove this example and let's implement something that will be related for our app. So I'm going to move that to trash. So, we have the cart service, where we already saw that, you know, when we add things, when we buy tickets, they are going out immediately, and we have some race conditions there.

[00:00:39]
So let's fix some of this with a signal store. So first, I'm going to create a new feature, custom feature for Signal store that we're going to use in our store as well. And this is what I've shown like, already, that's the specific feature, and this feature would be responsible for the network status.

[00:01:03]
It's a network call status, request status when they call this. So let's create that. We're going to create it in the core, can just create a new folder, we'll just call it like the store features, they could be reused across multiple different stores we have because they are becoming a reusable piece of logic, store feature, so.

[00:01:33]
Features just to be precise, and then we could call it the request status feature. Yeah, sure. There you go, yes. So what would it do? Again, this will be a simple function here, right, function that we'll call with the request status, and it will help us to keep track of the network requests, so we're going to return the signals.

[00:02:24]
Now our feature helper, signal store feature. All right, let's just have it again. So this is our signal store here, it's just sort of helper wrapper before we can use it properly. So with this one we'll have with state. With state, and this state will have the request status. Our request status are when, when you do API calls are typically in one of the four different states.

[00:03:14]
Export function, sorry, type export type, so our request can be in one of the states, it could be idle, right, so no requests in process. It could be pending and it's loading in flight, it's loading for get, but for post delete, it's pending, right? It's fulfilled, means the request went through and there's already we're ready for new ones, for example, or it could be an error state, but this is again beauty of TypeScript.

[00:04:01]
It matches the craziness of JavaScript. So here we're joining all the strings and an object. There you go. JavaScript can do that, so TypeScript has to do it too and properly type this. So we have like the error message string. Now, the state that this feature will be responsible for, this custom feature will be responsible for, is, will be request our state, request status state.

[00:04:40]
Right, and you can, we've been doing the interface, I can just continue to do the interface interface, up to you what you want to do, but yeah, basically you will have to request status, which is type of this request status, right? So this is our state will be handling this request status state.

[00:05:14]
Going to import with state as well. Now initial state for this would be what, what do you think? What's the initial state for this status? Well, initially it's idle, right? That's what the initial one is. And then we can have a few additional computed ones. So they're based on the actual status, so we're going to extract that status out, request status, request status, and that's request status, we're going to create a few computed properties out of this, for example, is pending.

[00:06:12]
When request status, which is our signal here, right, is equal to pending, then it's pending. It's just like a helper computed, is fulfilled, of course, fulfilled, is fulfilled. Request status fulfilled, and then the error. It's our constant status. So we're going to do this a few things a very interesting way, so I'm going to read the status first and then we're going to return if the type of the status is an object, right, because we're combining this with an object.

[00:07:17]
So if it is the object type, then it automatically narrows it down, see status, it knows that's there, it's the error, and the error alternatively be null. By the way, why did we have to do the status here as a separate? Let me show you why. If I compare the request status here, this request status, which should type narrow, right?

[00:07:58]
But it doesn't. Why doesn't do it? I guess TypeScript doesn't know it's a signal. What if the value of that changed before the first read and the second read, right? So TypeScript treats us as a function. So that's why we need to, for type narrowing, we need to read the value first, right, and write it into something that's solid that it can really compare.

[00:08:30]
So yeah, TypeScript is not aware of signals. By the way, your is fulfilled needs the is in front of it instead of if. Oh, is fulfilled, yes, I mean, it kind of works, is fulfilled, is fulfilled too. We'll definitely use is fulfilled in the if cases. Yes, thank you. Thank you. And you're paying attention, so now we have this, and we have again, we'll just export a few helper functions here, they're pure functions to help update the state as well, I'm not going to type them, I'm just going to paste them.

[00:09:10]
I could have added them as methods as well, but really I could have added them as methods, but we can just, they're just pure change of state, and we can just say, hey, this is a state they're going to change, is our partial updaters, right, so pending, set fulfilled, set error. Those are just, they could have been a methods as well, there could be a method, just easier with the pure functions.