Refactoring the Session Tracker into a Controller Concern
This guide walks through how to refactor the session tracking system into its own controller concern to improve the code organization in the Rails 5 application.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

The next item we're going to cover is how the application controller works, we've talked about this a little bit.

Open Sublime Text, I'm going to open up application_controller.rb we've talked about it, however, I wanted to have an official guide to discuss how it works.

The application controller is the parent of all of the other controllers in your applications. If you go to app/controllers you can see blogs controller, pages and portfolios. In order for these to be controllers, they have to inherit from the application controller. As you can see, this is the parent, which means any data flow is always going to go through here first.

This is the reason why when we built out our set_source method right here it was able to be accessed by all of the other controllers automatically, we didn't have to do anything special. We didn't have to call it directly. This set_source method works on every page of our application and it does it because the application controller has access and is the parent of every controller in the app.

Let's implement very similar thing to what we did with our devise whitelist. This will be a little bit of a review but it will be good, if you're following along let's open this up in a different layout. I'm going to go with two columns and I know you can't see the window because the monitor I'm on right now but you would go up to view layouts and then select two columns if you want to see this.

We have our devise whitelist, we want to create a new one right here and this is going to be we can just call it our set_source module and we're just going to mimic what we did right here.

I'm going to say module SetSource and end, let's save it as set_source.rb. Remember how important it is to have our naming set up so that every time we have a capital this is going to be in the file name a underscore and then everything is lowercase. In case you're wondering about the naming, this is a form of camel case and in development you'll hear all kinds of cases. This is camel case. This right here is called snake case set_source.rb I guess it kind of looks like a snake how slithers up and down and has these little spots where it's blank or where it has an underscore and no characters there. that's those are the two different names.

Inside of our SetSource module, first thing we have to do is do the same thing we did before which is extend the active support concern, which is a module in itself.

This is what gives us the ability to have a lot of cool things like included and all of that good stuff. here I'm just going to grab all of this hit cut and put this code below just so we can cut it and slice it up here. We're going to need an include method just like we see there. It's going to say included do, this is where we're going to put our, I did a before action. This is just kind of one of the differences between different versions of rails. We can make this a before filter both of them are going to react pretty much the same way for our concerns. After that going to cut out set_source paste that in, get rid of all the white space underneath and this should work exactly the same way as before.


Now you can come to application_controller.rb and say include SetSource.

Let's come to the terminal type rails s, our feature should still be working exactly like before. I'm going to open up a browser window in incognito, remember Incognito gives you a new session. If we did this in one of the other spots then we might be locking ourselves into a session.

I'm going to say localhost:3000/blogs?q=facebook scrolling down you'll see "Thanks for visiting me from facebook."

This is working perfectly. Navigate to the home page. Thanks for visiting me from facebook. All of that is working perfectly if you come to the regular site. Hit refresh. Nothing shows up because we didn't have that logged into our session so everything is working perfectly.

Look how much better our application controller looks. This is something when it comes to professional development this is the type of structure that you're going to be expected to type out instead of having clutter. Could you imagine we were still only touching the iceberg with the features that we have built in. Could you imagine if we had to have all of this code and all of this code just for two very basic features here an application controller. By the end you might have a few hundred lines in this one file but by being able to leverage concerns then we're able to have some really nice clean calls. The other thing I like about these is they're also very explicit.

They say that devise whitelist. This is a lot more clear to me than configure permitted parameters and device controller and everything there. I think this very clearly states what it does. SetSource does the same exact thing. I like being able to look at a file look at these include statements and have a very clear idea on what their purpose is.

  • git status
  • git add .
  • git commit -m "Refactored application controller to include concern for source feature."
  • git push origin controller

Next thing let's close this out right here so we have how the application controller works. In the next guide we're going to talk about strong parameters.