I’ve Got 99 Problems – but Deploying My Rails/Angular App to Heroku is No Longer One of Them:) PART 2

So where was I? Oh yeah, I left off at changing my problem js file extensions to ‘.es6’ so there would be no problem with new JS6 syntax. This definitely helped, but in it’s place sprung another problem. Only the images that were not hooked up to the database on my site were showing . So I used my noggin and realized that I never migrated my database to Heroku! DOH!

When I tried to run ‘heroku run rake db:migrate’, the migration kept aborting with this message:

PG::UndefinedTable: ERROR:  relation "users" does not exist

I definitely had a table called “users” so that didn’t make much sense. I did a little digging and found out that postgres (the database Heroku uses) does not like tables relating to other tables that have not been created yet. The table being created was referencing a table that was created on a later migration. I know it’s not a good idea to mess with the names of migration files, but I did anyway. Rails timestamps migration files, so I just had to change my “users” file timestamp to a date before the file in question.

So I tried the migrate command again and got the same error. Strange. My migration files had quite a few additions which later became subtractions. I decided that I only really needed three migrations for three tables. Since I had a good seed file which could recreate everything I needed, I decided to recreate only the migrations I needed. This would allow me to reset the database and start from scratch. I deleted the schema and development.sqlite3 files so there would be no references to the old migrations. Now I could recreate my database and schema file.

$ rails db:drop db:create db:migrate db:seed
// This will delete the entire database, losing all data
// recreate a new database and runs the migrations
// db:seed will seed the database from seeds.rb

I had a brand spanking new schema and database, ran my local server and everything was running smoothly. So I ran the heroku migration command again and got THE SAME ERROR!! WTF?!? After googling for a bit, it hit me. I didn’t push the new changes to heroku! Often times it is the simple tasks that one might forget to do that causes errors. Note to self: if you are banging your head against the wall, stop for a minute and think of the steps you would normally take. Save yourself some time and energy. The first change to the “users” migration file name probably would have worked if I just slowed down a little.

After trying to migrate to Heroku again, it worked! Now my site is up and running, and I’m feeling good! Hopefully this helps fellow programmers out there that get stuck – and have sore heads! As always, thanks for reading!

AngularJS: Using $localStorage to Keep Users Logged In

If you are familiar with authentication, then you are should be familiar with sessions and web tokens. While the latter is the standard these days, sessions still have their place, especially when building small apps. The app I’m currently working on is using a Rails API with an Angular front-end. Since it was my first time attempting to use authentication with Angular, I used the tried and true Devise gem for Rails and Angular-Devise for Angular. Devise was fairly simple to set up and I had it working pretty quickly. Their documentation is pretty good as far as documentation goes!

I was saving my user info and their signedIn status in the $rootScope of my app which would make it accessible to all of my views and controllers. This worked well until a page was refreshed and my $rootScope was demolished along with all my users signedIn status. This is a good thing to know about Angular! The rootScope starts fresh on every page refresh. After reading up and doing some soul searching, I found a solution.

ngStorage to the Rescue

The ngStorage module allows you to store information that you want to have available during a session. After bowering or npm-ing, all you have to do is add ngStorage to your apps dependencies and inject $localStorage or $sessionStorage into any controller you need it in. Pretty simple. Now to use it, you have to pass $localStorage by reference to a hook under $scope or $rootScope, like so: $rootScope.$storage = $localStorage. Add this line to your controller and you have access to all the goodness that you would like to store there.

The basic usage would be to pass a boolean to your currentUserSignedIn variable on the $storage when they are logged in. Using Devises’ Auth.login function, you can then add the users status in the callback function.

Screen Shot 2017-03-06 at 10.01.13 AM

 

Ignore the toaster.pop (although check it out, it’s cool!) stuff going on and pay attention to the $rootScope.$storage line. Here we set currentUserSignedIn to true and have that information available in our views. Since it’s set on the $rootScope, we should have access to it throughout our app. Now on page reloads, we still have access to our users’ signed in status. Cooool!

I have a navbar throughout my views which uses its own controller. Since I used $rootScope.$storage I should have access to the users’ status. There was one occasion, however, where I would lose access to the $storage variable on a page reload. I wasn’t quite sure what was happening, but when I added $scope.$storage = $localStorage to my navbar controller, everything worked fine again. Don’t forget to inject $localStorage into the navbar controller. Now in the navbar html template, if we wanted to have a link to show “Log In” if the user is not logged in we could use a ng-hide directive as such:

screen-shot-2017-03-05-at-6-57-27-pm

 

If our user is logged in, we can simply change the hide to a show for a Log Out link:

screen-shot-2017-03-05-at-6-58-30-pm

When our user signs out we can reset our $localStorage or set the currentUserSignedIn boolean to false. We do this just like we did in the sign in function:

Screen Shot 2017-03-06 at 10.15.36 AM

Here we set currentUserSignedIn to false and our users session is complete. I’m definitely going to check out JWT Tokens next, but baby steps are good to take with these things. Thanks for reading!

 

 

AngularJS & Rails: No Helpers:(

Angular is a front-end framework and is used for speed and asynchronous page loading (no page reloading on each request). Which means much of the helpers we rely upon in Rails are deemed useless. This can be hard to take for someone new to a front end framework like myself. But, alas, life must go on! The biggest obstacle for me so far is not being able to use the Flash Messages helper provided by Rails. What to do?

There are a few options out there on github that you can use. After trying a few different repos on Github which gave me a plethora of errors, I came across Toastr. It appealed to me right away because of it’s simplicity. I ran into one small bug (which was on my side), so I thought I might share.

The Set Up

screen-shot-2017-01-19-at-5-02-44-pm
First, to install Toastr, you can use Bower or npm. Next, copy the css and js files from the repo into your Asset Pipeline  – app/assets/stylesheets and app/assets/javascripts respectively. This will auto-rails-magically make the files available to use (as long as you //= require your trees *= in your application.js/css files). Now we can set up a factory in Angular.

The Chocolate Cheese Toaster Factory

screen-shot-2017-01-19-at-7-18-05-pm

Hey you…can you pass the butter, please?

Here we have set up a factory (we can just as easily use a service), which returns an object. Note that we also have access to other methods such as info and warning, but I only needed success and error for my project. When we call our toaster from a controller, we can give any text we’d like the user to see as an argument. I needed an error message telling a user that they couldn’t upvote a post more than once.


This Isn’t Going to Hurt, I Swear

We can then inject our toaster (factory) into any controller we’d like, then we have access to our success and error calls.

 

screen-shot-2017-01-19-at-8-20-51-pm
We’re injecting our toaster factory into our Main Controller. Now we can use it in any function we see fit. As I mentioned earlier, I needed to show the user an error if they tried to vote more than once on a post. By using a basic conditional statement with a some method on the array I could check for previous voters. I created a private function called voteChecker that checks the an upvoted posts user_id against the current_user $scope.user.id (I had to use inject the controller with Auth from the angular-devise gem for this).

screen-shot-2017-01-19-at-8-30-10-pm

By using the voteChecker function as the callback for the some method, we can check if any of the previous upvotes were from our current_user (I know, I know). However, the some method will return true if our array is empty, so we have to check that too. If the some method returns true && our upvoted_posts array’s length is not zero, then we have ourselves a two-timer and get to yell at them:) If, however, the challenge is passed, then we get to use our posts service (which I’m not going to delve into) to upvote our post. Very nice!

The Bug

I almost forgot! After doing everything above, I was getting a strange error:

TypeError: Cannot read property ‘extend’ of undefined

Crap! Well after a little Stack Overflowing it turned out that I was requiring jQuery after Angular in my application.js file. Once I put it before angular, everything was all good. NOTE – the same goes for if you’re including links or script tags referencing the angular and jQuery files from your application.html file. Well, all this toaster talk has made me quite hungry, so I think I’ll end here. If you ever need a flash message in your life and you’re using a front end framework, check out toastr!

 

Stumbling Through Angular: Routes!

AngularJS can be quite difficult to comprehend. Today, while trying to follow along Udemy’s Angular tutorial (hosted by Tony Alicea – it is great by the way!), I ran into some trouble with routing. Angular has built in routing that is very useful, but when things don’t work as you think they should, it can be frustrating. Every programmer in the world has been there. Although banging your head against the wall for a few hours can be quite fun, sometimes it’s best to go take a walk. When you come back, all of a sudden the problem is obvious. In my case, I was really trying to do something simple, but I just couldn’t get it to work.
screen-shot-2017-01-03-at-8-21-56-pm
Setting up the routing is fairly easy, once you  know the basic syntax of Angular. To the left is the file structure for my primitive app. I just wanted to have a main index page with two links. Simple right? Well a few hours later, yes…very. But if I can save anyone else a little time then it was all worth it. First off, we have to let Angular know that we want to use routing in our app. We can either use a link from Angularjs.org or we can download the node modules directly into our app, which I did. In both cases, we add it to our app with a script tag in index.html file. To download, in your terminal type:

‘npm install –save angular-route@1.6.1’

The numbers at the end represent the version of Angular you are running. If you’re not sure which version you’re running, open up package.json and you’ll find it in there.

Now we can add the script to our index.html file (it must be under your angular.js script!).

screen-shot-2017-01-03-at-8-39-31-pm

Note that these are all relative to my index.html file which is in the top of my file directory. Next, in app.js we let Angular know we want to rely on ngRoute. We do this in our module setup like so:

screen-shot-2017-01-03-at-8-32-02-pm

Here we are setting our module up and telling it to include ‘ngRoute’. Now we can use the routing capabilities. I set up two simple controllers to handle the two different links:

screen-shot-2017-01-03-at-8-50-42-pm

Here I’m using the array syntax which basically allows you to minify your files when you go to scale without any hiccups. But that’s for another blog post.  In the body of my index.html file I have two links and a div with a built in Angular directive.

‘ng-view’ tells Angular to look at the url screen-shot-2017-01-04-at-9-04-33-amand use the correct template that we set up with our routing. For this exercise I daisy chained all of my controllers and the like to my main module, but for bigger applications we’d have them in their own separate files. Now all we have to do is hook up our routing and we’re all set…

screen-shot-2017-01-04-at-10-16-54-am
So when we go to our main route, ‘/’, we’re expecting our ‘ng-view’ to summon up our main.html file with our $scope attached to our mainController. Welp, that didn’t work. I was getting a ‘404 (Not Found)’ error in my console. My main.html file couldn’t be found.

After searching stackoverflow.com for a  while I thought I found my answer. You can check out this stackoverflow exchange to see what I thought might be going on. Here’s the gist of it…

screen-shot-2017-01-04-at-10-50-12-am

So I tried a few of their solutions and also tried changing the templateUrl to no avail. After taking a much needed walk, I realized that I was giving the location of my html file relative to my app.js file and not my index.html file. So once I changed the templateUrl to reflect that, everything was groovy!

screen-shot-2017-01-04-at-10-27-00-am

Final app.js file

Unfortunately, something was still off when I clicked my links in the browser. The first link was working fine, but the second wasn’t doing anything. Well, technically it was changing the url in the browser, but nothing was going on in my terminal behind the scenes or changing on the web page. The main url is on the left and second link/url on the right.

Something funky was going on with the second link. There were a few characters that were being added – ‘#%2’ – before ‘second’. When I went directly to the ‘/second’ url, everything was cool – my page loaded up correctly. So what was the deal with the extra characters? What’s up Angular?!? I tried changing my href in index.html to include the bang before the ‘/second’. screen-shot-2017-01-04-at-10-55-15-am

And it worked! YAY! I still didn’t know what the heck was going on, but it worked! I thought that Angular, by default, adds a hash to url’s, which is why I included them in the first place. I didn’t know about the bang though. It’s called a hashbang, by the way. There are ways to beautify url’s in Angular, but I’ll leave that to more seasoned Angularites. I hope this will help someone out there! May your journey be smooth and remember – everyone stumbles! Just get back up and keep trekking#!