Good Practices to Build Your AngularJS Application

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

#1 Structure:

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!

2) The other recommendation is to use yeoman (http://yeoman.io/) which is a tool that will basically create the skeleton and add other tools such as bower and grunt, which are widely used in the development of javascript applications according to the user preferences.

You need to be very careful with these tools that seem to be very useful in the beginning. Why is that? Because you need to think first on what your project needs are.  For example, angular-seed will create a folder named ‘app’ where all the static deployable files are and inside we will have a folder named ‘js’ with all our javascript files like ‘controllers.js’, ‘services.js’, etc…

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.

#2 Dependency Injection:

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.

#3 Extension of the HTML

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.

Sometimes, especially people that have worked before with javascript either pure or with other libraries like jQuery, want to create behaviour in the DOM with javascript. In this case, AngularJS already has many directives that can help us to not reinvent the wheel, and in case we don’t find something that meets our requirements, AngularJS invite us to create our own directives where the DOM manipulation would go.

The benefits of doing so are to have a single place where our DOM manipulation code is and also, to be able to unit test all these directives, since in many occasions lots of javascript code is not tested because is hard to test modules that involve the DOM.

#4 Scope

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.

3) do not create properties in the scope but object! It’s a common mistake to think that the scope is the model component that AngularJS talks about. In fact, the scope is just a way to bind our model with the template, so the model must be a javascript object, to use a simple property can and will give issues later on with the scope hierarchy.

#5 Modules

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!

Finally, please do keep in mind that these points depends a lot on the type of application we want to build, either the nature of the business, the size of the project or other factors that are unique in each project. For example, having different components in different files may not make any sense if we are just building a small module with very few lines of javascript code! Our advice? Always keep in mind your business needs and try to follow the best practices described! Good luck building!