Common AngularJS Issues and How to Deal with Them

AngularJS is the weapon of choice in every web developer’s arsenal — the ones who wish to stay with the times that is.

However, despite being one of the most widely used web development frameworks in the world, Angular does have a few teensy-weensy drawbacks, but hey; nobody’s perfect.

Fortunately for us, most of these common “issues” that are reported by developer teams pertaining to Angular are due to the under-utilization of the framework’s capabilities.

Translation: you can easily fix most common Angular problems for you because in most cases, you’re probably just not using it right.

Gone are the days when all that a front-end web developer had to do was, well, code. Now, any developer worth his or her salt will have to handle application logic, XHRs (XML HTTP Requests), animations and transitions, SEO (Search Engine Optimization), styles, and even linking and integration with external services.

Those things are just the start of a very long list, but thankfully, Angular can handle all of it, and more — even if every developer cannot.

That being said, according to Talent.com, your average Angular developer will set your company back $117,000 per year.

With astronomical rates like that and no guarantee of a single employee’s proficiency, it makes sense to expand your team.

To save significantly on costs other get access to the global talent market, it is a prudent move to hire angular developers (or at least some of them) remotely.

Think about it: you can get a full, dedicated team of developers for half the price of what you would pay a bonafide, in-house employee.

Well then, this article is going to be an “easy fix” as well as a “best practice” piece. So, without any further ado, let’s get right into it.

Common Mistakes Developers Make

Sometimes, the solution is so easy that we do not believe in its simplicity.

1. Not using dots in the ng model

Everyone’s heard it at least once by now: if you don’t use a dot in your ngModel, you’re doing it wrong.

Now, after scouring the internet, there remains to be seen a clear explanation for why using a dot in the ngModel is actually needed.

So, let’s cut out the jargon. Having a “dot in your model” refers specifically to the ngModel, and not something like, ngDisable, for example.

This is because having a dot in your ngModel allows for two-way data binding, and to cut a really, really long story short, two-way data binding is essentially a mechanism for components within your code to share data among themselves.

So, for example, this comes in pretty handy with user-defined variables such as forms. Many website developers will become frustrated when their forms don’t work properly.

The dot ensures that your variable will bind only to the defined scope and not to the current scope. Even worse, two-way binding to a primitive (such as a boolean) want keep you up at night when your inputs fail to compute.

For a more detailed and easy-to-understand explanation of parent and child scopes, Foos, and two-way binding, check out this discussion on AngularJS’ official Github page.

2. Structuring Their Directories “The Usual” Way

At the very root of the matter, AngularJS is an MVC (Model View Controller) framework, although some would put it in the MVVM (Model View ViewModel) category.

That particular argument, however, is an article for another day though.

Most good developers default to grouping their files together solely based on file type (such as grouping the app/ controller, app/ services, app/ filters together under “app”).

While this isn’t such a bad idea on regular backbone JavaScript, it is decidedly a laggy mess on larger Angular applications.

This approach causes many folders to be open at the same time, taking up valuable cache in the render.

For example: for media folders, it can significantly increase the time that site files such as images and logos take to load which could eventually compromise the UX (User Experience).

It can cause desync to the point where even lazy loading your features will not salvage the situation

Also, when using an IDE (Integrated Development Environment), you’ll just end up scrolling endlessly through the folder layout tree.

Well then, what’s the solution? Group your files by feature or functionality instead of by type. Example: instead of using the layout on the left, use the one on the right.

It is much more efficient and organized. The major benefit of doing something like this however is improving your application’s scalability by about a hundred percent.

vs

3. modules

While we are on the topic of an efficient grouping of code components, it would be remiss not to mention modules.

Well, more specifically, we are referring to the paint of modules and modularity.

It is a rookie error (and one that frequently goes unnoticed until it is too late to change) to have at the onset, all subsets of code modules “leeching” or “hanging” off the main module.

Again, this practice scales about as well as the previous example of grouping one’s files by type: that is, it does not scale very well at all.

When your application gets to the point where it might be termed “enterprise-scale”, all your things are likely not going to be contained on a single page alone.

Having scalable code and efficiently managed (and sorted) modules will allow you to even reuse some of those modules with call features, and will save loads of time when you consider that the alternative is having to custom-write each module by hand.

This practice allows the developer team to reuse modules but only if a particular feature or set of features has been contained solely within a single module.

A small point, but worth remembering.

4. Dependency Injection And Global Dependencies

While dependency injection does make testing much simpler in AngularJS-based applications, it makes for a headache when the time comes to analyze efficiency.

Dependency injection is as simple as having the function for the module inserted with the dependency’s name.

However, when trying to minimize the amount of code used for a faster SSR (Server Side Rendering) experience, traditional dependency injection can prove to be a bane.

Counteract this by using the UglifyJS 3 toolkit that does what it says on the box: it makes your code less aesthetically pleasing but can improve performance by a couple of degrees.

Coming to the question of global dependencies. Sometimes, a dependency will tie itself to an object that binds itself to the global scope (see point 1).

Long story short, this interferes with and can even break the dependency injection model as the dependency is available in any AngularJS code now.

So what is the fix? Using UnderscoreJS is. UnderscoreJS is a library of tools that provide functionality that does not extend the built-in objects in Java.

Even if you don’t face dependency injection issues, Underscore is worth checking out — it might just save you a whole lot of time and effort as far as compilation and compressional go.

5. Overloading your controller

Last but not least, it is time to address something that is a little more concept-based and high-level.

We all know that controllers are the most important part of AngularJS apps, but unfortunately, it is extremely easy to overload or “bloat” your controllers, which can easily result in a visible drop in performance.

Here are a few tips to help you avoid common mistakes that lead to controller bloat:

1. Always store your data in services, except when it is bound to the scope.
2. Even storing data on local storage is a mistake: this is still slower than calling the data from a javascript variable.
3. Similarly, your business logic should also live in services, not in controllers.
4. Never use your controller for DOM (Document Object Model) manipulation.
5. Lastly, never allow your controller to hold DOM selectors.

For points 3 and 4, use the model and directives instead.

Closing Thoughts

Prevention is always better than cure, and I’m positive that you will have taken away something from this article that will lead to a change in your AngularJS application.

That said, AngularJS is an extremely proficient web development toolkit and many of its issues are caused due to under-utilization of its available resources.

Oh, and one last thing: if you do choose to hire a front-end developer, ensure that they know their stuff by quizzing them with information from this article (it is medium-difficulty tier information).

For example, you could ask them how they would handle global dependencies, given that the dependency would be tied to the global scope.

Hopefully, this piece has pointed out some of the most underused AngularJS functionalities and will lead to a better UI and UX for your app.