Fantastic video! It's a good topic to cover, I'm glad I found this! Just one part I have not been able to understand well: Starting around 5:50, you said that we don't want to export the UI Modules from the SharedModule to avoid multiple import statements. I can understand the goal of keeping the code cleaner through barrel files for the imports at the top of each file, but wouldn't you be able to keep your FeatureModules code cleaner by only importing the SharedModule (with all UI Modules in its exports array) instead of importing all the UI Modules there individually like you started doing at 11:09?
Thanks for the feedback mate 🙏🏼 import files would look better as you explained however it would impact the performance negatively since you’d import every ui-module in every feature module 😃
Where do you place your nested routes ? Lets say /account module has /acount/:id and account/:id/settings and account/:id/settings/random-route1, .../settings/random-route-2. Do you keep nesting files inside of pages deeper and deeper or you flatten and keep max one level with longer description like account-detail-settings-random1. And also when is the time for subroute to be its own module or all the pages are their own modules. Sry if its confusing question.
Thats a good question mate! 😁 if there are a couple of nested routes its fine. However, if its too many nested routes, I would consider breaking it into submodules. Meaning, we create a new folder within the feature module named "subfeature 1", "subfeature 2" etc. The reason is we want to enable for lazy loading 😁
hi want angular version your used in this project do you have a folder structure for angular 17 and 18 I checked the latest angular version it have a standalone composennt and signals that application faster and better than previous angular version.
That is great. I do similar type thing in my project. what is your oppinion about account module have children module, Call AccountDetails module, so account details module contain just like account module(page, service, etc)?
I thought the way you explained it was sensational. In terms of aesthetics, it is a completely clean code, can you tell me in terms of performance, would it change anything? And talking about lazy-loading, how do I reduce my "main" in the final build, it's getting 2.4mb... would you have any examples?
Thanks for watching and the awesome feedback mate! In terms of performance: * If you utilize lazy loading - it will have a significant impact in terms of performance as it will only load things when the user hits a certain route. * If you combine that with build optimization and three shaking - it may impact the performance in a positive way, I have a short video on how to achieve that here: ua-cam.com/video/NPsRXz5MOSg/v-deo.html When it comes to lazy loading, etc, the build sizes will most likely be the same. However, with threeshakeability and build optimization - it might decrease the size of the build :)
Excellent question mate. I love standalone components. The structure could be similar but with less files, and would be trivial for ui components and shared components. So its a good idea to use it where its suitable.
Great question - if it's a core interceptor (one used for ALL requests on a global level) - I would add it under the core/interceptors folder. If it's a feature specific one, I would create an interceptor folder there e.g. feature1/interceptors. If it's none of the above, its most likely a shared one - so under shared/interceptors (when it's used in some of the features but not all). Hope that helps :)
If you have to explain to someone what the difference is between "core" and "shared", then it's a flawed model. Project structure should be self evident and not require any additional "explaining". Just like when you are building UI designs, there should be no "ambiguous choices" - any choices the dev has to make (where do I put this bit of code) should be automatic and unambigous.
Thanks for your feedback mate. However, I don’t agree with it. I believe it might be obvious what differences there are between the core and shared folders if you are used with that particular thinking 😃
@@DevBySeb Thank you so much for the video. This is really very good material. But I need an example of the layout of different services. If I understand correctly, everything related to the main layout (menu, header, footer) is located in CORE. If I have an HTTP service, which will be used by all other services, then we also locate it in CORE? If I have a service responsible for the appearance of toast (with errors or info) on the screen, do I locate it in CORE or in SHARED?
Oh my god that's what I've been searching for, a tutorial where someone treats me like a competent developer
Thanks for the feedback and for watching mate 🙏🏼
Nice explanation! It's a clean solution the way you handle import paths
Thanks for the awesome feedback mate and thank you for watching 🙏
Thanks for sharing with us!!! 🎉
Thank you for watching 🙏🙏
Nice explanation ! 👏
Thanks for the awesome feedback mate 🙏🏼
Fantastic video! It's a good topic to cover, I'm glad I found this!
Just one part I have not been able to understand well:
Starting around 5:50, you said that we don't want to export the UI Modules from the SharedModule to avoid multiple import statements.
I can understand the goal of keeping the code cleaner through barrel files for the imports at the top of each file, but wouldn't you be able to keep your FeatureModules code cleaner by only importing the SharedModule (with all UI Modules in its exports array) instead of importing all the UI Modules there individually like you started doing at 11:09?
Thanks for the feedback mate 🙏🏼 import files would look better as you explained however it would impact the performance negatively since you’d import every ui-module in every feature module 😃
much appreciated! can you share the formatter settings you are using please? thanks
Thanks for watching mate 🙏🏼 I’m using ”prettier” with default settings 😀
i definitely gonna use it in my project!!!
Thanks for watching mate - glad to help 🙏
Where do you place your nested routes ? Lets say /account module has /acount/:id and account/:id/settings and account/:id/settings/random-route1, .../settings/random-route-2.
Do you keep nesting files inside of pages deeper and deeper or you flatten and keep max one level with longer description like account-detail-settings-random1.
And also when is the time for subroute to be its own module or all the pages are their own modules.
Sry if its confusing question.
Thats a good question mate! 😁 if there are a couple of nested routes its fine. However, if its too many nested routes, I would consider breaking it into submodules. Meaning, we create a new folder within the feature module named "subfeature 1", "subfeature 2" etc. The reason is we want to enable for lazy loading 😁
but why inside app and not src?
Good question mate, either place should work. I just prefare to have it in that way
hi want angular version your used in this project do you have a folder structure for angular 17 and 18 I checked the latest angular version it have a standalone composennt and signals that application faster and better than previous angular version.
Good tips! Thanks for your sharing :)
Amazing vid!!!
Thanks for the awesome feedback mate and for watching! 🙏
what if all the components are standalone including app.component.ts? we must make standalone: false or remove it entirely?
Good question mate I’m going to do a video about standalone components and project structure
That is great. I do similar type thing in my project. what is your oppinion about account module have children module, Call AccountDetails module, so account details module contain just like account module(page, service, etc)?
I think that sub features as you explain is an good idea. You should have it in that way, but at the same time - keep it as simple as possible 👌
can i use the shared ui components inside the core module components, or is it just for modules/features
Good question mate. Core is usually connected to the app, therefore, we should add shared things into the shared folder
thank you @@DevBySeb
I thought the way you explained it was sensational. In terms of aesthetics, it is a completely clean code, can you tell me in terms of performance, would it change anything?
And talking about lazy-loading, how do I reduce my "main" in the final build, it's getting 2.4mb... would you have any examples?
Thanks for watching and the awesome feedback mate!
In terms of performance:
* If you utilize lazy loading - it will have a significant impact in terms of performance as it will only load things when the user hits a certain route.
* If you combine that with build optimization and three shaking - it may impact the performance in a positive way, I have a short video on how to achieve that here: ua-cam.com/video/NPsRXz5MOSg/v-deo.html
When it comes to lazy loading, etc, the build sizes will most likely be the same. However, with threeshakeability and build optimization - it might decrease the size of the build :)
How do you get 317k (gzipped: 91k) on the VSC ?
You can add an extension to vscode named "Import Cost" 😁
What are your thoughts on using standalone components with this structure
Excellent question mate. I love standalone components. The structure could be similar but with less files, and would be trivial for ui components and shared components. So its a good idea to use it where its suitable.
i got a question: which folder should i move my interceptors to?
Great question - if it's a core interceptor (one used for ALL requests on a global level) - I would add it under the core/interceptors folder. If it's a feature specific one, I would create an interceptor folder there e.g. feature1/interceptors.
If it's none of the above, its most likely a shared one - so under shared/interceptors (when it's used in some of the features but not all). Hope that helps :)
@@DevBySeb thanks a lot
Nice bro!
Thanks mate 🙏🙏
What font vs code. Thank bro
If you have to explain to someone what the difference is between "core" and "shared", then it's a flawed model. Project structure should be self evident and not require any additional "explaining". Just like when you are building UI designs, there should be no "ambiguous choices" - any choices the dev has to make (where do I put this bit of code) should be automatic and unambigous.
Thanks for your feedback mate. However, I don’t agree with it. I believe it might be obvious what differences there are between the core and shared folders if you are used with that particular thinking 😃
@@DevBySeb Thank you so much for the video. This is really very good material.
But I need an example of the layout of different services.
If I understand correctly, everything related to the main layout (menu, header, footer) is located in CORE. If I have an HTTP service, which will be used by all other services, then we also locate it in CORE? If I have a service responsible for the appearance of toast (with errors or info) on the screen, do I locate it in CORE or in SHARED?