Although AngularJS has a gentle, initial learning curve, the powerful and flexible framework relies a lot on developers’ skills and understanding of the framework to produce well-engineered and maintainable applications. This hiring guide offers a set of insightful questions to help you identify amazing AngularJS developers who are experts in their field.
AngularJS is the framework of choice for multiple high-end web applications. The reason many teams choose this technology is because it is flexible and powerful, seems to evolve in the right direction, has a great community, and has countless extensions and integrations.
There are also many Angular developers. While starting out with Angular is fun and building small single page applications is not very difficult, maintaining even a small app can be tough. Until today, a large number of good practices and advanced techniques have been documented and discussed, and some high-quality standards have emerged.
Our hiring guide will help you find developers who strive to follow that high-quality approach. It is the one that results in great applications which attract clients. In this guide, we will cover concepts relevant to scopes, the digest loop, services, testing, and more.
Working with Scopes
Scopes are the data-model of Angular apps. They are the single source of truth in the app, and should be bound and handled with the greatest caution. There are many caveats in dealing with scopes. We will describe a few significant ones below.
Q: How does scope inheritance work in AngularJS? Describe the various ways for data to be passed into a scope.
Scope inheritance in AngularJS is prototypal for child scopes, but not for isolated scopes. Core directives, which create a new scope, use the child scope option. Those scopes have access to the models set on the parent scope. Accessing parent scope models works seamlessly for objects, but when trying to write to a primitive model (e.g. a string), a new model will be created on the child scope. The model on parent scope will be masked, or shadowed.
When building custom directives, it is possible to create an isolated scope. Isolated scopes don’t have direct access to their parent’s models. Still, bindings can be set manually by specifying them in the directive’s scope property object. In such a case, data can be passed into the directive through HTML attributes. That supports both two-way and one-way bindings, and also expression bindings.
Directives also have the ability to transclude scope onto contained elements. When using transclusion manually, it is possible to create a cloned scope - one that would keep all the properties of the parents, but would lose all the bindings. That feature is not very well documented.
At this point, it seems very important to note that it is possible to traverse scopes, in all directions. Every scope has a $parent property (“null” for root scope), and also childTail, nextSibling properties. It is possible to communicate between scopes using those properties, though it may be difficult and also not a good practice.
Q: What exactly are controllers? What is their lifecycle and relation to the scope?
Controllers are classes, that is, constructor functions, which are bound to a scope AND a section of HTML through the directive “ng-controller”, routing, or through a directive. Setting a controller creates a new scope (child scope). The controller’s purpose is to set up the initial state of the scope and also manipulate it by adding behaviour, setting watches, event listeners, etc.
Even though at first controllers may seem like the primary ground of operation in AngularJS, once the developer truly understands the purpose of scopes in AngularJS, their use of controllers will minify. It is not optimal to perform calculations directly on scope models, as those might be watched, and in effect may trigger and slow down the digest phase. The motto that transcends MVC frameworks — “keep controllers thin” — applies very well to AngularJS.
Working with the Digest Loop
The digest loop is used to keep the DOM in sync with the models set on the scope. In Angular, running into issues around the digest cycle is common. A deep understanding of the digest cycle is much less common.
The developer being interviewed should be familiar with what the digest cycle is and how it works. The requirement for that knowledge will emerge sooner than later when building a large application. The questions below will help you assess their level of proficiency.
Q: How does AngularJS know when to perform dirty checking and update DOM output?
The answer is short — when it is told to do so. The point is, there is no polling mechanism that would trigger dirty checking automatically. Core AngularJS directives, services, and methods usually set up watches, or fire the digest cycle explicitly. That process is executed internally, it is not exposed, and may not be obvious to the developers. In fact, there are articles which contradict the facts, falsely stating that there is a constant heartbeat in AngularJS. There is no such thing.
Manipulating scope models using non-core functionality requires the developers to manually trigger the digest cycle. In most cases, that is done by using the scope method “.$apply()”, which triggers a digest on the root scope. That phase propagates down to every child scope.
Without anything triggering digest, the dirty checking will not happen. The callbacks to watches will not be fired, and DOM output will not be updated.
Q: What is the difference between “.$apply()” and “.$applyAsync()”? Why would you choose one over the other?
The main difference between them is that the latter happens on a 0 timeout. The actual delay is about 10ms. Consecutive “.$applyAsync()” calls cancel the previous timeouts. The point is that for multiple “.$applyAsync()” calls, there will only be a single digest trigger, and not one for every call. That would be the case with the regular “.$apply()”.
At this point, the reason should be obvious — the main concern is performance. Applying a certain change to your scope, only to redo or change it again in a fraction of a second can often be redundant. $applyAsync() helps avoid that.
Q: What is the difference between “.$digest()” and “.$apply()”? Why would you ever call “.$digest()” on a scope?
There are a few differences. First of all, “.$apply()” takes an argument, an expression, and evaluates it against the current scope. “.$digest()” does not take any arguments.
Secondly, “.$apply()” calls “.$digest()” on root scope. That digest will propagate down through every child scope — it will eventually affect every scope in the application. Calling “.$digest()” directly on a scope does not affect any scope that is higher in the hierarchy. That means that any watches set on parent scopes will not be evaluated.
Again, the reason why a developer might want to call “.$digest()” instead of “.$apply()” is performance. It can be safely done when working with isolated components, e.g. widgets, that don’t communicate with the rest of the app. More precisely — when it is known that no models set on parent scopes will be affected.
However, it is not a common practice. As a rule of thumb, the use of “.$apply()” is preferred and expected.
Services in Angular are where the business logic is kept. Even in core Angular, there is more than one (even more than two) supported ways of creating services. The style guides have a lot to say about optimal approaches in dealing with services. The engineer you consider hiring should too!
Q: What are services in AngularJS? When are they initialized?
Angular services are singletons — there is only one instance available during an app’s lifecycle. Angular lazy loads its modules, so all services become available after they were injected into a “run()” block, or into another module (which of course needs to be initialized too).
Providers become available prior to that, as they can be readily used in “config()” blocks. Their core functionality is still unavailable at that time. It can be manipulated though.
Q: What means of HTTP communication are available in AngularJS? Describe and explain the differences between at least two.
The two core services for Angular that deal with XHRs are “$http” and “$resource”. The latter actually needs explicit installation, while “$http” is readily available.
“$http” is a low level module, which already provides a lot of functionality, but using it with a RESTful API might lead to duplication of code, and is somewhat primitive. The module can be used for communicating using XML HTTP Requests or JSONP. It is rather simple to use.
“$resource”, on the other hand, is a high level service built on top of “$http”, designed for communicating with RESTful APIs. It was built to deal with standard server-side resources. It provides a rich api, allowing the declaration and reuse of multiple defined parameters, even ones which can be used alternatively on the same path level. It provides standard actions (except for “update”, but that one is described as an example in the module’s documentation). It also allows new actions to be defined.
There is a common ground for both “$http” and “$resource” — the “$httpInterceptors”. More about those in the next section.
A third alternative is Restangular. Restangular is a contributed module, and was built as a substitute for $resolve. It has a different, rich API, operates primarily on promises, and is supposed to have an easier syntax. In fact, developers consider $resource to be somewhat confusing. Restangular allows you to generate new types of requests on the fly. It is a fairly popular module. On the other hand, there haven’t been many commits lately.
AngularJS has a lot of power. To be able to use it, the developer often needs to dig in to documentations, techniques described on blogs and forums, and also into the source code. After spending some time building client-side applications using AngularJS, the engineers broaden their view on AngularJS. New paths open up as a result of searching for optimal approaches. A veteran developer should be at least somewhat familiar with the cases described in the questions and answers below. They all relate to advanced aspects of using Angular. The developer’s fluency in discussing them may indicate to you their thorough understanding of the framework.
Q: Is it possible to manipulate HTTP requests globally in AngularJS? Describe your approach.
Yes, requests can be intercepted, and Angular provides a great api to do that - the “$http” interceptors. “.interceptors” is an array, available at “$httpProvider”, so it can be manipulated from “.config()” blocks. That array should consist of functions which return an object, basically factories.
Requests can be intercepted at: request (just before sending), request error, response success, and response error.
Considering that also “$resource” relies on “$http” to cover XHRs and the functions passed to the $httpProvider.interceptors array, can be normal Angular factories, using interceptors is a good practice for general global manipulation of HTTP requests.
Q: How does root scope differ from all other scopes?
“$rootScopeProvider” is a service. It is a singleton; it does not have a parent, siblings, or another root. It was created directly from the “Scope()” class, and not through the “.$new” method of another scope.
Perhaps the biggest differences are in how root scope is meant to be used. It’s primary use for developers is meant to be event handling. In Angular, “.$broadcast()” and “.$emit()” are ways to trigger events, which are sent down or up the scope hierarchy respectively. The effects are optimal at the root scope, i.e. “$rootScope.$emit()” will only be caught by listeners set on root scope, while “$rootScope.$broadcast()” will reach to all listeners in the app.
Models should not be set on root scope. That scope can be seen as a form of global namespace, especially when evaluating expressions in the context of scopes. Polluting the global namespace is almost never a good practice. The recommendation in Angular documentations is to use root scope only for small parts of data, which are useful throughout the app (globals), but not functions.
Building applications without writing tests is a no-go. Fortunately, Angular was built with testability in mind. Writing tests requires developers to learn and apply different approaches, depending on what type of Angular structure is tested. Some of the differences may be subtle and incomprehensible without knowing the good practices of software development. Others may include alternative approaches to achieve the same goal.
Setting up testing also for a continuous integration environment is the Angular developer’s responsibility. Who else would take care of it otherwise? Though the techniques described here are not required to build great applications, most of the teams behind the great applications value them deeply.
Q: Unit testing controllers and services - what are the differences?
The main difference between unit testing controllers and services stems from the differences in concerns. Controllers are used for setting the initial state and behavior of the scope they are bound to. We could say that all the models set on scope, either directly or using the //this// keyword, are public. This is still somewhat similar to the public properties of services. Controllers should not contain business logic though.
In unit testing controllers, one could expect more assurances of the initial values of models, and less logic. The logic in controller methods should mostly be just coupling UI actions to services. All functionality that is not tightly bound to the current view and scope, should be delegated to services. The developer would definitely have more spies set on mocked services objects in controller tests than in service tests.
Conversely, the services should be tested primarily for correct business logic handling.
Q: How would you automate the testing within a larger team, or in a production environment?
This is not a strictly AngularJS question, but a veteran front-end developer should at least have an idea of how continuous integration environments work, in regard to front-end testing.
First of all, we need to make the assumption that the project is version controlled with Git, and is hosted on GitHub, or BitBucket, or some similar code repository service. It would be great if at this point, the developer would mention gitflow, as it is a method with proven effectiveness. More importantly though, the developer should mention hooks, e.g. GitHub webhooks. Those are event handlers, described in-depth in a recent article on Toptal Blog, which allows HTTP requests to be made to arbitrary URLs in response to various repository events. An example would be to ping a third-party testing service when someone pushes commits to a repository.
There are multiple services, most notable of which are Travis, another GitHub product, available for free for open source projects, and SauceLabs, which allow automated testing on mobile devices. Those tools will do most of the configuration automatically, including configuring the webhooks. What the front-end developer will need to provide is a script, most often a bash script, similar to what probably already is in the repository’s README.md file — the client application needs to be installed and run on the machine provided by the third-party testing service. The script usually installs all dependencies, runs the tests, builds the application, then deploys it. That last step is critical.
The continuous environment, after successfully completing the tests, should perhaps push the code to a remote server. The author never used such processes to push to production, but he did set up several systems where deployment was performed automatically to pre-production servers, e.g. development and staging. In fact, those servers were never pushed manually again. Such setup relieves developers from having to do the build themselves — the only thing they need to do now is commit their code and push. Even more importantly — it runs the tests on another machine. The developer would be expected to test their changes locally anyway. If the tests pass both locally and remotely, there is a big chance that the codebase is stable.
A great AngularJS developer is capable of blending art into engineering.
There were also some areas not covered by this guide, such as animations and rendering performance and CSS / HTML expertise. Angular developers don’t have to be great designers, but they must strive for making performant applications which mirror the provided designs. As there are so many concerns on the side of the logic, it would be alleviating if the team included an HTML / CSS developer. Static HTML templates provided by them could be easily applied to and coupled with an Angular application. Otherwise, animations in Angular, though frustrating at times, are well documented and rather easy to use. Please refer to the Top 18 AngularJS developer mistakes article for more on client-side performance.
Lastly and maybe most importantly come the communication skills. An Angular developer might very well become the main communication node of your team. They will need to constantly cooperate with the back-end team, the HTML coders, and the designers. Their work will be what the end client directly interacts with. Essentially, the Angular dev will need to be very responsive, an expert at their field, and on good terms with everyone. Finding the right one is a difficult task. Toptal makes it easier.
This article was originally posted on Toptal