Angular.js: My First Experience

After finishing up two long projects, my next endeavor was to create an app for the localAngular.js airport. They were looking for an app that was fast, small, and would update in real time. Doing a lot of reading on Angular.js recently, I figured it would be a good fit for this project due to the small nature of the app. After doing a few months of development, I wanted to share some of the awesome, and not so awesome, things I ran into while using Angular for this project.

Awesome: Single Object Updates in Array

I created a large grid of data that was a ‘live’ dashboard. Any time someone would update a record anywhere in the app, it had to be reflected in this grid. Speed and  was important. At first, I decided to use just an interval to do a new query to the server every few seconds. That wasn’t ideal because of the time of updating the UI. This would lock the UI thread and while the table was updating, the user couldn’t interact with the page. I decided to give SignalR a try (it was a Web API backend) to do the updates instead. This way the client would only have to update when needed. Come to find out, when a single object is updated, Angular only updated the single object instead of doing the whole list. This was much faster than having the lock the UI for the whole table to draw again.

Not So Awesome: ngResource Query String Data

For the model layer, ngResource seemed like a good fit. At first, all interaction was done with hand crafted AJAX requests using $http, but ngResource replaced most of that custom code. As long as the Web API controllers were made with REST in mind, ngResource would have no problem communicating with them. The issue I was running into is ngResource is putting all the data in the query string. This somewhat goes against the reason of doing a POST or a PUT if it doesn’t include the data in the body of the request. On top of that, Web API was having issues parsing a JSON content type rather than the default. Which I’m lead to believe is more of a Web API configuration issue than a client side issue. I have some solutions lined up that I want to try before I write it off completely, but it’s an interesting issue.

Awesome: Encouragement of Refactoring

The blueprint that Angular.js gives front end development encourages refactoring of code. There were numerous times that I was working on a section of the app that started out as functionality in a controller, to having maybe a directive or two, a couple of shared services, and a custom model. This led to logic being more isolated and it became more testable. After doing that a few times, I started to see more of the power Angular can provide. So my advice when is to refactor as much as it seems reasonable. You’ll reap the benefits later on.

Not So Awesome: The Angular.js Docs

I know this is somewhat common knowledge throughout the Angular community, but the docs site does a bad job of pointing you in the right direction. Even the ‘tutorial’ they have on their site is convoluted and doesn’t have a real direction. The API reference feels incomplete. This is the main area Angular can improve the most I feel.

Overall, Angular has been a pleasure to build an app with. Once I learned some of the gotchas and what should go where, it’s a powerful framework. It might be overkill for more simple single page apps, but for something that will require multiple views, a full model layer, and testable, Angular will be go to for now.