Large Angular Project Design Guide
Are you about to start developing a large angular project? Have you mastered the basics but not sure how to structure a huge app with more than just a few screens? Then you need to read the Large Angular Project Design Guide. Most design guides, or examples to get you started, are for really small projects that put all the views and controllers in separate files. But when building large applications it is best to organize files by feature. When you open our app/account folder for example you know all these files are dealing with a users account. Much easier then making a change to the accounts view file then having to open a different folder containing controllers, and then having to guess what the controller is called. Same for searching for the account css file, or even worse combing one big css file for its classes. Following this guide and implementing your own standards can make developing with a team so much easier.
The Large Angular Project Design Guide
When creating a new controller, service, or directive it is best to place that code in its own file. That way if it needs to be changed or used elsewhere it can easily be found. For example, if there are two controllers using one service. And the service is defined in one of the controllers, say controller ‘A’. And now controller ‘B’ or another added controller needs a change in the service. How can another developer quickly locate it? Our solution was to put all services and directives in their own folder. And all the controllers and views are placed in their own folders based on feature.
Controllers – Each View has a controller, most controllers are responsible for one view but can have more if the views are similar and share functionality. As seen under consent_management folder. Controllers should be as slim as possible and only have functions that support the view. A controller that tries to do too much, like fetch data, is over exerting itself. Making the code longer and harder to manage and not reusable. Any code that is not directly manipulating the view or could be useful to other controllers should be made into a service.
Services – Services are meant to do the heavy lifting for controllers. And they should have very specific roles, such as handling data, validation, or storing sessions. Notice that these functionalities are needed by multiple controllers, so it makes sense to separate them from a single controller for code reuse and cross controller communication. While angular has Services and Factories, which are both singletons and essentially can accomplish the same thing with subtle differences, you will mainly use Services. Factories allow you to use the new keyword to create objects. So only use Factory if you need to create a bunch of objects life a factory in real life does, else a service will suffice.
Directives – Directives are where angular gets a lot of its power. Since directives can be used by multiple views we separate them into their own folder. A directive enables you to teach the browser new elements or controls. You can condense a lot of html and functionality into one html tag that can be used anywhere throughout the application. A directive has unique scope options, an html file as a template, its own controller, and even a link function that gets called once when the directive is instantiated. If you have a view that requires a unique UI control, especially if it can be useful elsewhere, consider making it a directive.
Angular Hierarchy Explanation
Content – The content folder is for any static content we add to the application. This includes images, global css, bootsrap, fonts, themes, and language files for internationalization(i18n). Language files could be delivered by the server as a web service.
Scripts – The scripts folder is where we store all of the third party libraries. This includes the source version for development and assisted debugging, as well as the production ready minified versions. Since these are third part libraries no custom coding should be done or added here. In other words these files should never be touched!
SDK– The software development kit folder will be used for features that can be reused for other applications. Few examples are log in and registration. If another application is to be made that uses Web Services or login credentials then instead of re-coding log/registration forms and services again they can be taken from this SDK.
Angular is built using a subset of JQuery, it is not required as angular already has included in its core what it needs. However if you Include jQuery before Angular it will use the full jQuery Library and get some extended functionality. It may be beneficial to know jQuery, however it can also cause confusion when making an Angular App. Meaning you may be tempted to use jQuery directly in code but this is not the “Angular” way. A true Angular app has everything it needs to accomplish what jQuery already does. So it is best to avoid jQuery in your code and find/learn the way it can be done in Angular. Which would be to use directives, jQuery if needed should be wrapped in a directive, but that is another topic. Extra Reading and Documentation on jQuery can be found at https://jquery.com/