I really enjoyed this video because you took a problem, demonstrated why it happens, demonstrated a solutions with explanation - then provided information on a third party product. With this video I learned so much, even beyond testing
I just ran into a situation like this today but with component store in a child component being the troublesome thing. I think this solution will work a lot better than what I tried to do. Thanks.
This is great content as always. The concern I have about moving to standalone components is the bundle size. I haven't taken a deep look into this, but I've read here and there that there's a lot of code duplicated and your app actually grows in size. I'm sure it can be mitigated with lazy loading, but it's something to consider.
Hi, where did you hear about the bundle size issue? Could it be that you are mistake standalone with the barrel files? Having a lot of barrel files (index.ts) will problems to your bundler because it might not be able to tree-shake them efficientyl, and you may end up with a huge initial bundle. Regarding Standalone vs NgModule, there is no impact on the bundle size.
another great explanation! thank you! it's embarassing but in my company we got new schematics using overrideCopmonents and I just did not bother finding out why... sometimes the test did not work and then I spend hours trying out different things. So happy I now understand, what it does!
You mention the usage of ng-mocks library to Mock Standalone Components. We use this as wel to mock our services that we provide. However, sometimes, it uses the actual service instead of the mocked one. How do you properly mock these services that you provide?
Do you want to test only the guards or the guard in combination with a Component? In the first case, check out this video th-cam.com/video/mMiSmStwGOU/w-d-xo.html, in the second that one: th-cam.com/video/DsOxW9TKroo/w-d-xo.html
How about non-standalone dependencies? I have in my imports array some modules with related dependencies. I want to replace them with stubs which I already have. Should I create test module and include all stubs components in it and add it to the standalone imports?
So you will always have to configure the TestingModule. There is no other way if you want to test via the DOM (and it is also the official recommendation). Without standalone, mocking is easier. you just declare your stubs instead the original ones. Declare, not import.
I have a problem with a dialog that is standalone, which returns this error TypeError: Cannot read properties of undefined (reading 'find') at Dialog.getDialogById (node_modules/@angular/cdk/fesm2022/dialog.mjs:506:33), has anyone encountered this error?
Great tutorial! Was able to finally understand how to inject mocks for standalone stuff. Thanks 😁
Great to hear, you're welcome
I really enjoyed this video because you took a problem, demonstrated why it happens, demonstrated a solutions with explanation - then provided information on a third party product. With this video I learned so much, even beyond testing
Thanks a lot Dylan!
I've been fighting against this problem for hours, thanks for the video, all really clear!
Thanks, great to hear.
Thank you.
Great content 🙏
Thanks as well
I just ran into a situation like this today but with component store in a child component being the troublesome thing. I think this solution will work a lot better than what I tried to do. Thanks.
You're welcome Michael! Happy to help.
Awesome, great explanation. This is what I was looking for
👍
Amazing content as always!!!!!
Thanks Dany and best wishes!
Indepth Info as always, thanks Rainer
Thanks as well Vinit.
This is great content as always. The concern I have about moving to standalone components is the bundle size. I haven't taken a deep look into this, but I've read here and there that there's a lot of code duplicated and your app actually grows in size. I'm sure it can be mitigated with lazy loading, but it's something to consider.
Hi, where did you hear about the bundle size issue?
Could it be that you are mistake standalone with the barrel files? Having a lot of barrel files (index.ts) will problems to your bundler because it might not be able to tree-shake them efficientyl, and you may end up with a huge initial bundle.
Regarding Standalone vs NgModule, there is no impact on the bundle size.
Thanks Rainer, awesome video !
You are very welcome Rudy
another great explanation! thank you!
it's embarassing but in my company we got new schematics using overrideCopmonents and I just did not bother finding out why... sometimes the test did not work and then I spend hours trying out different things. So happy I now understand, what it does!
Yeah, so TestBed.override... is something we don't see that often but it is quite powerful
By the way, MockComponents from ng-mocks work just as well, and your tests look clearer
Isn't that what I show at the end of the video?
You mention the usage of ng-mocks library to Mock Standalone Components. We use this as wel to mock our services that we provide. However, sometimes, it uses the actual service instead of the mocked one. How do you properly mock these services that you provide?
Hi, could it be the case that those services are provided by the component? Otherwise, it has to work as expected. Can you maybe provide an example?
@@RainerHahnekamp The services are indeed all provided on the component itself.
Very good thanks...
Thanks Roland.
how to test Angular Guards ?
Do you want to test only the guards or the guard in combination with a Component?
In the first case, check out this video th-cam.com/video/mMiSmStwGOU/w-d-xo.html, in the second that one: th-cam.com/video/DsOxW9TKroo/w-d-xo.html
@@RainerHahnekamp really, appreciated 👏
Thanks for video)
You're very welcome!
How about non-standalone dependencies? I have in my imports array some modules with related dependencies. I want to replace them with stubs which I already have. Should I create test module and include all stubs components in it and add it to the standalone imports?
So you will always have to configure the TestingModule. There is no other way if you want to test via the DOM (and it is also the official recommendation). Without standalone, mocking is easier. you just declare your stubs instead the original ones. Declare, not import.
Cool!!!
Thanks Paul!
I have a problem with a dialog that is standalone, which returns this error TypeError: Cannot read properties of undefined (reading 'find') at Dialog.getDialogById (node_modules/@angular/cdk/fesm2022/dialog.mjs:506:33), has anyone encountered this error?
It would be great if you could offer some stackblitz example for reproduction.