Creating a Dynamic Angular Project

These days it seems you can’t go a month without hearing about some new JavaScript framework. And it makes sense too. Just like Ruby had been along before Rails, these frameworks offer a new way to revolutionize what can be accomplished and accomplished quickly. If you’ve ever used GMail you’ve used an Angular application. Next time you log in, take a close look at the address bar. The first part of the path name almost never changes as you navigate around. That’s because at its core GMail is really just one page that dynamically changes based on what you click. Angular makes it really easy to build these powerful, responsive, applications but when you combine it with Rails you can create an application like GMail that relies on a database to serve even more information to the user. For my Angular assessment I built an application that combined these two frameworks.

Going into this project I had far more confidence in my abilities working with Rails than in Angular. Initially I was thinking that I would contain as much business logic as necessary in the actual Rails portion and merely use API calls to pass data back and forth between frameworks. Using strong parameters I would perform all validations and take whatever raw data I could get from Angular to insert it into the database. Essentially Angular would merely be the vehicle for my data so that I could manipulate it Rails. Now granted much of this had to do with the ways in which I organized my models in Rails. When I conceived the structure I would be utilizing scopes to show of my Rails knowledge. This was a terrible idea for a beginner. My comfort with Rails, led me down a far more complicated path in Angular that I eventually junked and refactored.

Design is always hard but often made harder on us by ourselves. When you combine Rails and Angular nearly everyone recommends building out the Rails server first, and for good reason. When you do start working with Angular you have to get data from somewhere so you might as well firmly decide what those points are first. In my case I knew I wanted to provide the different scopes as an API endpoint. Easy enough so I wrote four distinct endpoints. But wait! Why write four when they’re essentially the same save for a variable I could call? Naturally I made a more RESTful route which relied on a variable I would pass in. I sealed my fate.

When it came time to design my Angular app things didn’t seem to difficult. I knew about the various parts fairly well I believed the challenge would be tying them into a Rails server and making them function properly. What I didn’t count on was how little my understanding of Angular prepared me for this. To date all of my practice with Angular was either reliant on others work for styling, or was just plain ugly. I had never tied in a server before. It turns out that most of the difficulty I faced was never actually in making the different parts of any one thing but how they came together to interact.

Once I had created my various states and controllers, I needed to tie everything together. I wanted to use Angular-Resource because it seemed to be the most efficient RESTful way of doing things. Angular Resource has become so popular because of this implementation, one could compare it to the CRUD features of Active Record. And it largely works too when you target things correctly. When you’re using ng-Resource make sure you take out the dollar sign, you’re effectively using a variable and not a scope method! However because it is programmed to work with the regular RESTful routes I encountered to many issues the way I initially set up my routes. Angular, like Rails, prizes convention over configuration.

Ultimately I ended up changing not only my routes in Rails, but also the entire relational structure of my models. As I developed the Angular front end I realized that I wanted to make my Resources model related to many skills; after all StackOverflow doesn’t just answer questions on one skill. This could be considered a pitfall of designing my database first, but I think its more indicative of features being added and the product growing.

Once I stitched my backend back together again, I found I had a much easier time implementing my Angular features. I did need to tweak a few things but because of Angular’s module based structure things were largely still intact. I think this represented one of the strengths of these module based frameworks. Despite, major refactoring on the Rails backend, there was actually very little that need change in Angular to receive the data.

One place during all of this where I ran into trouble was finding appropriate help. Angular of course is Google’s JavaScript framework and boy does it show. Like any good Google IP it’s varied wildly with many changes over its lifetime. Some of my biggest challenges were finding documentation and results that worked with the version of Angular I was using (version 1.5.9). Google and stack overflow seem to be riddled with issues regarding version 1.2 where Angular underwent a massive shift. As great as building this app was, my one worry is that I will need to relearn a great deal of convention because, yet again, Angular is undergoing a major revision with the new Angular 2.0.

The other area of trouble is that Rails, because of its many advanced features, just doesn’t seem to play nicely with Angular templates right out of the box. There are several gems that seek to rectify this which allow you to load views dynamically, but as of writing they are encountering depreciation errors with Sprockets; its unknown how long this solution will continue to be viable. You can always place your templates in the static public folder Rails offers but this seems like a lackluster solution.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.