@voidemon490
Can't wait to implement this in my project that is due tomorrow. Thanks
@DmitryEfimenko
Great video! Thanks a lot for creating it. With Angular 14 being out, it is time to update it and replace the SCAM with the Standalone Components :)
@Emekaelo
Literally went through all comments because I'm obsessed with the proper way to do stuff like this. Yeah I understand recommended practices are not set in stone. I'm actually liking the structure as it encourages smart -> dumb hierarchy. A few tweaks I want to put out there for possible discussion is; # Feature specific (clients | notes)/feature: smart components, pages (clients | notes)/ui: dumb, reusable components (clients | notes)/shared/(services | models* | pipes | guards | interceptors) # Global files shared/(services | models | pipes | guards | interceptors): for files NOT NICHED to a feature and used globally, or if you can't pinpoint the niche yet and you just want peace so you can refactor later as the app grows and becomes clearer. shared/(services | models | pipes | guards | interceptors)/(clients | notes): files NICHED to a feature that are USED ACROSS THE APP. Something like a service that fetches clients in the notes page or in some other feature. *I sort of feel models should just always be in global shared folder and not in feature specific shared folder because the types and interfaces are likely used everywhere and it's one less thing to worry about (if this interface will be imported in another component in a different feature module)
@darwinwatterson1732
Hi Joshua! What about core module and all of that stuff that u need to be initialized with your application?
@farrukh.
we could make it more obsivous/simple by pulling out the "shell" content - routing.moduel and module to the feature folder iteself
@claudiuciprianbetiuc3985
Nice video! I guess that you would not use anymore the SCAM pattern for Angular 14 and above having the standalone components available but I am curious if I'm wrong or not about this guess. Also, what's the advantage of using SCAM? I don't think you mentioned this in this video. For example, why not have a single module that would group a whole feature ? (Possible multiple smart & dumb components, services, utils, .. ). Thanks!
@phucvuong165
I have serveral question. 1) Where do we put the pipe, directives, guard, interceptor, etc for each feature? 2) Is it right idea to use that same client store for these 3 features (detail, list, survey). 3) what if feature client detail have few features inside it such as client-detail history, cient detail info. Then would it be something like this. client-detail |- data-access | - feature |- - client-detail-history | - - client-detail-info | - ui I'm trying to understand Nx project architecture at scale.
@lancetv4826
Thanks josh, will try this folder structure on my next project.
@alexandrponomarenko4100
Thanks for your videos! What about shared data-access. What we gonna store there. Because as i understand your "ngrx-like" stuff is places inside domain's data-access. And also, how we can use some data-access stuff from domain A in domain B? Thanks!
@user-fw2uy3mh8w
@JoshuaMorony Thank you for your video. I was wondering how you handle deeper nested features in provided structure. Suppose that you have an admin feature that contains itself many features like a CRUD user feature. If I follow your structure, user-list, user-add, user-edit... would be modules. So the route "admin/user/edit/1" involves 3 lazy loaded modules (admin first, user second and finally user-edit). How do you handle such a case in terms of folder structure (and even worse when route is composed of more than 3 lazy loaded modules as in the provided example)?
@TheSaceone
Hi Joshua! good video, I think it was needed, it is a very well explained basis before watching your other architecture videos. Very interesting! Thank you!
@mikhailratner4649
Amazing! Are there other structures which you could recommend? It would be great to see alternatives. Also, if you are in need of a quick video idea, you update the video to implement Angular 14 Standalone Components :)
@victornjg
Great video! I'm starting a new project and I'm definetely going to use it. But I have one question, let's imagine that all notes features will share the same layout, and therefore you want to render all the features (list, detail, etc) inside that layout using a router-outlet, in that case would be OK to have a notes-shell component containing that layout and also the router-outlet?
@Andyg471984
Hey love the videos and really like this file structure. Using the structure, how do I organise a nested route? So for instance products->id but the detail page has a nested router outlet to show different data on the page depending on the child route so, products->id->child_route_1 or products->id->child_route_2
@balajibalamurugan8053
Hi Joshua, what about model, interfaces, constants, directives and pipes
@theanswer1993
Is it intended to nest the features as well? For example if every feature is representing a path in the URL how would you create a structure for something like: /lists/1/item/edit/2
@Michals0199
If I need another smart component that will be used for example in client-details component, do I put it as another feature but I do not route it? I'm trying to learn SOLID so it kinda bothers me to create one smart component that will do many things.
@dennistucker2138
Do you have a demo project with example code? I would like to see how UI works with this project or how routing works.
@biosgl
Interesting, for the shell routing modules, wouldn't it be cleaner to call it 'client-routing-module' instead and maybe keep it in the root folder of that feature?
@JoshuaMorony