A few months ago, I finally had a chance to get my hands on the so-much-talked-about AngularJS framework and I really digged it. In fact, I like it so much that I am 100% sure this framework will stay ahead of others for a long time. Well, in our world this means for at least another year or two.
Though, I’ve got the basics down fairly fast, I had hard time around understanding the proper code organization. Being a perfectionist didn’t help either. Coming from a very opiniated Rails framework it didn’t feel comfortable at first that AngularJS gave significantly more freedom to do things. But thank God the “Rails magic” is gone!
The type of questions that kept poping up in my head were:
- “OK, I want to code this functionality, but where shoud I really put it”?
- Should I stick this code into a View controller, or should I put it into a Service?
- Perhaps, a directive could be a good place for it, but then where exactly in a directive?
Doing my googling I’ve realized there were plenty of other pilligrims like me trying to find their way in this new and exciting AngularJS world.
So, I am putting together this cheatsheet hoping it will guide us on where the stuff should really go. It’s not meant to be detail, but it should give you the right starting point depending on what you are trying to achieve.
|Use Case||App Component||Angular Component||Examples||Notes|
||Non-configurable Application Service||Factory||
|These are generally referred to as `application services` or simply `services`. Do not confuse it with the name of AngularJS `Service` component that we've excluded from this post for simplicity.|
||Configurable Application Service||Provider||
|Examples of such configurations may include setting Facebook application id or an API key for accessing geo-location service.|
|Keeping view logic in application controllers makes them eventually fat. Recommend placing it in the view service instead and have controllers simply call these view service methods and process their responses.|
For anything more than a trivial implementation, I recommend using
js-data-angular instead of the built-in `$resource`.
|Keep controllers thin. Should mostly contain calls to methods in an application service or in a view service.|
||DOM Template Manipulator||Directive
|Rarely used1. Does not have access to scope.|
||DOM Instance Manipulator||Directive (link function)||By link function I mean the `post-link` function|
||DOM Service/API||Directive (controller)||A directive controller can be written inline as part of DDO or injected via DI. Another directive wishing to access controller methods of a given directive needs to explicitly require it.|
|Cannot be injected into the `module.config` phase, but can be altered by a `Decorator`. Examples could include an object that tracks currently logged in user properties or any other object, properties of which you want to access in various parts of your application|
|Besides controller and a service, Constant can also be injected into the `module.config` phase. Constants cannot be altered by a `Decorator`. Avoid modifying the Constant. If you need an editable object or value, use `Value` component/provider instead.|
||Decorator||Decorator||myLog||If you simply want to replace an instance, then using `Factory` or `Value` component is musch simpler|
1 See example of how a compile function can be used.