Planning to write an application in AngularJS? Post to help you
![](https://habrastorage.org/getpro/habr/post_images/69a/dbc/39c/69adbc39c2886a2070b47e1e54f2910a.png)
In this post, I will address the issues of designing an application on AngularJS, philosophy, its architecture, assembly, and walk through various useful libraries and ready-made architectural templates. To top it off, I'll arrange a small Angular + Require.js + Grunt + Yeoman orgy, which I called an Angular-Super-Seed or a slightly more modest ASS generator .
So if you plan to write an application in Angular, then why not?
Motivation
- "Treat people as you would like to be treated." Suddenly someone will come in handy
- Learn something new about yourself and about development in the comments.
- Promote your app generator ASS .
What does an Angular application consist of?
Provided that the Angular application does not consist of services, controllers, directives and templates?
That's right, an Angular application consists of modules and only modules.
Ok smartass, what are the modules made up of?
But the modules, in turn, can already consist of services, controllers, directives, services, providers and templates.
Services
Services is perhaps the simplest component in terms of its application. What is it for? In most cases, the service is used as a Model in MVC theory, that is, for working with data. For example, you can create a user service $ user for storing data in cookies or local storage. Or the $ api service - a wrapper for the library $ http that will interact with your server API. But the service can be processes that are executed by the background, and just libraries of objects, functions that you plan to use in different places of the code.
...
.factory("$user",function($rootScope, $someLocalStorageService){
var user={
id:null,
name:null,
isAuthorized:false
}
if($someLocalStorageService.load("user"))angular.extend(user,$someLocalStorageService.load("user"));
$rootScope.$watchCollection(function(){
return user;
},function(user){
$someLocalStorageService.save("user",user);
});
return user;
});
In this example, the service is both a model and a background process that monitors the changes in the object and immediately stores it in local storage.
Now a few words about where you can work with these services.
Controllers
In controllers. We abstract from the methods of calling controllers and turn to the essence. And their essence is simple to connect the work of services. And only in this, although most often it seems that the controller serves to link the display (/ layout / DOM / HTML) with the data. And in principle, it was originally so. Previously, you could in the controller using this to access the data that is used in the template.
...
.controller("SomeCtrl",function(){
this.var="холли вар";
});
...
Святой {{var}}
But the shop was quickly covered up, and now, to access this data, you need a special $ scope service. Therefore, we write: “controllers are a structural component that is used to implement interaction between services . ”
If I were a teacher taking an exam with a student, I would not say better. But, if you face the truth, then in 99.99% of cases, the controllers will be used by you precisely in order to connect ui with the data processing logic.
Directives
But for how to link, these same data with layout are responsible for directives. About the fact that working with the DOM in Angular should be done only in directives, a lot of words are said, therefore, if you are asked with the question “-And can jQuery be called in the controller”, answer “-Yes, of course,” and when it unfolds and satisfied will start to leave, calmly shoot at the back of the head.
What is the relish of directives? That you can very simply bind logic and data to ui elements. In principle, if you set yourself such a goal, then you can completely forget about such a term as a selector.
What is a directive? Something attached to the DOM element. How tied? As a tag, as a tag attribute, as a tag class.
And this, in my opinion, is the whole essence of Angula. Routing, data-binding, framework - all this was already before Angula in different frameworks. But I have never seen such compactness and simplicity of designing ui.
Build issue
Why is it needed? So that when you load a page on production, you have not hundreds of connections for downloading project files, but, ideally, one. That during development there was no need to register the added files with pens.
For a long time in large projects and teams, it was solved with the help of self-written tools, now there are Grunt / Gulp plugins for this. And there are several aspects. The essence of these plugins is that all your scripts / styles are sewn into one. So you need to write down rules / dependencies, etc., how to sew these files somewhere. It will be inconvenient to do this in the code of the files themselves, which means that you need to create additional package files. But that is not all. Obviously, this stitching should occur after editing the project, when you want to test the result. And here are two options either to update with pens by calling the appropriate command, or to make the so-called watcher - a script that monitors all your files and builds. In principle, the option is not bad, but when working on a large project, you can get the expected performance problems.
Therefore, I personally am a supporter of Require.js . Why? Well, firstly, dependencies are written in the code, secondly, when developing the browser itself will load all the necessary files and no sewing is necessary, and thirdly, when it comes to production, all your files will be compressed into one and, if you want, minified.
Therefore, the question of assembly is a question that everyone decides for himself, whether it is needed or not, and what tools to use. The main thing that plays a role in solving this issue is architecture.
About architecture
Here I recall again that the application consists of modules. Therefore, when you are planning the architecture of your application, you should figure out how many modules it will consist of. It can consist of only one module or vice versa to have a separate module for each page of the site. What does it depend on? Firstly, from your desire to split even a small application into modules. Secondly, on the size of the application. To make it clearer, here is the condition.
(boolean) Буду ли я разбивать проект на модули = (boolean) Я разбиваю любые проекты на модули || (boolean) Проект большой
Well, it’s not unimportant how you are going to test your application. If you want to run tests separately for controllers, services, directives, then it is clear that you will need to place them in separate modules "App.controllers", "App.services", "App.directives", etc.
But as for architecture, it is always nice to look at how others do.
NGBP
LGBT people just assume that your project will consist of many modules. The application has a main module that describes routing and other initial settings, and the rest of the logic is distributed among the components .
What catches your eye? That all your controllers, services, directives, etc. should be described in one module file. And although I personally am a supporter of simplicity, but even in my opinion this will already be too much. And this is in my opinion the main disadvantage of this template.
Angular seed
In my opinion, great for small to medium sized applications. Although the project consists formally of several modules, this is just the case when the controllers, services and directives come together, so from an architectural point of view, we can assume that there is only one module.
The advantages are obvious - everything is simple, clear and compact. Cons, too - if you are doing a large project in a large team, you will be cramped, in addition to everything, the assembly and minification of the application is not provided.
Angular-require-seed
If you liked angular-seed, but want to use require, then please use . Pros and cons are the same as Angular-seed. It is possible that by using require.js it will be easier for you to compile your project, but this is if you use the require-optimizer
Angular-super-seed
Reflecting on the architecture of the application, on the topic of what is missing and what else to offer the community, I came to this result .
What is the feature? You can split your project into modules, or you can limit yourself to just the main one. In terms of storing controllers, services and directives, I went even further. All of them are stored in separate files. Moreover, a separate template and a separate stylesheet are created for each directive .
Component modules are defined and described in a separate file as well .
The obvious drawback of this approach is that when creating each new controller / service / directive, you need to perform a bunch of routine operations to declare them. That is, you want to create a new directive: create a directive file, a template file, a style file. Not deadly, but can be fed up. And here it is time to say YO ASS!
Yeoman
When I first visited the Yeoman website, I didn’t appreciate the service features. Well, can you create separate files according to certain templates. Well, this is what I can configure in the editor.
But when I thought about the fact that it would be nice not just to create separate files, but also to perform some other operations, it was then that I looked at a comrade foreman.
As a result of what such a generator turned out .
We put Yeoman
npm install -g yo
We put the generator
npm install -g generator-ass
What is the buzz? In what you can do in your console like this:
yo ass
And a new application will appear in your folder. Well, then more.
yo ass:page main
Automatically create a new template for the page, a stylesheet, a controller and plug it all into the router.
Create a module
yo ass:module first
The module is ready and already delivered turnkey .
And now let's create a directive in it
yo ass:module firstDirective
We answer the question, in which module and everything is ok.
I must say right away that there is not enough testing and moqs yet. All will be.
That's all, I hope someone comes in handy. Why not?