Eyyyyy this will clean up my code big time! Ah man, naming my actions with prefix's was, as British people would put it "a bit of a faff". Thanks Brandon!
This will do a lot of cleaning. It is such a nice feature. It is easy for the developers who are growing ngrx api, but it'll require some explaining to beginner that how far we came from original actions 😀
@@BrandonRobertsDev A different question, I have a Shell module with store that need read access of users, and there is another module Users that need read and write access of users. Now should I keep state users in two different stores or in one store? If I consider Shell to be only place that has user state, than it doesn't look right that user module is dependant on another sibling module "shell" store. It loses the code colocation. If I keep same state in two different places, than I have to maintain at two different places, every time user is updated, I have to send to two dispatches. Such that both store are updated. Than it is antipattern for me. Did you came across such situation? and what solution would you propose?
I'm relatively new to angular and ngrx and I would like to know, are there any new features that reduce boilerplate code for other ngrx stuff (like selectors, effects, reducers, etc) I feel like I have to write so much code and so many files, just to achieve the simplest things...😅 Great Video btw. As a newbie I'm loving your content!
Thanks! One thing to be mindful of is that NgRx is to be used mainly for globally shared state. The files you have to create are part of having process around updating this state. All state in your app doesn't need to go into the Store, so if you only use it when necessary it will provide it's value there. Look at NgRx ComponentStore if you're looking for something more lightweight in terms of state management. I have a video on that also
Seems like someone had fun with those new string type features in typescript 😅 Very interesting idea. Sadly my IDE can't trace back "find usage" or if an action is unused. But with actually using it like this in the wild, maybe the static analyzers will soon account for it.
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
thanks man, now I understand the actions
Great implementation. This is a much cleaner way to handle action creation. I also was not aware of the callback function trick.
Thank you for your video, very helpful! Is there a way to rewrite them to Action Group automatically?
Thank for sharing Brandon Roberts!
I am starting a new Angular App with NgRx State Management as always and will go with this Nice Feature!!
Cool, let us know how it goes after you get going! Discord: discord.gg/ngrx
Super!! Exactly what I needed clarity on.
Eyyyyy this will clean up my code big time! Ah man, naming my actions with prefix's was, as British people would put it "a bit of a faff". Thanks Brandon!
Appreciate that James!
This will do a lot of cleaning. It is such a nice feature. It is easy for the developers who are growing ngrx api, but it'll require some explaining to beginner that how far we came from original actions 😀
Definitely. After you get familiar with creating them separately, the new function helps out so much more.
@@BrandonRobertsDev A different question, I have a Shell module with store that need read access of users, and there is another module Users that need read and write access of users. Now should I keep state users in two different stores or in one store?
If I consider Shell to be only place that has user state, than it doesn't look right that user module is dependant on another sibling module "shell" store. It loses the code colocation.
If I keep same state in two different places, than I have to maintain at two different places, every time user is updated, I have to send to two dispatches. Such that both store are updated. Than it is antipattern for me. Did you came across such situation? and what solution would you propose?
this is a really good explanations of actions!
Thanks!
Great video, Brandon! This will reduce the action creation overhead by some margin.
Thanks Sourav!
I'm relatively new to angular and ngrx and I would like to know, are there any new features that reduce boilerplate code for other ngrx stuff (like selectors, effects, reducers, etc) I feel like I have to write so much code and so many files, just to achieve the simplest things...😅 Great Video btw. As a newbie I'm loving your content!
Thanks! One thing to be mindful of is that NgRx is to be used mainly for globally shared state. The files you have to create are part of having process around updating this state. All state in your app doesn't need to go into the Store, so if you only use it when necessary it will provide it's value there. Look at NgRx ComponentStore if you're looking for something more lightweight in terms of state management. I have a video on that also
Thanks, Brandon! Great stuff!
Thanks Kristopher!
Thanks Brandon, awesome NGRX as always
Thanks Oscar
Seems like someone had fun with those new string type features in typescript 😅 Very interesting idea. Sadly my IDE can't trace back "find usage" or if an action is unused. But with actually using it like this in the wild, maybe the static analyzers will soon account for it.
Definitely took some TypeScript wizardry by Marko to get this working. As you said hopefully the IDEa can better identify these in practice
Nice feature - thanks!
But the downside is that now I can't use VS Code to find all references of a declared action.
That's true and a trade-off for now. Hopefully the IDEs will gain better support for it
Thanks Brandon.
Thanks Peyman
I don't find this very intuitive :( . I get it, the old approach was verbose but at least you could find actions more easily based on they real name.