Reactive Angular, the Facade Pattern, & the Subject Pattern

[00:00:00]
>> We're gonna start with a standard component service combo. And I'm going to venture that at some point everybody has seen a component that is injecting a service and it's pulling data, basically it's calling the server into the service into the component. I know you've seen this, because this is what I've been doing up to this point.

[00:00:27]
And so you have this kinda typical component that is pulling in a service and then it's just calling or making these calls out via the service to do something at the server layer. And so what we wanna do is we want to introduce a facade to decouple that component from the implementation details.

[00:00:59]
So I'm gonna back up one slide. The problem with this is that the component has some knowledge of where the data is coming from and how it's being fetched. Now this is a fairly simple example, but the implementation details are still leaking into the component. Being that you have essentially coupled this component to this service.

[00:01:37]
And if you ever needed to change that service or change the way that you handle your data fetching. You'd have to entirely rip it out of the component. And by creating that separation, now you are decoupling or creating, abstracting the implementation details from the components. So what you can do now is you can expose state from the facade directly into your component.

[00:02:17]
So in this case, we're saying we have all of our widgets and selected widget and then we have mutations. Then, and so this is where we have a service with a subject. And we're saying allwidgets is a new subject that is of type widget array. And then we're exposing that as an observable stream by saying allwidgets = this.allwidgets.asobservable.

[00:02:52]
And from here, what we can do is, When something comes in, and we want to propagate that on the subject itself, we can call next and we can pass that data in. So when you're dealing with an observable strain, I'm going to keep this very tight very condensed.

[00:03:21]
Is that an observable stream typically has three events. It's next, error, and complete. Why do we care about observable streams is that when state changes in your application, how do you know about it? Well, previously, you had to resort to callbacks, or at some point people realized that the observer pattern was pretty good.

[00:03:44]
And they started using a venting. And so this is actually what I did in the old AngularJS days, is I simply use route scope as an EventBus to communicate like hey, the state changed you need to rehydrate yourself. Well, an observable stream, when you have a subject and you expose the portion that's the observable stream.

[00:04:06]
When you call next on the subject it's going to take that data and it's going to emit it to any subscriber that is subscribed to that stream. And so observable streams are very, very powerful for communicating state or data from one place to another in conjunction with the event that caused it.

[00:04:32]
So again, complexity is what? State management, control flow, and code volume. And so by having an observable string, you kind of tackle all of those in one fell swoop. And so here at when you select a widget, we're able to call this selected widget.next and pass that in.

[00:04:53]
When we get new widgets, we're able to say this.allwidgets.next(widgets). Now you'll notice here that when we call reset, is we're just creating a simple stream called mutations. That if we wanna reset, we just pass true into the mutation string. Now, what this allows us to do is achieve essentially remote server communication by calling or taking this right here.

[00:05:24]
And instead of the widget service, and we're saying okay I wanna call this and I wanna handle this. That you're able to separate this. So let me back this up real quick. That in here we are from the component, communicating to the server. Like I want you to do this, and then we're waiting for a response to then do something.

[00:05:53]
So what's interesting, not only are we worried about how we're going to communicate to the remote service, but we're having to handle the control flow around that. And so the difference is in a reactive component, what we do is we one, we subscribe to the data that we want.

[00:06:21]
And when something happens like a mutation, we just listen for that and then we just say, hey, if we've created, read, update, delete, whatever. We're just going to reset that. And then when we want to get our data, then we just call it from the facade. So notice here, this is one thing that I really want to call out.

[00:06:47]
Is that what do we notice about this reactive component versus this non-reactive component? I'm gonna just pause for one second. And notice that in createwidget, updatewidget, deletewidget, we're having to handle the response. In the reactive component, we are simply issuing the command. So this is a separation between command and query, this is a fairly common concept.

[00:07:29]
Is we're taking and we're separating the command portion of the code from the query portion of the code. And we're saying, we're going to segment this in a way that we're able to essentially issue commands to our facade. Selectwidget, loadwidget, updatewidget, createwidget, is not waiting for something to happen.

[00:07:52]
It's just issuing a command to the facade and delegating it, truly delegating it. It's the same time when we need our data or we wanna consume it, all we're doing is we're subscribing this is the query portion to the data that we make available in our facade. And so now what's interesting is if I go back to this, Ironically, this block of code here, specifically the last three elements, allwidgets$, selectedwidget$, mutations$.

[00:08:41]
These are outputs from the facade into your component. And so now it's just kind of like Legos, facade, output, container component, output into a presentation component. So this is defining the outputs or the queries that are available from this facade. This is defining the command portion. And so inside of the facade, we are saying, do this thing.

[00:09:12]
And so when you select a widget that it's calling selectedwidget next. And it's just passing that along, that's the command. But then it's updating selectedwidget$. So I think I mentioned this, but when you have an observable string, the convention is to put a $ on the end of it to indicate stream.

[00:09:32]
More money you ever thought possible, I don't know, but that's the convention. And because it's basically a data type that's wrapped in an observable stream, and that's how that works. So now you have this reactive component that in the first two lines, this is all the data fetching it's ever going to do.

[00:09:53]
Is it's just basically saying, give me the widgets, give me the selectedwidget. And with the exception of the mutations is that we're just using this to reset. And then from here we are issuing commands which then allows us to write reactive components where we are just taking that stream.

[00:10:17]
And instead of subscribing and unwrapping it, we're just dumping it right into our presentation components, and that's it. We're just taking it right from the facade and just piping it right through the component, into the container component, into the presentation component. And so this is the facade pattern with using a subject within the service.