Creating a Dynamic Angular Project
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.
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.