Rails App With a jQuery Front-End

Zenia Villa
Jul 25, 2017 · 3 min read

Going into the full-stack web development program, I thought that I would be more gifted in front-end development. After all, I majored in Fashion Retailing, worked in interior design, and did a lot of graphic design work. The creative side that dealt with UI and UX was surely going to be my strength. After completing this project, I realize that designing a database schema and creating routes is far less complex than implementing jQuery into a rails app. This has a lot to do with certain features of Rails not playing nicely with certain JavaScript libraries. Here are the main things I struggled with (therefore, etched into my brain).

Turbolinks does not work right out of the box

I set up my app’s “All Categories” link to override the default of rendering categories ‘index’ and instead insert the ajax-requested JSON into the DOM. I was extremely happy when that was working as my Handlebars template was extremely lengthy with a few if block helpers. Then I noticed after clicking on “All Categories” a second time after rendering a different page, the overridden rails HTML render would be active once again. After reading through similar issues on StackOverflow, the answer was easy. Add ‘turbolinks:load’

$( document ).on(‘turbolinks:load’, function(). 

Or


document.addEventListener(“turbolinks:load”, function() {
// …
})

Because I created my app for the sake of learning, I decided to forgo using turbolinks. Once I add more models and features, I’ll definitely need to include turbolinks to speed up the app.

Handlebars in Rails

Using Handlebars templates in a vanilla JavaScript file is easy. Using it in a Rails app, not so easy… at first. Sure, there’s helpful documentation that outlines how to implement Handlebars in Rails but I was going once step beyond (using it with JavaScript object models). I had created a Chore model and after an AJAX ‘GET’ or ‘POST’ request with JSON returned, I created a chore object with that JSON. No big deal, I’ve done it before. The issue arose when I was trying to give the Handlebars template context and then call the template with a chore object. Then it came to me like a slap in the face. I didn’t need to set a context because I had already created that with the Chore model itself. This is all I needed to write:

Chore.prototype.renderTd = function() {  return HandlebarsTemplates['chores/index'](this);}

Also, part of the Handlebars confusion was having the templates and helpers in my views. Everything concerning Handlebars belongs in app/assets/javascripts/templates. For my chores, I created a chores folder and an ‘index.hbs’ file, following the MVC pattern.

Don’t forget BCRYPT in the DB seeds file

After creating my seeds file with a non-encrypted password_digest, I was getting errors about not being able to write to a read-only database when creating a user and @user.authenticate(password) would no longer work. Always simulate the exact way the app will run.

Those were the main issues I had. It may not sound like a lot but Handlebars in itself had an array of issues. I’m pretty happy with how the app turned out. Of course, there’s always more that I want to implement. And hopefully deploying to Heroku won’t be too difficult.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade