Hi Lars. Good to have you here! As you write in the introduction it's been 9 months and 3 major Angular releases with Ivy since you wrote the article. Can you give us an updated view of what happened to NgModules in the meantime?
With the Angular Ivy renderer, this approach could become a thing of the past.
From what I see nothing has changed in Angular 11. If both approaches are possible now I wonder how big the overhead of NgModules is... and does it mean we should only use NgModules when we want to use lazy loading?
edit: Ooops, it's been not only 9 months, but 1 year and 9 months.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
Indeed, I remember starting this research 23 months ago 😊 Back then I was tired of waiting around for Ivy. Lots of talk about optional Angular modules in 2018, but all talk no show. I decided to try to figure out what that would look like in practice by approaching something similar to the deps component metadata proposal.
It might never make it into the Angular framework.
While writing this article, I ended up coining the term SCAM (Single Component Angular Module). I took it two steps further and turned it into a conference talk which I believe is mentioned in this article Part 2 in this series discusses SCAMs further in practice. I started working on Part 3 and planned a Part 4 based on the patterns I produced as part of my research for the mentioned conference talk, but Ivy seemed so close that it didn't make sense.
Seeing that it's now 2 years later and we're still stuck with Angular modules, I might pick up this series again as it's still highly relevant. I'm looking to continue the series in 2021. Until then, you can have a look at these repositories:
I made them shortly after the first stable release of Angular Ivy, back in February 2020. Feature render modules are the final frontier before actual tree-shakable components. The description of the last repository shows that this has potential:
14.1 KB gzipped (41.8 KB uncompressed).
Zippy Angular app using renderComponent and a feature render module.
Besides the point that the renderComponent API is still not public (maybe it will become so as part of the possible future optional NgModules effort), there are still unsolved issues mentioned in this very article. I'm starting to plan for a Part 5 of this series which looks into each of these in detail.
I have quite a few spare time writing projects planned, so timelines and interests indicated in this comment may vary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Lars. Good to have you here! As you write in the introduction it's been 9 months and 3 major Angular releases with Ivy since you wrote the article. Can you give us an updated view of what happened to NgModules in the meantime?
From what I see nothing has changed in Angular 11. If both approaches are possible now I wonder how big the overhead of NgModules is... and does it mean we should only use NgModules when we want to use lazy loading?
edit: Ooops, it's been not only 9 months, but 1 year and 9 months.
Thanks for your comment, Thorsten
Indeed, I remember starting this research 23 months ago 😊 Back then I was tired of waiting around for Ivy. Lots of talk about optional Angular modules in 2018, but all talk no show. I decided to try to figure out what that would look like in practice by approaching something similar to the
depscomponent metadata proposal.This year, the Angular team released their first public Angular roadmap which happens to mention optional NgModules. However, note that this item is in the Future section which means that:
While writing this article, I ended up coining the term SCAM (Single Component Angular Module). I took it two steps further and turned it into a conference talk which I believe is mentioned in this article Part 2 in this series discusses SCAMs further in practice. I started working on Part 3 and planned a Part 4 based on the patterns I produced as part of my research for the mentioned conference talk, but Ivy seemed so close that it didn't make sense.
Seeing that it's now 2 years later and we're still stuck with Angular modules, I might pick up this series again as it's still highly relevant. I'm looking to continue the series in 2021. Until then, you can have a look at these repositories:
I made them shortly after the first stable release of Angular Ivy, back in February 2020. Feature render modules are the final frontier before actual tree-shakable components. The description of the last repository shows that this has potential:
Besides the point that the
renderComponentAPI is still not public (maybe it will become so as part of the possible future optional NgModules effort), there are still unsolved issues mentioned in this very article. I'm starting to plan for a Part 5 of this series which looks into each of these in detail.I have quite a few spare time writing projects planned, so timelines and interests indicated in this comment may vary.