I use this pattern, with one difference. In your example, you use filter() to decide whether or not a get action should be dispatched. Instead of this, I prefer to check the loadStatus and dispatch always dispatch an action depending on the status. If it is NOT_LOADED, I would dispatch the "get" action. But if it is LOADING or LOADED I would dispatch a "alreadyLoading" or "alreadyLoaded" action respectively, which will both do nothing. That way your "get" action will always result in a kind of "reaction" that you can see in the redux dev tools. Imho that makes debugging easier. In your example if no data is shown in the UI after a "get" action has been dispatched (and no action afterwards according to the dev tools) it would be easier to see if this is a bug in your effect or in your display logic. For other people reading this: If you need error handling, the loadedStatus can easily be extended with an ERROR state (for example if your API did not respond). When you do this, you can display error messages and also prevent the same call from being processed again or the opposite, process it again because it errored. Some simple form of error handling should always be incorporated, atleast to reset the loadStatus to "NOT_LOADED".
Hi Rainer, thank you for your awesome content. Do you or AngularArchitects have a full example. with ngrx caching and error/succes state aswell? I Found somewhere on Github an example with local storage but I cannot find it anymore. Regards Bram
Hello Bram, we cover that in the Advanced NgRx workshop: www.angulararchitects.io/en/training/professional-ngrx-advanced-state-management-best-practices/ Unfortunately, we don't have a public example available, but I can recommend you to checkout these two sources: - github.com/btroncone/ngrx-store-localstorage - timdeschryver.dev/blog/keeping-browser-tabs-in-sync-using-localstorage-ngrx-and-rxjs
Hey, I'm not sure if CRUD + Pagination is enough for a complete video but I can answer specific questions, if you have any. What are you struggling with? In the end you have a list of entities with the CRUD actions and additional actions to swtch pages.
@@temitopejunior can you be a little bit more specific about that? Do you mean a sign-up use case, where the user receives an activation email? If yes, I don't think that ngrx plays a big role here. You have a route in your angular application that forwards the activation to your backend, show the a proper message and redirects the user to the login. There will be an episode about doing proper redirection within ngrx though. So if that's what you need, help will come!
Hi Hans, so I would argue that nx is no dependency with a lock-in effect. For me, nx provides features in three areas: Tooling, Build improvement and linting rules. If you decide one day, you don't want to use nx anymore, then you loose these. But it is not a blocker and also not a huge amount of work to remove them. In the end, it is more or less a fallback to the normal Angular CLI. You will have to maintain the configuration of all the tooling though or just delete them as well. That would be jest, storybook, cypress, eslint, etc. So summarized, as long as nx comes with a smooth/natural fallback option, I don't see it as something where I depend on. If that changes though, I would have a different opinion.
@@RainerHahnekamp Nx does profit from Angular. Angular CLI has all the possibilities to structure the Angular App Directory the same way as Nx does. To my opinion it would be fair of Nx to contribute back to Angular and allow for an Angular way to use some of Nx features. Maybe to addon Nx Schematics to Angular Schematics! Anyway thank's for your comment. I would like to stay on the classical Angular path and maybe profit from some features of Angular! I feel safer in the hands of Angular than in the hands of Nx.
Amazing content and quality. Looking forward for more. Thanks!
Thanks a lot!
I use this pattern, with one difference. In your example, you use filter() to decide whether or not a get action should be dispatched. Instead of this, I prefer to check the loadStatus and dispatch always dispatch an action depending on the status. If it is NOT_LOADED, I would dispatch the "get" action. But if it is LOADING or LOADED I would dispatch a "alreadyLoading" or "alreadyLoaded" action respectively, which will both do nothing.
That way your "get" action will always result in a kind of "reaction" that you can see in the redux dev tools. Imho that makes debugging easier. In your example if no data is shown in the UI after a "get" action has been dispatched (and no action afterwards according to the dev tools) it would be easier to see if this is a bug in your effect or in your display logic.
For other people reading this: If you need error handling, the loadedStatus can easily be extended with an ERROR state (for example if your API did not respond). When you do this, you can display error messages and also prevent the same call from being processed again or the opposite, process it again because it errored. Some simple form of error handling should always be incorporated, atleast to reset the loadStatus to "NOT_LOADED".
I agree. Error handling isn't integrated here but would be necessary. Otherwise it would just block. Thanks for pointing that out.
Hi Rainer, thank you for your awesome content. Do you or AngularArchitects have a full example. with ngrx caching and error/succes state aswell? I Found somewhere on Github an example with local storage but I cannot find it anymore. Regards Bram
Hello Bram,
we cover that in the Advanced NgRx workshop: www.angulararchitects.io/en/training/professional-ngrx-advanced-state-management-best-practices/
Unfortunately, we don't have a public example available, but I can recommend you to checkout these two sources:
- github.com/btroncone/ngrx-store-localstorage
- timdeschryver.dev/blog/keeping-browser-tabs-in-sync-using-localstorage-ngrx-and-rxjs
This is great content I’d love to see more!
Thanks, I'll try to publish the third episode in the upcoming days.
Can please do a video explain how to manage cach (CRUD with Pagination) using ngRX
Hey, I'm not sure if CRUD + Pagination is enough for a complete video but I can answer specific questions, if you have any. What are you struggling with?
In the end you have a list of entities with the CRUD actions and additional actions to swtch pages.
THIS IS AMAZING! EXACTLY WHAT I NEEDED!!!!!!! THANKS
Great, and if have you have other interesting challenges, let me know!
@@RainerHahnekamp do you have an email verification video or information please?
@@temitopejunior can you be a little bit more specific about that? Do you mean a sign-up use case, where the user receives an activation email? If yes, I don't think that ngrx plays a big role here. You have a route in your angular application that forwards the activation to your backend, show the a proper message and redirects the user to the login.
There will be an episode about doing proper redirection within ngrx though. So if that's what you need, help will come!
@@RainerHahnekamp exactly your last paragraph. Thanks a lot
Thanks a lot! Amazing!
Thanks as well
How about when I'd like to use spinner on add customer action? Can I use laodStatus property for this?
Yes you can. Maybe you want to checkout at that video as well: ua-cam.com/video/IpC-s8tGALo/v-deo.html
I am not sure about your statement: "I see no reason why you should not use Nx these days"! What if I do not want to depend on such a big environment?
Hi Hans,
so I would argue that nx is no dependency with a lock-in effect.
For me, nx provides features in three areas: Tooling, Build improvement and linting rules. If you decide one day, you don't want to use nx anymore, then you loose these. But it is not a blocker and also not a huge amount of work to remove them. In the end, it is more or less a fallback to the normal Angular CLI. You will have to maintain the configuration of all the tooling though or just delete them as well. That would be jest, storybook, cypress, eslint, etc.
So summarized, as long as nx comes with a smooth/natural fallback option, I don't see it as something where I depend on. If that changes though, I would have a different opinion.
@@RainerHahnekamp Nx does profit from Angular. Angular CLI has all the possibilities to structure the Angular App Directory the same way as Nx does. To my opinion it would be fair of Nx to contribute back to Angular and allow for an Angular way to use some of Nx features. Maybe to addon Nx Schematics to Angular Schematics! Anyway thank's for your comment. I would like to stay on the classical Angular path and maybe profit from some features of Angular! I feel safer in the hands of Angular than in the hands of Nx.
This is really useful! Thanks 🙂
Thanks as well. Happy you liked it.