I'm strictly against putting actions and selectors together. This goes completely against CQRS or NgRx's design. In fact, this is actually one of the reason why the NgRx team is not really happy about facades. They have seen these kind of "misuses" quite often.
Hi, do you mean you want to mock the complete NgRx and only the class with the facade? Then you would have to use the mocking features for NgRx: ngrx.io/guide/store/testing
Hi, great video again! I'm using createActionGroup method to organize actions from the source which uses them. This way, different actions can lead to the same effect like calling the loadCustomer method from a service for example. This is where I'm struggling with the facade pattern... How can I implement the customerFacade? Do I have to implement several methods like fromPageXLoadCustom(), fromPageYLoadCustomer()... in order to dispatch the right action? I mean that I don't want to loose the origin of each action for debugging purposes.
I see, you are the action hygiene. So you have one facade method per action. If you have multiple actions, then you also have multiple methods. As a side note: If you have multiple actions just for debugging purposes, why don't you add {context: string} property to the action's payload. Saves the the same purpose. On the other side, if you have different load actions, stick to what you have.
@@RainerHahnekamp Thank you for your reply! So It seems that using createActionGroup method and a facade service is not really appropriate. The source property in createActionGroup method is the interesting property (as well as the organisation of the actions of course) and unfortunately we can't benefit to use it.
Thank you for the high quality Angular/Spring content, good stuff. I have though a question, it is not really related to the topic of this video. In the code example that you provided the shared directory, you put services with 'providedIn: root' inside the decorator, is there a reason for that ? Because usually Singleton services lives under core. What do you think ?
You mean why I use providedIn: root? If I wouldn't do that, then somebody else would have to provide that service. Otherwise I can't inject it. That somebody else might the AppModule, the providers in bootstrapApplication or I provide it locally on the component level, which is something I usually don't want to do. If you provide the service locally, then the services gets destroyed together with the component. You should also try to avoid providing the services via an NgModule (if you still have them) or bootstrapApplication because tree-shaking will not work them. If there's something unclear, please let me know.
@@RainerHahnekamp According to Angular Style guide, Singleton services that are shared across the application should live in CoreModule. Well, I understand in your example that core is rather just a namespace/package boundary holder and no module there. I completely agree with what you said about the usage of 'providedIn: root' flag, but that was not my question. The question is: Shouldn't we put those services in core instead of shared namespace ?
@@bjeouisaber2391Ah, now I understand what you mean. So you can of course have one place where all your main services reside and call that core. It should be a separate module because you want that both the AppComponent/AppModule and the rest of your application can use those services. The larger your application grows, the more you want to divide up your core services into different sub-modules. If you now rename those core sub-modules to "shared" you end up exactly where I am. Does it makes sense or do you see something that differentiates the core from the other shared modules?
At 7:58 you are importing CustomersEffect using a deep import path (using tsconfig path). Which brings me to the questions (1) is this on purpose or just a result of WebStorm auto-import? Also (2) Do you think breaking the customers domain into ui + data "libraries" would make sense if the data were to be shared with another module (eg. dashboard)?
Hi, so the deep import is alright and can only be done like that because both files are part of the same module. If an NgRx feature state is required by other domain as well, you have two options. You move the feature state into shared and make it therefore a "shared feature state" that can be accessed from everywhere. If you want to limit the libraries, for example only domain dashboard is allowed to access the customers feature state, you need to do more. You have to create an API module and setup the dependency rules so that only dashboard can access that customers-api. You can find a working example for that on github.com/softarc-consulting/sheriff/blob/main/test-projects/angular-i/src/app/customers/api/index.ts
You can remove webstrom left margin while in distraction free mode by going to settings>advanced settings> there is a line named Left margin in distraction free mode. Change its value into 0 and apply settings.
Hey! Thanks for the compliment. Planning to come up with more videos. For Angular, I'm currently planning a Signal video und a generic one about Playwright / Cypress. There will definitely be one about architecture, when I start creating one about the sheriff project.
Hey, very insightful video! I have a question, I've previously read that the facade shouldn't have business logic, what do you think of that? I was thinking that if I have a facade for a component, and is not meant to be consumed by any other component, why not having some business logic in it, that way the container component doesn't have to handle too much.
Thanks and yes: Try to move the logic into NgRx if you can. In your case, when you say that you have just one logic for one component only, then maybe the NgRx Component Store is what you want. It allows you to provide the State only for the lifetime and exclusively (i.e. provided) for the component. Also check, if you actually need NgRx for your use case. Maybe, everything you need is just a single service.
@@RainerHahnekamp In the actual application I'm working on, we use behavior subjects instead of NgRx. There's a particularly large container component that needs to be broken down (but that's a different story), where a lot of the business logic is handled. I've been considering moving much of this business logic into a couple of facades for specific tasks. Following your customer example, I'm thinking about extracting all customer-related business logic into one facade, and all product-related business into another. These facades are meant to be used exclusively by this component.
@@Yadiel458x Ok, ok, I see. Yes that makes sense. I wouldn't call it Facade then anymore but that's not that important. The main thing is that you extract your logic into services.
