Optimistic UI Updates

[00:00:00]
>> Alex Okrushko: Let's inject it. So we're going to read this data in our header. In our head. So in our header, we're going to read that data. So this is where we can... We'll do I'll read only count. And we can do this, oh no, not this, and just do inject. Inject, um, is it cart service. And we can just get count directly out of this.

[00:00:43]
So this is a signal, this is a signal. Because if we don't use the service multiple times, we just don't need to assign it to a specific variable, can read it directly. And then, you know, the only difference here is we'll have our count immediately here available to us. In this case, I made this service public, so I can read the data directly, either one works.

[00:01:18]
So, okay, let's check again. So what do we have now? Now we can see that the tickets API is called as well. Right, and we just don't have any data back, because our database here is still empty, we don't have any tickets. We have some workshops, but no tickets yet. All right, but we see it's working now. All right, tokens.

[00:01:59]
All right, let's get back to our header, okay, so now, what we're going to do in the next thing, we're going to add to our cart service the ability to add the tickets. I'm going to go to our cart service. We're going to create an basically a method. A ticket. I will have the event ID for it. So this one, we need to be a little bit careful about because we're, remember, we're adding this optimistically.

[00:02:36]
So before we can just send the request, we want to update our tickets locally. I'll first we'll just give a snapshot of our previous tickets. Just in case we need to roll them back. So, there's tickets IDs, right, now, this reads the data of the signal, just like as a precaution if we need to update. Now, before we send the API we'll update our tickets.

[00:03:13]
And again, this is because this is just a signal. It has the update function, right? We can use the previous tickets IDs. And what we're going to do is we're going to spread that array, right, because we're not going to create a new instance, have all those previous ones. And we're going to add the new one that we are passing as well.

[00:03:39]
This way, when we click the buy, you'll automatically update this and then kind of see the count immediately. Now, we also need to persist it to the backend. So we're going to do this HTTP client, we're going to use HTTP client, we're going to be posting to that URL. And this was going to be our ticket URL. Cool, and I'm going to be posting this event ID object, so event ID is basically event ID.

[00:04:22]
ID, right? Event ID ID if it's the same value and the property, the shorthand would be just have one, so I'm posting this object. Internally, it will add this object to the ticket array. And then it will assign the ID for this specific update as well, right? All right, so, but again, this is the observable, which doesn't do anything unless we subscribe.

[00:04:58]
And we need to subscribe, because if we have the next. Everything's fine, we can just, whatever, just a console log that everything's fine. Like optimistic update was successful. Right. So that's if everything's good, but we're not really interested in what's good, it's what's not good here is really important.

[00:05:33]
So if we have some kind of error. For this, we need to do a few things. We can first of all console log console.error, the error first. Like sync failed. Failed for and then I can just say event ID here or something like that. And then, what we need to do is we need to restore the previous state. Previous dates, so we need to get our tickets back, which will update the count.

[00:06:10]
That's what I was going to ask is when do you update the header, the new count. So the beauty here. And this is the beauty of reactive model in general, be it observables or signals. Hatter does not care about all these things, doesn't care who's changing things, we're updating things, we just expose the reactive property for the consumer to listen to.

[00:06:36]
And it just. Hey, whenever this discount signal changes, whenever it gets the new value, doesn't matter how it gets the new value, it'll just update the template. Which is really powerful. So, let's now add this add ticket functionality to our event, this is will be event details. In our event details now when we want to buy this ticket, that's when we want to call that thing.

[00:07:21]
We have already event service, let's just add another service. Will be cart service. And we're going to inject the cart service here. Now, when we click this button, that's when we get out. Add a ticket, so I will just say um, that ticket. I'm going to pause, I'm going to do this event ID we have event. Yes, event resource, event event ID, yes.

[00:08:07]
Oh, yeah, we have ID here as well, so it's not really needed, so I'll just say, hey, he added a ticket. And then we can implement this method here, add ticket. This cart service, add ticket. And we're going to pass the this ID to it. I noticed I hear we don't need to subscribe. Because what we're doing with these type of methods is in action.

[00:08:42]
We're telling it what to do. But then we read the data from some state. In this case, this card service is the stateful service that keeps track of the ticket ID state. There are pros and cons for services to be stateful. We're going to describe and look into alternatives in the advanced course, but just to be aware that this interaction is really awesome, because again, your hotter component does not care who's changing the state, even though right now we're changing it optimistically, it could be even the pessimistically so post updates, but the beauty of it, it doesn't matter which component because what if say if you can buy this ticket from different places and destroy the tickets, delete the tickets from all the through entire application, right?

[00:09:40]
Your account does not really care, it's just tracking the current state. Super powerful. All right, so let me make sure that everything we have here, yes, that's what we do here. Cool, buy a ticket add the cart. I take it, it's fine. Same idea, cool. And we actually, we updated the event service already as well, we injected this API URL, good, good there.

[00:10:22]
So let's see it working. So, I'm going to pull this clean, so we can see, we can buy a ticket, see it's immediate. Is that cool? I can do this. I can do this, not to, there is issues with that, which we're going to talk about in the advanced singular. Yes. So is this sort of like a modern replacement for like, what do they call service with the subject.

[00:10:52]
Yes, surface of the subject is basically the same idea, where you have a reactive subject that you were exposing with as observable, so you cannot touch the subject. And you have computed, it is a modern take on that, for sure, serves with the subject, yes, serves with serves with the behavior subject because that one tracks events over time even better with the default value.

[00:11:30]
Which kind of what we have. There are some issues with this. With the system, so let's see what the issues are, could be. So say we have in our service, we're going to, we need to see the rollback, right? That's what we want to see. So if we have the card service and say I messed up my URL here. I just have more things to this.

[00:12:07]
Now, our sync will fail, and if we're careful, we have 16 tickets now, we can buy another one, 17. Boom, it's rolled back. That's awesome, right? There are little issues with this, which, let me just do a little teaser. Yeah, but all he has is body, there's no, there's no, how do you get rid of it? And we probably didn't roll back to initial state.

[00:12:36]
So, there are certain things which we cannot control exactly with this approach. We can again do some workarounds, but there are certain things we cannot control with this approach. It's really great and we will make it work during our advanced Angular approach, but as it is, and super powerful, if you're careful if your users are doing one thing at a time, awesome.