Six Months with AngularJS at BuildZoom

Last week at BuildZoom, we rolled out a complete rework of how homeowners manage their remodeling projects through our service. Since deploying our first feature that leveraged the AngularJS JavaScript framework six months ago, the magnitude of the angular code we’ve sent to production has increased with every release. This latest release continues the trend, leveraging a slew of AngularJS features, on top of our existing Ruby on Rails code base. With the implementation came many learnings. Some more general, while others strictly for angular junkies.

Reusable components

A good engineer is a lazy engineer. Laziness drives engineers to do the least to gain the most: efficiency. With this mindset, all features we’ve built leveraging AngularJS were broken down into reusable components. Services, models, and directives were all engineered to be easily popped into other features with minimal effort. The fruits of our labor paid off. The core API communication services between the front and back end were ready to go without additional engineering time.

Asset pipeline advantage

Developing javascript code on top of rails has it’s pros and cons. The major pro I’ve come to embrace and rely on is the asset pipeline. The feature allows seamless inclusion of needed asset files (JS, CSS) on a requested page. Furthermore, with proper configuration, all assets are automatically minified for production. No need for grunt or gulp.

We’ve configured our layouts to automatically include asset files and directories respectively named after the controllers and actions of the pages being requested. This minimizes the assets to only those needed on the page. Shared components, which are not part of the path, are explicitly required in the top-level js/css manifest for the page.

Service-based API architecture & parallel development

Working with AngularJS has allowed our small team to break out of the monolithic mold of Ruby on Rails. Switching to a web-service / API based architecture, we’ve been able to efficiently separate responsibilities (both for team members and code) and engineer in parallel without conflict. Fake stubs for APIs let the front-end come together as the details of the back-end flesh themselves out.

Two-way data binding goes too far

One of the biggest arguments for using AngularJS is the built-in two-way data binding. User interactions instantly update javascript objects, which do other fairytale things. What if you have a form that lets the user update an email? You need to let the user finish typing first before updating the client-side data, which happens to be watched by a trigger to call an API to update the email. In a nutshell, access to triggers is needed to control when data updates are propagated, for complex data manipulation and validation scenarios. AngularJS v1.3 comes with a great solution for this: ngModelOptions. We’re on v1.2.26 and relied on a manual solution.

Old browsers breed new problems

I don’t like Internet Explorer 8 and 9. I truly don’t. They should have come with a self destruct mechanism that was triggered years ago. May be they would have, if IE8 wasn’t released only five years ago, with IE9 being just 3 years young. So in no particular order, here are some of the issues I’ve spent more time on resolving that I’d like to admit…

• character encoding for UI Router’s HTML templates: modern browsers are reflexible on the character encoding of AJAX responses from the server IE8/9 are not. We had a typo in the template response headers (server setting), charset: utf8. It should have been charset: utf-8. The javascript error the console displays is not informative, to say the least.
• forEach does not exist: this is a common problem. IE8 has no idea what a forEach method is when it comes to arrays or objects.
• AngularJS 1.3 dilemma: v1.3 has been released. It brings tons of awesome new features (ngModelOptions, for example). It drops support for IE8. If you’ve got a notable user base of IE8 aficionados, you can’t take advantage of it.

Wrap up

While I was battling one of the IE8/9 issues, our VP of Engineering asked me if I still believe using AngularJS was a good decision given the frustration that comes about with legacy browsers. My confirmation was without a doubt. The solutions that have been made possible using AngularJS have decreased development time while increasing code integrity, maintainability, and reusability. That’s definitely worth a few hours of debugging and creative problem solving.

Originally published at www.buildzoom.com on October 28, 2014.