Assembling a Rails app is even more complex than assembling IKEA furniture. And just like an IKEA dresser, you shouldn’t have to go at it without instructions.
We’ll walk you through how some of the more important pieces are assembled.
This guide does not attempt to be a deep technical resource on the inner workings of Ruby on Rails. There are plenty of resources online for that, but we’ll try and point you in the right direction when we can.
If you’re unfamiliar with them, it’d be a good idea to read up on the basics of a few topics:
See Section 2.2.1 in the official Rails docs on The Asset Pipeline if you’d like to learn more about how Sprockets loads images and other assets.
When you deploy to production, you'll want to move your images to a Content Delivery Network (CDN) like Cloudfront or Cloudinary. This will force you to use some different helper methods, but will be well worth it to decrease page load times. We’ll go over this more in-depth in a later post.
Argon is configured to use 2 different sources of icons:
See the Creative Tim docs on icons to see what's available and how to use them. You can also check out icons.html.erb in Argon for plenty of examples like this one:
FontAwesome has thousands of free and premium icons to choose from on their website.
For simplicity, we’ve organized all our views under a generic pages directory. They all have empty (currently not defined) actions in PagesController. I would not recommend continuing this simplistic pattern when you extend the app for your own purposes.
All views start with the application layout file - application.html.erb. Rails renders the appropriate view file where we call yield in the layout. Read more on layouts here in the Rails docs.
Each view file is further broken up into partials. A partial is a way of dividing up a bigger file into smaller chunks. It avoids having massive files with thousands of lines. More importantly, it allows us to reuse code across different views while only writing it once.
Adding some flair
Customizing the UI
Just because you start from a theme, doesn’t mean you can’t get creative with it!
Bootstrap makes it super easy to style pretty much everything using their included classes. For example, bg-primary sets background-color to blue, while btn-secondary makes your <button> white.
But not everyone wants their site looking like an out-of-the box Bootstrap template. I’m going to walk through how to customize Argon to match our own brand and colors at DinoSaaS.
Bootstrap comes with a _variables.scss file that specifies everything from $primary and $secondary colors to $border-radius and $box-shadow.
These values are used all across the app - we can change values in one place and immediately have global consistency.
We could go directly into the bootstrap source at bootstrap/_variables.scss and modify them there, but I wouldn’t recommend it. Doing this will make it more difficult down the road to update Bootstrap to a future version.
Instead, you’ll want to make changes in custom/_variables.scss. In general, if a property on a class is set twice, the one that is set last overrides the first. However, bootstrap/_variables.scss uses the !default flag - this assigns a value to a variable only if it's not already defined.
So even though custom/_variables.scss is included first in our application.scss manifest, variables that are set there will override the bootstrap defaults.
Changing the color scheme
First, we’re going to make some color changes. We’ll set $primary to “Steel Blue”, the lighter blue color used in most of our copy.
Next, we’re going to change our $default color to “Midnight Blue”, the darker blue used in our home page.
Here’s what some of our pages look like with these new changes:
Reload the page. Clicking the “Say Hello” button should show you an alert popup like this:
Why are we listening for the turbolinks:load event?
Great question! By waiting for turbolinks:load to fire, we ensure that the button is rendered before we attach its click handler. See this section in the Rails docs on Turbolinks if you want to learn more.
Using real data
By now, you’re probably thinking, Yea these charts look great, but what am I supposed to do with this fake data?!
Snarkiness aside, you’ve got a point. Next, we’re going to populate the “Page Visits” table with real data from our Rails backend.
We’ll start by creating a PageVisit model. We don't care about tests right now so we don't generate tests or fixtures.