The Facade Pattern

[00:00:00]
>> Let's just do some commentary on reactive Angular, specifically kind of state management. And I wanna introduce two patterns. That is kind of a front runner to what I would say like full on proper state management, which in the angular context, when I talk about state management or if I'm going to do a personally, I'm using NgRx.

[00:00:29]
Now NgRx is a bit of a mind warp. It took me I would say a good five or six weeks of completely fundamentally flipping my entire paradigm on its head about how I thought about applications structure, and how we manage complexity, the estate management, control flow and code volume.

[00:00:57]
And so what I'm hoping to do in the next hour or less, give or take is I want to set, or establish a couple incremental points that you can use to kind of launch yourself out to start to think about proper state management, and really ease that barriered to entry to using NGOrx.

[00:01:26]
Because there are some things that I wish I would have known that if I'd had a few fundamental concepts in place, it would have saved a lot of calls. A lot of very angry, ugly crying calls to Rob Wormald about why his library was so stupid and why he was such a bad programmer.

[00:01:47]
And then, at one point like the light clicked and I realized that like Redux NgRx the most amazing thing in the world. So with that said, I wanna introduce two transitional patterns that I believe are very useful. And I think really set the stage for doing proper state management in your anglar application.

[00:02:13]
And that is the facade pattern and a service with a subject. So reactive angular. Specifically, the facade pattern and even more specifically, a service with a subject. Now, let me preempt this entire conversation by saying that facades are controversial and they can absolutely be misused. So Mike Ryan, who is one of the co-authors of NgRx.

[00:02:51]
So you have Brandon Edwards, Mike Ryan, Rob Rodet, Rob Wormald he handed off to these two wonderful, beautiful human beings, and they're doing an amazing job. This is one point, I would say contention, but we definitely feel differently about this and more so I have to explain what I mean when I say a facade, because you can definitely do a lot of bad things with it.

[00:03:22]
And so, they are controversial, and there's people that just don't like them. I would say the same could be said for a service with a subject. Now, when i talk about facades, they are a pure delegation layer. They should not handle business logic. What a facade is designed to do is to provide a clean separation between components and the rest of your application.

[00:03:55]
So what's funny is just as inputs and outputs, provide an API for your components, a facade provides an API for your application. And so most individuals have no problem thinking of inputs and outputs as like a component API. Think of facades is just an API for your application and you're simply saying, in order for these layers to communicate, this is what you're able to do, you're able to consume this information and delegate these events.

[00:04:32]
What is also important is an excellent, way to incrementally integrate NgRx. So again, if you're Greenfield awesome just start from the beginning go full NgRx. But I have seen a lot of projects where you show up and there's no semblance of state management, and you need to figure out how to introduce this without breaking everything.

[00:05:00]
Like, how do you do this without ripping up the floorboards? Well the answer is a facade. And so not only that is they're great for mocking out a business logic layer. This is not in my notes. But what I found is that when you're working on a team, and you have a distribution between junior developers and senior developers, most junior developers are pretty comfortable working the component layer.

[00:05:29]
And so I will distribute the effort where I will put junior developers on the component layer, they're doing just layout. Then, I will have a mid senior developer essentially write the facade that either provide some mock data or mock functionality for the component layer. Then I will have a mid senior developer on the other side of the facade handle all of the complex, high level implementation details of how do I go get data from the server?

[00:05:58]
How do I handle this complex business logic? Well this is not only a way to your app but to segment your effort in a way that makes sense when you're working on a distributed team with varying skill sets. So that little point didn't cost you anything but if you implement this depending on your team it could actually probably save you a ton of time and money.