Indirection design pattern12/26/2023 ![]() Con #1: Facades break the indirection of NgRx. This reduced friction in development and scaling really sound great, but is everything a bed of roses? Let’s take a look at the other side of the argument. "Using facades in NgRx can increase dev productivity and make apps easier to scale." The seven new features could then be added quickly while letting the facade worry about the underlying NgRx pieces. Finally, we'd appropriate methods and selectors to our facade. ![]() Next, we'd add them to the right places in the application-wide NgRx setup files (like changes to the application state or reducers).First, we'd determine the smallest number of state changes we need to make based on unique use cases.We could cut out a lot of repetitive work by using facades: Several of those features would probably overlap in some of the ways they affect the state of the application, as well as in the data they consumed. Let’s say, for example, we needed to develop seven new features for a large application. The second argument for the facade pattern is how easy it is to scale. Frosty OctoPro #2: The facade pattern is easier to scale than plain NgRx. It feels much cleaner than with a store by itself. It becomes the interface for the components and the store. For example, a new developer writing a new feature listing books could just inject the BooksFacade and call loadBooks ( ) without needing to worry about learning the intricacies of the store.Ī facade wraps the store up, and allows your component to only know about one thing, the store facade. By adding a layer of abstraction through the facade, we decrease the need to directly interact with these pieces. Every feature requires changes to state, the store, actions, reducers, selectors, and effects. NgRx often gets flack for requiring a lot of repetitive code for setup and for the difficulty of maintaining and scaling a lot of moving parts. One of the biggest arguments for using the facade pattern is its boost to developer experience. Pro #1: Facades provide a better developer experience. Let’s first consider some pros of the facade pattern for NgRx. So, is that a good thing or a bad thing? Let’s talk about some pros and cons to this approach. Looking at the component code in isolation, you’d have no idea that this Angular application is using NgRx for state management. Here’s the BooksPageComponent from the sample code for my NgRx Authentication Tutorial (I’ve hidden the code inside of the Component decorator to make it easier to read): // src/app/books/components/ import Let’s take a look at an example to understand this better. ![]() This diagram illustrates the relationship between the component, the facade, and the rest of NgRx: When a component needs to dispatch an action or get the result of a selector, it would instead call the appropriate methods on the facade service. A facade is basically just an Angular service that handles any interaction with the store. This was sparked by an article by Thomas Burleson called NgRx + Facades: Better State Management. Recently, there has been a lot of discussion about whether or not to use a facade with NgRx to hide away bits like the store, actions, and selectors. They simply call doSomething ( ) and the facade handles working with the services behind the scenes. You can see here how the clients don't know anything about the other services. Here's how the facade pattern can be represened in a diagram: You don’t need to care about the underlying mechanics of the engine or the science of combustion in order to go to the grocery store. You only need to know that when you turn the key and press the gas pedal, your car moves forward. The facade pattern, and abstraction in general, is similar to the relationship between you and your car. You’ll often hear this hiding of complexity referred to as “adding a layer of abstraction.” An abstraction is a simpler and more general model of something that only provides what its consumer needs to know. Just like the front of a building hides what’s inside to passersby, a facade in code hides the complexity of underlying services by only exposing certain methods. ![]() In code, the term “facade” refers to the facade pattern, which is a structural design pattern from the famous book Design Patterns (usually called the “Gang of Four” in reference to the authors). Even though I know by looking at it that it’s Buckingham Palace, I have no idea what’s inside - and those guards are there to make sure I don’t find out. I took this picture of the facade of Buckingham Palace when I was in London this November. (You can find the sample code in this repository.) What are facades? Let’s learn what facades are, the arguments for and against them, and how to implement one. I thought it’d be a great idea to write an article to talk through this issue. You may have heard recently about a topic whizzing around the Angular community: facades in NgRx.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |