Angular Master Class in Freiburg
Join our upcoming public training in Germany!Get a ticket →
With the release of version 1.3, the Angular project comes with a new module called angular-hint, that makes debugging and finding mistakes in the code base easier. It also gives us hints about best practices, so that our code is more maintainable and easier to read. In this article we’ll take a brief look at this module and explore how we can actually use it and what great features it provides. As a side note, this is the third article of our “Exploring Angular 1.3” series, so you might want to check out our articles about ngModelOptions and one-time bindings too. Okay, let’s dive into the actual topic.
TABLE OF CONTENTS
As already mentioned,
angular-hint helps us writing better Angular code and makes finding very common mistakes in our code base easier. For example, did it ever happen to you, that you developed your Angular app, you grabbed a module from somewhere, then you started using the directives that the module comes with, and no matter how much you followed the usage instructions, it simply didn’t work. And after one hour of debugging you found out that you forgot to add the module dependency to your application. Yikes!
But let me tell you something. With
angular-hint, these times are over. And that’s just one use case where
angular-hint helps out. In fact,
angular-hint comes with a couple of other sub modules for particular use cases.
These modules are:
- angular-hint-controllers - Warns about use of global controllers and hints about best practices for controller naming
- angular-hint-directives - Hints about misspelled attributes and tags, directives and more
- angular-hint-dom - Warns about use of DOM APIs in controllers
- angular-hint-events - Identifies undefined variables in event expressions
- angular-hint-interpolation - Notifies of undefined parts of interpolations chains and suggests available variables
- angular-hint-modules - Identifies missing module namespaces, undeclared modules, multiple uses of
Let’s start right away and see what the usage of
angular-hint looks like.
Install and using
angular-hint is super easy, since all we have to do is to install it via npm, embed the source in our application and use the
ng-hint directive that takes care of the rest. Alright, so let’s install the module via npm:
angular-hint module declares all the sub modules (
angular-hint-controllers, …) as dependency, so you don’t have to care about installing them manually. The command above does the job for you. Also, the package comes with a pre-compiled
hint.js file that contains the source of all mentioned
angular-hint-* modules, so you can use it right away.
Once it’s installed, we can embed the source in our application right after Angular itself like this:
Next, we apply the
ng-hint directive in order to actually use the
That’s it. We’re done. It’s that easy.
ng-hint directive to our document takes care of injecting all needed hint modules in your apps bootstrap phase. But how does
ng-hint know, which hint modules we actually want to activate? By default,
ng-hint injects all the mentioned hint modules. However, if we don’t want to get controller related hints, but are interested in DOM related hints, we can restrict the use of hint modules by using the
ng-hint-include directive instead. The following code only injects
We can even define more than just one hint module if needed:
As you can see, the names used as value for
ng-hint-include map to the suffixes of the actual hint module names. E.g.
directives map to
Okay, so now that
angular-hint is installed, let’s try to reproduce the “I forgot to add module dependency” scenario we were talking about. To do that, we declare an additional Angular module that act as our app dependency. For simplicity’s sake, we don’t add any ground breaking functionality here.
Next we take a look at our actual app module definition. As you can see, we declare the module without any further dependencies a.k.a we simply forgot it.
Now, instead of fiddling around for an hour to find out why
myAppDependency’s directives aren’t picked up,
angular-hint is telling us that we might missed something. Simply open your browsers console and you should see something like this:
This log occurs whenever an Angular module is present but not declared as dependency anywhere (You might see another message says that
ngHintModules was also created but never loaded. This is a probably a bug and filed here).
There are a couple more things that this module tries to warn you about and you can read about them here.
If there’s one thing you should embrace when working on a bigger Angular app and especially when working in a bigger team, are best practices. The Angular team published their style guide for apps built with Angular internally at Google, that covers best practices and conventions.
One of these best practices is, when naming controllers, to suffix them with
Controller instead of using short names like
angular-hint helps with that too. Let’s take a look what happens when we define a controller with a name that doesn’t have this suffix:
Having a controller registered like this,
angular-hint gives us the following warning:
I think this makes pretty much clear what can be achieved with such a tool. Having a style guide with conventions and best practices that everybody agrees on, makes a projects structure easier to understand and debug. With
angular-hint we actually have a tool to embrace and encourage these best practices and conventions and this is just the start!
When dealing with directives, there are a couple of things that can go wrong and stop us from being productive because we have to debug (once again) why a given directive doesn’t seem to work. Similar to the example where we forgot to add our module dependency, it also happens quiet often, that we misspell directive names. When a directive name is misspelled, for Angular, this is just an attribute (or element) that it doesn’t know about, so it gets completely ignored.
Just take a look at this small snippet:
As you can see, there’s a typo in the directive name. We actually wanted to type
ng-repeat, but we typed
ng-repaet. I can easily remember the last time, when I was debugging for an hour because I just misspelled a directive name. Because literally nothing happens.
angular-hint is activated, we get the following very useful warning:
How cool is that? Not only that
angular-hint warns me about an incorrect directive name and on what kind of element it is applied, it also suggests me a directive that is actually registered and to use! And now think about how much time you can save with such a helper.
Even if we took a look at just a few of all provided
angular-hint modules and features, I’m pretty sure you get an idea how useful it is. Of course, it’s still in early development and has one or the other bug here and there, but the initial idea of having such a module that you can easily apply and tells you about all your possible mistakes, is just awesome.
And again, this is just the start. I can’t even think of all the possibilities we have when extending the hint modules with additional functionality and hints. I could also imagine that this module could help out migrating from 1.x to 2.x in the future once the APIs are stable.
However, you should go and try it out in your apps today. If you find any bugs, make sure to file them at the dedicated repositories on GitHub, or fix them directly and send a pull request. Also, don’t hesitate to come up with new ideas on how the module could be extended. It’ll make all our lives easier!
Get updates on new articles and trainings.
Join over 1400 other developers who get our content first.
Futuristic Routing in Angular
An this article we discuss the new router APIs and how it's going to change the way we implement component...
ngMessages in Angular 1.3
In this article we're going to how the ngMessages module improves the way we handle validation messages when dealing with...
Go fast with $applyAsync in Angular 1.3
Angular 1.3 comes with a feature to share a running $digest cycle across multiple XHR calls. This articles details how...
Validators Pipeline in Angular 1.3
In this article we discuss a newly introduced feature called custom validators, so we don't have to hijack parsers and...
Binding to Directive Controllers in Angular 1.3
In this article we are going to take a look how to bind values to directive controllers to make them...
Disabling Debug Info in Angular 1.3
This article details how to give your app a performance boost in production environments with just a single line of...
You might also be interested in
Exploring Angular 1.3: One-time bindingsRead more
Exploring Angular 1.3: ng-model-optionsRead more
Exploring Angular 1.3: Stateful FiltersRead more
Exploring Angular 1.3: ES6 Style PromisesRead more
Exploring Angular 1.3: Disabling Debug InfoRead more
Exploring Angular 1.3: Binding to Directive ControllersRead more
Exploring Angular 1.3: Validators PipelineRead more
Exploring Angular 1.3: Go fast with $applyAsyncRead more
Exploring Angular 1.3: ngMessagesRead more