Check out a free preview of the full Reactive Angular with NgRx course

The "Facade Rationale" Lesson is part of the full, Reactive Angular with NgRx course featured in this preview video. Here's what you'd learn in this lesson:

Lukas explains use cases and why the Facade pattern may make sense for an application.


Transcript from the "Facade Rationale" Lesson

>> Lukas Ruebbelke: So the use case for this is if you have a legacy. Or an [INAUDIBLE] application that's not using ngrx. It is kind of as you can see. There's a lot of kind of moving pieces that you have to do before you even get to the component. What you can do is create a facade that will stand in place of ngrx and communicate with the facade.

And so that may communicate with your server directly, or whatever. But then under the hood, then you start to replace those pieces with ngrx. And so this is a really good way of, I would love to use NGR racks, but I don't really have the luxury of tearing of the entire floorboards from my application and gutting it and then basically redoing everything.

Because as you can see we've kind of taken the entire project's component, and kind of ripped it out and put it back together. Well now with a facade what you can do is put that in place of NGR rex. Communicate with the facade and then piece it out is you're ready.

There's a situation now where we're doing NGRX, but the backend isn't ready, and so what we're doing is we're simply putting a facade in. We're feeding it in fake data, and our components don't care. And then, so it's a brand new application but as we're building this out and we're waiting for some clarification from the back end, is those pieces are pretty much fundamentally decoupled.

And as we find here's a data concern, is that we simply need to communicate it to the facade and then whoever's working on the other side of the facade. Then it has an opportunity to say, let's work with this. And so now we're just taking mock data, putting it in the facade.

And then once we validate the user flow, then we move that into mock services that we feed into NGRX. And then once we're at that point, then we once the back end's ready, we flip the switch and we're good to go. But by creating those layers of abstraction, what you can do is when we want to test the application, because we've already built it out with a mark back end, a mark data set.

Is that for instance when you wanna do [INAUDIBLE] testing that you can do it in a vacuum. We are not doing it against a real server. Is that you're just testing the user flows in by feeding, you know this data into NGRX, which then feeds into your facade.

So it's just a way to create these nice divisions where as you're working on a piece you don't have to worry about the implementation pieces on the other side. And so this is why I quite like facades and where I really got hooked is I realized that I don't have to do this all at once.

I can just, and you even saw how I was implementing this, I'm picking it up and I'm moving it into the facade. It's almost like cut, copy, paste, cut, paste, cut, paste or copy, paste. Once it was there, then I just had to call the facade and it was business as normal.

But then somebody could come along and start to replace those things with NGRX.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now