How to structure your Angular apps like a Googler

In this video, we take a look at how to apply best practice architectural patterns from Nx in a standard Angular applications.

0:00 Introduction
1:00 Key concepts
2:27 Smart components
3:51 Dumb components
4:42 Data access
5:17 Utils
5:48 Shared code
7:23 Routing
9:10 Conclusion

#ionic #angular #nx

[voidemon]

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)

[farrukh.]

we could make it more obsivous/simple by pulling out the "shell" content - routing.moduel and module to the feature folder iteself

[darwinwatterson]

Hi Joshua! What about core module and all of that stuff that u need to be initialized with your application?

[fwuymhw]

@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)?

[phucvuong]

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.

[claudiuciprianbetiuc]

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!

[lancetv]

Thanks josh, will try this folder structure on my next project.

[mikhailratner]

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 :)

[alexandrponomarenko]

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!

[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!

[leosconflicts]

Hi Josh, this is really a great video, but I do have a question about it the architecture that I haven't seen in any of your other videos wherever you talk about, how do you deal with shared features (features that depends on other features)? In the context of your video, let's say your "notes" feature can be associated with one or more clients, so somewhere in your "notes add" feature you'd have to show a list of clients from which the user can select from. How would that look like? Should there be a "client list" smart component for each feature that needs to use it? Should there be a shared service specific for loading data for this?

[theanswer]

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

[knotprasertsimla]

Great video!! But haven’t fully understand how to categorize Smart and Dump Component yet

[RePorcello]

So in general, ui/dumb components would never interact directly with ngrx (call to actions or selectors), this is a responsibility of the feature component. The page might be complex and made up of sub-features that might need to interact with ngrx. Should we add subrouted features? How would you handle it?

[balajibalamurugan]

Hi Joshua, what about model, interfaces, constants, directives and pipes

[Michals]

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.

[rastapoile]

Hi, I have two questions:

Where would you place the models? In the shared folder or directly in the feature folder?

Then, in the utils folder, are you talking about implementing simple export files of useful functions? Or a service?

Thanks!

[boris]

I don't really get what the shell is needed for, is it just used so that the smart components within the feature folder can be lazy loaded aswell? I guess this would be done with loadComponent with the current angular version and standalone components?