Deine Videos sind der Hammer. Deine Arbeit bringt meine Skills wirklich auf's nächste Level. Vielen Dank!!! Du bist in meinen Augen zusammen mit Manfred Steyer im deutschsprachigem Raum der Angular Papst. :) VG und vielen Dank!!
One thing to Note from my experience on our current project: Using selectors for config is a good idea EVEN when you do not save or load the config or even have them in the state yet. This allows you to write "Dummy" selectors and later Refactor them to actually read from state and you may add Server requests for that config. In out App the example is that we skipped all personalization of things like grid columns etc for now but may store these things in a User database later. We already select the defaults via a Dummy selectors so later we can easily Refactor all bits behind it and the components will just work.
Hi Jacques, thanks for sharing your experience. I think what you describe is also know as the facade pattern. So you have a central service that exposes a selector and disguises the usage of ngrx. If you don't use it yet but integrate at a later stage, you only need to make changes in the service and all the rest of your application can stay untouched. Did I understand you correctly?
@@RainerHahnekamp Well it is true that we use the facade pattern a lot in our Angular project. But it isn't only that. What I meant here was that we actually read information that is currently static using selectors that locally define and return data. Of course, we could also define these static things in the initial state of the reducer, but then the separation of concerns would be weaker. So regarding my example, we have a definition of columns that are displayed in our data grid. This definition of columns could come from the server later on or it could be in the local storage or whatever you can think of. Instead of locally defining this data in a component, facade or service, we define it in a selector. It's just a feature selector that returns data that never changes. This has - at least in my opinion - some major benefits: 1) the fact that the definition is static for now is no problem in a selector, it could easily come from state later on 2) when a developer sees that the data comes from a selector, they tend to accept that this data could potentially change, which increases the chance of a robust component design, since you expect that data coming from a reactive source will always be treated as potentially dynamic at runtime. 3) having nothing more than a selector keeps the app absolutely unopinionated towards a later solution regarding the source of the data. You can have it in your API, write effects, put it in the store and you can do this however you want. I really like this approach. Sure, the selector will later be refactored, but nothing outside it will ever change.
@@jacqueskloster4085 ah, ok, now I understand what you mean. I've never heard of this pattern before, but it sounds more than reasonable. One last question, which type does your selector produce? Do you map it to an Observable or do you keep the original one?
@@RainerHahnekamp well, it's a regular selector, so it returns my defined array of ColumnDefinition and it is used via Store.select() just as any other selector. It just doesn't access the state at all internally ;)
@@RainerHahnekamp In the end, my original post was just a remark about how you can use ngrx even when you have aspects in your app where there is no definite design decision yet. In our case, we decided to skip all personalization related features, but I still introduced settings related to personalization to the app. It's just that they are never stored, never loaded, just hard coded inside a selector (well, in reality it's multiple selectors as the topic spreads widely across different settings). Partially, they are actually already in the state and are just defined in the initial state. I think both can work and it is more about whether or not something needs computation, since the initial state is rather a serializable object than a function like a selector. You don't even have to think too hard about the state shape when you have no decision. Using a selector works self contained as a starting point here. As long as you know what your consumers expect, this is a good approach to keep the app free from clutter and actually have a good pre-design/YAGNI balance.
Hello Anton, I'm happy that you liked my video. Full-Stack videos are definitely in the pipeline. One of my upcoming ones will be on how to to build an OAuth2 authentication with Angular, Spring & Keycloak. But it will be without nx.
Great introduction, I'm learning a lot from this series on NgRx.
Thank you very much Hugo. 👍
Deine Videos sind der Hammer. Deine Arbeit bringt meine Skills wirklich auf's nächste Level. Vielen Dank!!! Du bist in meinen Augen zusammen mit Manfred Steyer im deutschsprachigem Raum der Angular Papst. :)
VG und vielen Dank!!
Hallo, ja vielen Dank für das super Kompliment 😁. Das ist natürlich gleich ein ordentlicher Motivationsschub. 👍
One thing to Note from my experience on our current project:
Using selectors for config is a good idea EVEN when you do not save or load the config or even have them in the state yet.
This allows you to write "Dummy" selectors and later Refactor them to actually read from state and you may add Server requests for that config.
In out App the example is that we skipped all personalization of things like grid columns etc for now but may store these things in a User database later.
We already select the defaults via a Dummy selectors so later we can easily Refactor all bits behind it and the components will just work.
Hi Jacques, thanks for sharing your experience.
I think what you describe is also know as the facade pattern. So you have a central service that exposes a selector and disguises the usage of ngrx.
If you don't use it yet but integrate at a later stage, you only need to make changes in the service and all the rest of your application can stay untouched.
Did I understand you correctly?
@@RainerHahnekamp
Well it is true that we use the facade pattern a lot in our Angular project. But it isn't only that. What I meant here was that we actually read information that is currently static using selectors that locally define and return data. Of course, we could also define these static things in the initial state of the reducer, but then the separation of concerns would be weaker.
So regarding my example, we have a definition of columns that are displayed in our data grid.
This definition of columns could come from the server later on or it could be in the local storage or whatever you can think of.
Instead of locally defining this data in a component, facade or service, we define it in a selector. It's just a feature selector that returns data that never changes.
This has - at least in my opinion - some major benefits:
1) the fact that the definition is static for now is no problem in a selector, it could easily come from state later on
2) when a developer sees that the data comes from a selector, they tend to accept that this data could potentially change, which increases the chance of a robust component design, since you expect that data coming from a reactive source will always be treated as potentially dynamic at runtime.
3) having nothing more than a selector keeps the app absolutely unopinionated towards a later solution regarding the source of the data. You can have it in your API, write effects, put it in the store and you can do this however you want.
I really like this approach. Sure, the selector will later be refactored, but nothing outside it will ever change.
@@jacqueskloster4085 ah, ok, now I understand what you mean. I've never heard of this pattern before, but it sounds more than reasonable.
One last question, which type does your selector produce? Do you map it to an Observable or do you keep the original one?
@@RainerHahnekamp well, it's a regular selector, so it returns my defined array of ColumnDefinition and it is used via Store.select() just as any other selector. It just doesn't access the state at all internally ;)
@@RainerHahnekamp In the end, my original post was just a remark about how you can use ngrx even when you have aspects in your app where there is no definite design decision yet.
In our case, we decided to skip all personalization related features, but I still introduced settings related to personalization to the app. It's just that they are never stored, never loaded, just hard coded inside a selector (well, in reality it's multiple selectors as the topic spreads widely across different settings). Partially, they are actually already in the state and are just defined in the initial state.
I think both can work and it is more about whether or not something needs computation, since the initial state is rather a serializable object than a function like a selector.
You don't even have to think too hard about the state shape when you have no decision. Using a selector works self contained as a starting point here. As long as you know what your consumers expect, this is a good approach to keep the app free from clutter and actually have a good pre-design/YAGNI balance.
Great video! I would love to see how you would set up and structure a full stack nx project from scratch, is that something you have in the pipeline?
Hello Anton, I'm happy that you liked my video. Full-Stack videos are definitely in the pipeline. One of my upcoming ones will be on how to to build an OAuth2 authentication with Angular, Spring & Keycloak. But it will be without nx.