Things I wish I knew about AngularJS before I started

If you’re anything like me, when starting with a new, exciting technology, you like to dig straight in. Docs? Who needs docs? I’ll just start bashing away and learn as I go.

Fortunately, I have done this for you and here is a list of things I wish I knew before I started with AngularJS. You’ll notice a lot of them lead on from the previous point, but I’ll try my best to stop myself from going on a tangent.

Notice: this is for Angular 1.*. I haven’t got round to working with Angular 2 yet, but I’m looking forward to it!

Difference between ng-if and ng-show

ng-show keeps the element on the DOM and doesn’t create its own scope. Think of it like a CSS show/hide.

ng-if removes the element or adds the element onto the DOM and creates its own child scope. It inherits the properties from the parent scope.

Inheritance

This bit may seem obvious to any seasoned veteran, but I didn’t even think about until I had some problems with scopes not behaving like I thought they would. In Angular, there is the “global” scope, i.e. $rootScope. It is bad practice to put anything in here, as putting stuff globally is a recipe for disaster. See this if you want to know more.

Inside the global scope, Angular creates child scopes. Say when you use a controller, this creates a child scope. This inherits any values from the parent scope. But if you change anything in a child scope, the changes stay within that child scope and are not propagated into the parent. But if you change something in a parent scope, it will change in the child unless the child has set the value to something else. See this as an example (Plunkr)

Services and factories

This is where I get a bit… blurry. I typically think of services as models, as you would in other languages (i.e. PHP). For example a user model would be a service called user. A factory is sort of a helper method. There really isn’t much difference between them, except factories return the object while services return constructor functions of the object. I’ll use a page factory and a user service as an example.

Factory:
angular.modue(‘app’).factory(‘PageFactory’, function () {
    return {
    // pretend that the title is set in the controller
        title: function () { return ‘Some title’; }
    }
});
Service:
angular.module(‘app’).service(‘User’, function () {
    // this would be a call to backend if the user doesn't exist in the cache
    this.get = function () {
        return { name: ‘Joe Bloggs’; }
    };
});

Naming conventions

You might’ve noticed that in the last examples, I affixed the factory with “Factory” and I didn’t affix anything onto the services. This is a good naming convention to adopt. It is totally up to you what naming convention you follow, but as a loose guide I follow this . You can pick and choose what conventions to follow but generally, it is best to stick with some sort of standard.

On the topic of naming conventions, before you dig into writing your Angular app for a client or business, do some research into directory structure. If you don’t, it’ll come back to bite you in the arse. Trust me!

ng-cloak

When you use the curly braces to render something in Angular, do you notice that you get the flashing of said curly braces before Angular gets the chance to do something with it? This is where ng-cloak comes in handy. Just add the class .ng-cloak to your elements to prevent this.

[ng\:cloak], [ng-cloak], [data-ng-cloak], [x-ng-cloak], .ng-cloak, .x-ng-cloak {
    display: none !important;
}

Even better, use ng-bind

Ng-bind is one of those things I knew about loosely about but I was quite happy to ignore until the problem of unrendered text became a problem. As a general good rule of thumb, you should try to always use ng-bind instead of curly braces. This also solves the problem of using a template renderer with your backend language (as they often also use curly braces to render things).

Example: {{ name }}

Would become: <span ng-bind=”name”></span> (or any other element you want to bind it to)

Always use properties of objects

Whenever you use an object, always use the properties of the object. It is considered best-practice to bind references by a property on an object. This is also better for performance as you’re updating an individual value, rather than a whole object.

I’ve most likely forgot about a couple of things. If I have, I’ll come back to update this list. As I come across new, quirky things I’ll update it also.