#1 Structure #2 Dependency Injection #3 Extension of the HTML
#4 Scope #5 Modules
A team of us in the Porto Alegre office has been using AngularJS for a while now, and it has been learning curve. We want to share some practices that we have learned along the way that can help you start your AngularJS application on the right foot!. Learn from our mistakes!
This article has no intention of setting rules or having the absolute truth but only to give some useful tips and lessons learned when writing AngularJS applications.
Here are some good practices for AngularJS applications separated in five categories:
When we start to build an AngularJS application sometimes we don’t know exactly how to organise our files or even know what files we need. For this, the AngularJS team recommends two solutions:
1) Use the angular-seed (https://github.com/angular/angular-seed) project, which is basically a skeleton of a typical AngularJS application. You just need to clone the repository and you are good to go!
It depends a lot in the nature of the application we are building but there will be cases in which it is better to separate files for what they mean for the business rather that having them for what kind of component they are inside the framework we are using. In this case, for example, if we are building a sales module we could have files like ‘product-controller.js’ or ‘product-service.js’ and have folders inside our ‘js’ folder with the modules of the business.
The AngularJS injector is pretty powerful and can be very useful if used correctly. It’s in charge of creating components, resolving their dependencies and providing the components when required.
What benefits do we have when we use it?
One of the greatest benefits is given when writing tests for our application! If in each component we create, following the AngularJS syntax, we can require other components and it will take care of resolving these dependencies for us, then when creating our tests we can just simply create these same components but with dependencies created by us (mocked objects), then we are able to really unit test our application and have a good coverage.
The creators and developers of AngularJS have made clear since the beginning that AngularJS is not a framework to write code that modifies the DOM. Usually we can find other ways when we want to do this and AngularJS teaches us that the extension of the HTML is the answer.
How do we accomplish this? Through Directives.
Regarding the object scope that we have in AngularJS, we have three simple rules:
1) the scope must be write-only in the controllers, meaning that the controller is in charge of using another component, like a service, to get the data that the template will show and write this data in an object of the scope.
2) the scope must be read-only in the templates, meaning that even if AngularJS allows us to write code that modifies the scope in the templates, it’s something that we must be very cautious about and probably shouldn’t do.
AngularJS allows us to organise our application through modules that are basically containers of some part of our application. Just like there is no rule or standard of how to modularise the application, it must take into account the nature of the business rather than the different components we create. But what does it mean?
Sometimes when we start to play with AngularJS we think is a good idea to create different modules, for example, for our controllers, services, directives, etc…but this may not be the best option. For example: let’s say we create a controller inside a module named ‘myapp.controllers’ and this component depends on a service that is inside the module ‘myapp.services’. When we want to use that controller in another application we will have to not only require the controller module but the service one too and any other module that is as a dependency. However, if we have a login module and we create controllers, services, directives, etc under the module ‘myapp.login’, then later on when we want to use that module we will have everything we need to use to it without needing other dependencies.
These points are maybe not so clear in the beginner documentation or in the examples on the Internet when you start creating your AngularJS applications but are pretty useful. If they are considered at the beginning of the development, it will result in a well-structured application following the conventions that the developers of AngularJS practice and share!