Oh my. It’s been a while since I blogged here. Well, first off the good news: I graduated from my program! The bad news? Well it’s not really bad news, but damn finishing was tough!
Remember how I said the key to getting through these LV assessments was to keep it simple, hit the project’s minimum technical requirements and then jazz things up? During my Angular assessment I received lots of great suggestions for improving Hangry!
Actually, they weren’t really suggestions. They were more like additional requirements for me to graduate, which was annoying, but I understand why the instructors would want to push us harder on our last official project. To be honest though, I was pretty mentally and emotionally zapped by that point, and it was disheartening to see the finish line moved at the last minute. I took a day off to clear my head, and then I was ready to get back into it.
It took me about a week and a half to add in these refactors. They all are aimed at flexing more muscles with Angular. There’s of course always more work to be done, but here’s what I’ve added:
Angular has a few directives that are useful for cleaning up your code:
The original error messages around my form validation for adding a new restaurant were built with ng-if, which quickly became messy. I switched over to using ng-messages, which was quick and easy. I just had to install ngMessages with bower, add ‘ngMessages’ in to the array of app requirements, and then I was able to use them straightaway in my form template. The actual code when using ng-messages still took up a fair amount of space, but things were much more readable.
I created a custom directive to contain the visual representation of a restaurant result on the index page. The resulting directive <restaurant-result></restaurant-result> made things a lot cleaner and semantic in my code. What’s loading here? A restaurant result! One thing that stumped me for a minute was the naming of my directive. Because of how Angular converts names, calling the directive RestaurantResult was incorrect. You have to name it in camel case (restaurantResult) in order to get Angular to convert the directive correctly to <restaurant-result>.
File Structure
With the increase in complexity to my app, I thought that it made sense to move over to Angular’s way of organizing your file structure by feature. So, instead of having folders just for controllers, views, directives, etc… I had folders for “restaurants” and “reviews.” I got it a bit wrong at first, however, in that I included components with objects. So “nav bar” for example is included at the same level. I still need to go back and clean this up.
Authentication & Devise
Another suggestion was to implement authentication. Allow people to register for accounts, log in and save information to their accounts. To be honest, I was actively avoiding authentication during my first go round with setting up my assessment project. I’d read a few too many horror stories online, and just looking into tutorials the approaches for making Angular + Devise + Rails work together were all over the place.
With the major bits of my app in place, I went ahead and decided to give it a go, using Devise. First I installed it on the Rails side with the Devise gem, and then I bower-installed the Angular-Devise service for interacting with Devise. I ran into some initial issues with handling the user’s authenticity token, but for now, a user can register, log in and log out. One bug: Devise flash messages don’t show until you refresh the page. This is because I set up my flash messages incorrectly. They should be handled by Angular. I’ll need to go back and fix that as well.
Other improvements seemed to be creeping this project more and more in the direction of Yelp:
Another functionality that seemed like an obvious improvement was adding on the ability for users to review restaurants. Once users reviewed restaurants, that restaurant would be added to their dining list, a list of places they had visited before. Adding reviews was simple enough- I set them up as a join table between users and restaurants.
Since reviews were for restaurants users had visited, I also added on the ability for users to filter results to see only restaurants they’d never been to. This filtering was accomplished on the Rails side with a class method.
As I mentioned in my previous post, I was looking into integrating Google Maps functionality on my Restaurant show pages. There are ways to do this without Angular (ahem, jQuery), but this was a good time to try out the popular Angular-Google-Maps. Just you know, trying out the most Angular that I can.
Even following the QuickStart guide line by line, I ran into some bumps, but Avi worked with me for quite a while and we managed to get things running. The major things that got in the way were loading Lodash and where I was adding my $scope.map object. My map was meant to be shown on the show page, which was handled by a showController, but my $scope.map was added to a mapsController. I was planning to have multiple controllers on the show page, which was unnecessarily complicated. Once I just moved the $scope.map over to the showController, it just worked.
Seeing the maps populated, I breathed a sigh of relief, but there were still a few more steps to go to actually implementing these map directives. I had to geocode the restaurant’s address. I ran into issues accessing my address data, but that was because I needed to account for accessing the data from the $resource $promise. The last hurdle: getting the place marker to show up. The code itself was simple enough, I just had problems with when the expression was being run. That was fixed with $evalAsync(), which is in the same family as $scope.watch and $scope.apply.
Next Steps:
The work is never done, is it? There are so many things I want to do to fix up Hangry!. Still it’s a relief to officially close the book on my program. I’ve already started job hunting, and it’s overwhelming as well, but that’s another blog post. 🙂
