👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
All the frameworks you mention have their own type of ceremony around even the simplest application state. I prefer NgRx over the others since it doesn't use decorators (which have never been standardized by the way). NgRx version 8 introduced creator functions to cut down on the amount of code needed to set up state. For CRUD applications, NgRx Entity and NgRx Data removes most of the setup needed.
The NgRx team is doing a great job for sure and they recently reduced the minimal amount of code to write, but to me the use of decorators is a huge plus, especially in the context of Angular that makes heavy use of decorators. It just feels like home to use NgXs decorators.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
But once compiled the decorators are just functions no? What is the drawback of decorators, even if executed at runtime to you? Only the fact they aren't standard yet?
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
Non-Angular decorators are function wrappers, yes. But the structure and semantics of decorators, even the syntax can still change. Heck, decorators might never make it into the language (that language is ECMAScript, not TypeScript).
If syntax and semantics change, don't bet on TypeScript saving our behinds. When we use decorators in TypeScript, we enable the option "experimentalDecorators", meaning: "You're on your own, pal. Good luck!". It's called experimental for a reason (that reason is Angular by the way, there used to be this language called AtScript).
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
I didn't mean to turn this into a state management framework discussion. I prefer NgRx over Akita for the reasons mentioned in my on-topic reply, but also because Akita makes heavy use of classes and inheritance which I personally dislike. I don't think it reduces the amount of code needed to set up and use state either.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
All the frameworks you mention have their own type of ceremony around even the simplest application state. I prefer NgRx over the others since it doesn't use decorators (which have never been standardized by the way). NgRx version 8 introduced creator functions to cut down on the amount of code needed to set up state. For CRUD applications, NgRx Entity and NgRx Data removes most of the setup needed.
The NgRx team is doing a great job for sure and they recently reduced the minimal amount of code to write, but to me the use of decorators is a huge plus, especially in the context of Angular that makes heavy use of decorators. It just feels like home to use NgXs decorators.
There's a big difference. Angular's decorators are compiler instructions and are not present at runtime.
Oh, never thought of that.
But once compiled the decorators are just functions no? What is the drawback of decorators, even if executed at runtime to you? Only the fact they aren't standard yet?
Non-Angular decorators are function wrappers, yes. But the structure and semantics of decorators, even the syntax can still change. Heck, decorators might never make it into the language (that language is ECMAScript, not TypeScript).
If syntax and semantics change, don't bet on TypeScript saving our behinds. When we use decorators in TypeScript, we enable the option
"experimentalDecorators"
, meaning: "You're on your own, pal. Good luck!". It's called experimental for a reason (that reason is Angular by the way, there used to be this language called AtScript).That's not true. Akita doesn't use decorators. It has only one metadata decorator for the store config, which is also optional.
I didn't mean to turn this into a state management framework discussion. I prefer NgRx over Akita for the reasons mentioned in my on-topic reply, but also because Akita makes heavy use of classes and inheritance which I personally dislike. I don't think it reduces the amount of code needed to set up and use state either.
Decorators also introduce tree-shaking issues.
I've heard of some saying decorators bad for tree-shaking but never seeing something that proves it. Is there any evidence to that?
Read these Webpack docs: webpack.js.org/guides/tree-shaking...