Reactive Angular Q&A

[00:00:00]
>> I have a question. How will you do with custom error handling for any of those API's for example?
>> So the question is, how do I handle errors custom error handling within like the API's? Is that correct and so typically if I were to stop at the façade or a service with a subject, I would handle it there.

[00:00:29]
But with NgRx, I would then handle it within the effect itself. So it moves just a further up the chain a little bit, but the idea is that especially if you're dealing with a service or remote service, you want to handle the air is close to where it happened as possible.

[00:00:47]
So even what I would actually do. Again, this depends on where do you handle the air? It depends. So I did a long contract with a fortune 100 financial institution. And they had a number of errors that were caused by any variety of things. Is it a 500 server error is your server down?

[00:01:19]
Or did the user put their verification code in Rob? And so to say, where do you handle errors? There's no blanket, just handle it here and you'll be totally fine. Cuz it depends on what is the nature of the air? Where did it originate from? And what can you do about the error?

[00:01:41]
Like, can you recover from it? Or like, for instance, is it a retry? Do you need to timeout? Do you need to retry? Or does a user have to intervene and do something? And is it possible that you could expose sensitive information by surfacing that error? And so, what you can actually do, and I haven't mentioned this yet, is you can handle the air, at let's say the effect, or even at the service, so I could very well, go into my code and let's go into my service.

[00:02:25]
And I could handle the air right in this service. And so this is the angular service that's calling and I could write from here. Subscribe or basically pipe through and just actually what I would do is I would add a pipe to it and I would say on air do this thing.

[00:02:46]
And so you can handle it right there. If you're on a spotty connection you want to retry, no problem. I would say that so you can handle it here, but then you can actually pass a new observable stream down the pipe, if you will, and handle it. It like the effect handle it there.

[00:03:12]
So now you need to maybe reset some application state, then you need to handle it at the component level. So, in some ways, I've kind of been framing of this, you can handle it here, or you can handle it here, when really the true I think approach is you can handle it here and here and here.

[00:03:34]
And you do it to optimize really the user experience and what's in the best interest of the client. Did that make sense?
>> Yeah.
>> All right. I feel like sometimes he signs up for like a 15 second answer, and instead he gets a three minute jumbo answer, if not more, so.

[00:03:56]
All right. That was a really good question. Mark, what do you want to know about facades?
>> Can facades be combine with the NgRx? Usually, at the NgRx architecture services are in the effects and what the current imp mentation are in the facades.
>> So the question is how can facades be combined with NGRX?

[00:04:26]
And because currently I have a façade that's interacting directly with a service and with NGRX, the façade or with NGRX, rather that service Interaction happens at the effect layer. And that is actually a very, very good question. And the answer is facades work very, very well together. This is my default pattern I'm actually probably going to generate.

[00:05:03]
>> So NGRX here after the break, I don't know if I'm going to wire it all up, but at least want to show you kind of the shape of things. But remember, a façade ideally should be nothing more than a delegation layer. So now. In NGRX, how do you communicate that something has happened?

[00:05:33]
It's an action is you dispatch an action. So now just imagine you're just extending that delegation. So in your façade. Instead of handling it right there. Also now your facade gets really thin because it's like load widgets. Well, from there, it's just this dot dispatch, load widgets, the action object for that.

[00:05:56]
And so from your façade, you're just delegating further down. And so this delegation just goes further down the stream and.
>> Now when you make an asynchronous call, which happens in an effect, the result of that, let's say it's ideally successful, is that what happens like when you reach an effect?

[00:06:22]
How does it get there? Well, you have an action coming in It does some asynchronous operation, and then you have an action coming out. Normally, that action object goes into a reducer, which then updates state. And how do you know that state has changed in NGRX via a selector.

[00:06:50]
And so I've actually just given like NGRX like 2.0, and like three minutes, and it actually turned out pretty well is that you're selecting or you're querying data from the store via the selector. So now your façade Is doing two things. It's querying data via selectors. I really wish they would have called them queries like I just think that would have made a lot more sense.

[00:07:17]
Because I just think of it as like, really, if your store is like a database then I think that really your well, if the stores, your database and your reducers are tables, then you're essentially you're clearing your specific table and say, give me the state of model. And that would be a selector.

[00:07:39]
I think you could have called it like a query, but you're pulling that into your façade. Then when something happens, you're just dispatching that the inaction. So, at the end of the day, it's just inputs and outputs. And you want to move that is far away from your component layer as possible.

[00:08:05]
And so what we see in here to what we will see in just a moment hopefully, is that all I'm doing is taking what I've done, and I'm continuing to refactor that through promotion, To where the stuff that's in the façade, starts to be moved out, into the NGRX layer.