Lessons learned: Year with a big project on AngularJS

After a year of working with a large project on AngularJS, I think to share some lessons learned in the process. First, I like Angulyar. It perfectly satisfies my needs and, I think, fully switch to it in the foreseeable future, when I need a reliable framework for a one-page "fat client." He is awesome. The world-class team is working on it, the community is fantastic, and it contains (or offers the community) a combination of functions for creating web applications.

Code organization

The pile is small. At the very beginning, my application resembled a template project from the Angulyar site. A bunch of massive unrelated files containing too much code. We have moved from John Reasing's “ Inheritance of Simple Classes ” to separation into separate functional blocks. This approach works well as long as you maintain a small depth of inheritance in your project. We were also bothered by the structure of massive folders containing various types of classes and resembling a “box with dirty socks”
')

  - project
 - controllers
 --- someController.js
 --- someOtherController.js
 --- ...
 --- someController99.js 

An example of a folder with controllers makes the brain. My new rule is: if you catch yourself thinking that you are going through the alphabet in your mind to find a specific file, then there are probably too many files in the folder.

Now I would start building my project in a more modular way. Each separate part of the functionality or functional area contains basically only those files / classes / objects that it needs. In an ideal world, these modules will be completely separate and can be used in other projects as reusable “meta-components”. This is difficult to achieve, sometimes because it will probably also require a set of common utilities, helpers, or other similar files on which your modules will depend. If reuse is not a prerequisite, I will not spend a lot of time on the absolute separation of everything and everything, but when the bar rises, then think about how to do it.

Cliff Meyers wrote a great article on organizing code in a large application on Angulyar.

Stunning and powerful directives

Now I am of the opinion that the directives are a deadly feature of Angulyar. These are great small packages containing user interface logic. The ability to extend HTML syntax makes them very flexible and powerful. We definitely use directives, but perhaps not as often as we could.

One of the favorite properties of Angulyarovsky directives is the ability to build. Setting them as HTML attributes, you can use directives to create complex widgets with multi-level functionality. The reverse side of the medal appears from time to time, when the functional levels try to compete with each other, but in general the directives are amazing.

If I started the project today, I would pay attention to some serious thoughts about the organization of directives, visual components and behavior. There are already several projects in which popular visual-oriented frameworks are wrapped in Angulyar directives, but it’s not at all necessary to think about how to use this entire full-scale set of components. What are the main components of the application? How to design directives so that the main components would be common to the whole application, and not in bulk with HTML and CSS copy-paste. How can these components be used for future work?

If you haven’t seen a video about them yet, then run on John Lindquist’s egghead.io and watch the series on directives. All videos are excellent and the guideline story is instructive.

Know your framework

Since I started this project, I certainly dig for a while in the entrails of Angulyar. The source code is easy to read and well tested, so reading for Yavascript will be fascinating .

While digging into it, I tried as much as possible to get acquainted with its device. Many things still remain a black box for me, and despite the fact that I trust the developers, I still feel the need to understand what happens during the creation of applications. Now this is one of my immediate goals, so I hope in the future I could tell you something about how Angulyar works under the hood.

Leaving aside, I feel compelled to do the same with Jikveri. So much code, so little time.

Assembly

Unfortunately, in this project we were obliged to use Maven and JAWR for assembly. It was a real struggle, and we simply could not carry out a “decent” assembly. We were able to put together some tools to help the transition, but I do not recommend using Maven for the frontend.

If I started a project today, I would definitely use Yeoman to easily create templates and make life easier.

CSS

It is not directly connected with Angulyar, but is another important aspect of the Angulyar project, so I would like to spend some time on it.

I admit that a year ago my attitude was “f CSS” (f - two). He scared and drove me to such a degree of disgust. Obviously, it derives from ignorance, and I spent the last year trying to play with the CSS layout. My attitude is no longer “f CSS” and sounds more like “SCSS” (s - three), because I found a place where CSS and I can live happily.

The syntax of “ SCSS ” covered many pain points in my brain with simple CSS and greatly increased the level of clarity. In addition, Compass adds a bunch of mischievous impurities that eliminate a completely new kind of pain from working with styles.

In the future I want to delve deeper into SASS / Compass by combining their expressive style capabilities with the modular and component level of work in Angulyar, outlined above. I would like to use a more organized approach to style sheets , something like SMACSS providing a basic standard that explains how to work and organize styles.

At the moment, CSS and I have completely reconciled. I overcome my ignorance, which obviously became the key to building a strong relationship. We'll see how it goes. Once at a time.

Conclusion

If you create a one-page web application, Angulyar is a good choice. It is important to decide on the structure of the application as early as possible. Decide how to break your code into modules and components so that you can use the full power of the directives and maximize the potential for reuse.

Comment on the article can be left on Hacker News , if you want to participate in the discussion.

PS For the Russian-speaking audience, comments, of course, here :-)
PPS Original article