Hy. I am 24 and I stacked between middle and senior position. Videos like this can help to get some data about app architecture, with is gold now. This video is very helpful and gives a good start point. Please keep sharing you knowledge. Thank you so much!
The title of this video is misleading. The first mention of Standalone Components is at 22:00 out of a 24:00 video. No code is shown about them. This video is more about NX architecture than anything else.
Hi Loïc, this video was recorded in December 2021. It is more than half a year old. That's why you see so little code. At that time, the API for Standalone Components was still discussed, and I avoid showing experimental code that might change. If you want to see stable Standalone Component code, then I would recommend watching my other video on upgrading to Angular 14: th-cam.com/video/g836yoZ2y6o/w-d-xo.html There you'll see plenty of it. And regarding nx: This video focuses on the modularity part. As far as I am aware, you can only get that from nx.
I might be missing something here but you state that if we are using libraries we are on the right track.. but the libraries does also contain modules? isn't the point to get rid of these modules that holds components?
You want to have an encapsulation feature in Angular. In programming, we usually call that a "module". The confusing part is that the NgModule is not a "module" in that sense because it provides only limited encapsulation. Only the lib, you get in nx, is a real "module". Due to Angular's rules, nx libs also have to contain NgModules. Otherwise, components, directives, and pipes would not work. With Standalone Components this changes. So you would have libs without NgModules. Is it clearer now?
Great talk, thx for that :). It was quite interesting. One/two questions I have. Is webpack smart enough to handle duplicate imports? I mean, what will happen, when I have 2 different components but both are using somehow similar exported stuff like models or services? They will not exist twice, right? When I use both components in one component, or?
Thank you very much and it is as you said: As long as everything ends up in a single bundle you don't have to worry about having the same code multiple times. Webpack is clever enough. A complete different story though is the amount how often these services are instantiated but as I understood it, that was not your question, right? You care about the bundle size.
@@RainerHahnekamp exactly. So the thing about tree shakabilty (If this word ever exists :D) or just tree shaking. I know there is a ticket about standalone components inside a module, without using them, they will still be part of the production bundle.
I like your explanation regarding nx projects as the real "module" that can be shared between apps. What if App A and App B both need share an nx lib C, BUT, A and B are not in the same code base? How do I do with the shareable C? Package it to a real library and host it?
Hello Huanto, if different applications have a dependency to the same lib and you don't put them into a monorepository, then you'll have to make an npm package out of the shared library and publish it to an npm registry where all your applications have access to. Do you require more explanation about publishing to an npm registry?
@@RainerHahnekamp thanks Rainer. Yes we do host libs in our internal npm registry. In my case the shared module is not a library, it is more like a shared app, which has some routers and services. I think in this case maybe I need look into web components?
@@huantao2274 Careful with web components. Do you use your library as an actual 'app container' where you embed another application, or is it more the scenario where your library provides components that are reachable via a certain route?
@@RainerHahnekamp yes i will need the shared lib as a component that is reachable through certain route, but the component should be smart component, it has service make calls
@@huantao2274 Ok, in that case, I see three options. Going with web components, module federation or pack into an angular module and install it in your apps as any other library. 1. Web Components: In combination with Angular, I would only use Web Components for UI components with limited logic. Your web component (generated by Angular Elements) will include the complete framework, it wants to use its own router, and you will face issues with zone.js and probably a couple of other things as well. I've written an article some time ago which is still valid: www.rainerhahnekamp.com/en/why-you-dont-need-web-components/ 2. Micro Frontends: Is much better than web components because it allows you to load any JavaScript file that includes an Angular module but integrates it into the existing Angular host. So you don't have to deal with the issues I listed in web components. It is also very easy to share services between the host and remotes (your lib). The downside is that the Angular compiler version of your lib and app have to match. If you want to go for 100%, then even on the patch level, although many companies try to match the minor (maybe even) major and don't report any issues. But version mismatch can cause trouble. 3. Npm Library: If you cannot guarantee that your lib and app have the same angular version and you don't want to fix all issues that come with web components, then you create npm libraries. You can also create multiple versions of it. One compiled for Angular 9, 10, 11, 12, etc. Dependening on the complexity of your lib, you might also get away with one version only.
An Angular module is a unit of angular compilation - it is necessary for the Angular compiler! It is hardly to imagine that this will ever go away. An Angular module is also a perfect unit for a feature module. A feature module contains all components, state this feature is in need of and is located in its own folder: products module components page (container comp) list (presentation comp) view (presentation com) state (products state - models) service (products service provided by products module)
Hi Hans, I think we are mixing here up two different things: As you said, the Angular module is a unit of the compiler. In other words, it has been designed for the particular needs of the compiler and not primarily for us as Angular developers. We see that in the design, that critical features like encapsulation are not fully covered. If we take the feature module you described, you definitely want to make sure that some services (especially the state) can only be used inside of the products feature (domain). An NgModule can't do that, only if your feature module is an NodeJs library combined with the lining rules from nx. So I would say, let the NgModule be there as long as it is a requirement of the compiler but if I (as application developer) need a module, I always go with a NodeJs library. And there have been some statements from the Angular team that NgModules should be removed in the long run.
@@RainerHahnekamp I like your proposal to create a Angular Library for encapsulation. Question: Would it be possible to just use thre nx rules which do not allow "deep import" without embarking on the whole nrwl nx train? Thank's a lot for the profound information on Angular Development you provide in public!^_^!
@@hansschenker Thanks for the compliment. A solution that uses these linting rules outside of nx is something that I've already planned to come up with. After sam-4s is finished (deadline is next Thursday www.meetup.com/de-DE/Angular-Meetup-Graz/events/283677638) that would be my next project.
For me it is a necessary boilerplate. Standalone Components will improve the situation, but as long as we don't want to use jsx or tsx, some boilerplate will stay. As long as it isn't XDoclet, I'm fine :D
I really appreciate your work here. nice talk. Well paused, step by step, just awesome. Thanks Rainer!
Thanks as well Angel.
Hy. I am 24 and I stacked between middle and senior position. Videos like this can help to get some data about app architecture, with is gold now. This video is very helpful and gives a good start point. Please keep sharing you knowledge.
Thank you so much!
Hi Ivan, thanks a lot as well, and all the best for reaching the senior position soon.
Really enjoyed this video and understood the concepts. Thanks so much!
Great, thanks for the compliment!
The title of this video is misleading. The first mention of Standalone Components is at 22:00 out of a 24:00 video. No code is shown about them. This video is more about NX architecture than anything else.
Hi Loïc,
this video was recorded in December 2021. It is more than half a year old. That's why you see so little code.
At that time, the API for Standalone Components was still discussed, and I avoid showing experimental code that might change.
If you want to see stable Standalone Component code, then I would recommend watching my other video on upgrading to Angular 14: th-cam.com/video/g836yoZ2y6o/w-d-xo.html There you'll see plenty of it.
And regarding nx: This video focuses on the modularity part. As far as I am aware, you can only get that from nx.
High quality presentation ! Thank you, Rainer !
Thanks as well. I'm always happy, if somebody gets something out of it.
I might be missing something here but you state that if we are using libraries we are on the right track.. but the libraries does also contain modules? isn't the point to get rid of these modules that holds components?
You want to have an encapsulation feature in Angular. In programming, we usually call that a "module".
The confusing part is that the NgModule is not a "module" in that sense because it provides only limited encapsulation. Only the lib, you get in nx, is a real "module".
Due to Angular's rules, nx libs also have to contain NgModules. Otherwise, components, directives, and pipes would not work. With Standalone Components this changes. So you would have libs without NgModules.
Is it clearer now?
@@RainerHahnekamp Thx for the clarification! 🎉
Great talk, thx for that :). It was quite interesting. One/two questions I have. Is webpack smart enough to handle duplicate imports? I mean, what will happen, when I have 2 different components but both are using somehow similar exported stuff like models or services? They will not exist twice, right? When I use both components in one component, or?
Thank you very much and it is as you said: As long as everything ends up in a single bundle you don't have to worry about having the same code multiple times. Webpack is clever enough.
A complete different story though is the amount how often these services are instantiated but as I understood it, that was not your question, right?
You care about the bundle size.
@@RainerHahnekamp exactly. So the thing about tree shakabilty (If this word ever exists :D) or just tree shaking. I know there is a ticket about standalone components inside a module, without using them, they will still be part of the production bundle.
@@MrNix2012 Can you post the link to that ticket here? I'd like to check that out before answering your question.
@@RainerHahnekamp sure, here it is: github.com/angular/angular/issues/46373
I like your explanation regarding nx projects as the real "module" that can be shared between apps. What if App A and App B both need share an nx lib C, BUT, A and B are not in the same code base? How do I do with the shareable C? Package it to a real library and host it?
Hello Huanto, if different applications have a dependency to the same lib and you don't put them into a monorepository, then you'll have to make an npm package out of the shared library and publish it to an npm registry where all your applications have access to.
Do you require more explanation about publishing to an npm registry?
@@RainerHahnekamp thanks Rainer. Yes we do host libs in our internal npm registry. In my case the shared module is not a library, it is more like a shared app, which has some routers and services. I think in this case maybe I need look into web components?
@@huantao2274 Careful with web components. Do you use your library as an actual 'app container' where you embed another application, or is it more the scenario where your library provides components that are reachable via a certain route?
@@RainerHahnekamp yes i will need the shared lib as a component that is reachable through certain route, but the component should be smart component, it has service make calls
@@huantao2274 Ok, in that case, I see three options. Going with web components, module federation or pack into an angular module and install it in your apps as any other library.
1. Web Components: In combination with Angular, I would only use Web Components for UI components with limited logic. Your web component (generated by Angular Elements) will include the complete framework, it wants to use its own router, and you will face issues with zone.js and probably a couple of other things as well. I've written an article some time ago which is still valid: www.rainerhahnekamp.com/en/why-you-dont-need-web-components/
2. Micro Frontends: Is much better than web components because it allows you to load any JavaScript file that includes an Angular module but integrates it into the existing Angular host. So you don't have to deal with the issues I listed in web components. It is also very easy to share services between the host and remotes (your lib). The downside is that the Angular compiler version of your lib and app have to match. If you want to go for 100%, then even on the patch level, although many companies try to match the minor (maybe even) major and don't report any issues. But version mismatch can cause trouble.
3. Npm Library: If you cannot guarantee that your lib and app have the same angular version and you don't want to fix all issues that come with web components, then you create npm libraries. You can also create multiple versions of it. One compiled for Angular 9, 10, 11, 12, etc. Dependening on the complexity of your lib, you might also get away with one version only.
An Angular module is a unit of angular compilation - it is necessary for the Angular compiler! It is hardly to imagine that this will ever go away.
An Angular module is also a perfect unit for a feature module. A feature module contains all components, state this feature is in need of and is located in its own folder:
products
module
components
page (container comp)
list (presentation comp)
view (presentation com)
state (products state - models)
service (products service provided by products module)
Hi Hans, I think we are mixing here up two different things:
As you said, the Angular module is a unit of the compiler. In other words, it has been designed for the particular needs of the compiler and not primarily for us as Angular developers. We see that in the design, that critical features like encapsulation are not fully covered.
If we take the feature module you described, you definitely want to make sure that some services (especially the state) can only be used inside of the products feature (domain). An NgModule can't do that, only if your feature module is an NodeJs library combined with the lining rules from nx.
So I would say, let the NgModule be there as long as it is a requirement of the compiler but if I (as application developer) need a module, I always go with a NodeJs library.
And there have been some statements from the Angular team that NgModules should be removed in the long run.
@@RainerHahnekamp I like your proposal to create a Angular Library for encapsulation.
Question: Would it be possible to just use thre nx rules which do not allow "deep import" without embarking on the whole nrwl nx train?
Thank's a lot for the profound information on Angular Development you provide in public!^_^!
@@hansschenker Thanks for the compliment. A solution that uses these linting rules outside of nx is something that I've already planned to come up with. After sam-4s is finished (deadline is next Thursday www.meetup.com/de-DE/Angular-Meetup-Graz/events/283677638) that would be my next project.
@@RainerHahnekamp thank's a lot. Following Rainer Hahnekamp is following one of the most informed Angular Expert - for sure will follow you!
These are great. Thank you.
Thanks as well Oskar!
Great explanation! Keep going! :)
Thanks Vladimir, will do!
scam is a good idea but not very practical!
For me it is a necessary boilerplate. Standalone Components will improve the situation, but as long as we don't want to use jsx or tsx, some boilerplate will stay. As long as it isn't XDoclet, I'm fine :D