Learning while conducting the Trigger Upgrade | NetEngine

Learning while conducting the Trigger Upgrade

My task, was to upgrade Trigger and fix problems which we basically blamed on our PJAX implementation. Whether it’s an exception or a long running process, PJAX renders the previous page on these scenarios and this may give users the impression that the site is stuck or not working.

So two of the biggest things I realise that need addressing are:

Turbolinks in favor of PJAX

Since we like to be on top of things, we want to be able to upgrade to Rails 4 (when it launches) seamlessly and use the best it has to offer. A quick read about Turbolinks shows that it is PJAX with less configuration. Sweet!

So I removed PJAX and started testing the page’s javascripts if they are still working. As expected, some of them work but most don’t. I also had this issue where JavaScript is not loaded, but when the page is loaded via Turbolinks.

This is probably because of the way Turbolinks works by loading the entire html response and only updating the title tag (in the header) and the body tags. By replacing the body with new elements, all JavaScript bindings are gone. So being the good developer that I am, I looked for help online and eventually found some articles about this issue.

From my reading it looks like I need to bind a page: change event to the document to run the JavaScript when a page is loaded via Turbolinks. In Coffeescript, this would be my sample JavaScript:

  $ ->

  $(document).bind 'page:change', mySampleJS

I discover that by doing this, I solve our JavaScript loading issues. Nice!

PJAX goodies

PJAX provides start.pjax and end.pjax events which most commonly show loading spinners while the content loads. It would be nice if we have this kind of behavior with Turbolinks. Well, what do you know?

We do! We have them with the page:fetch and page:change events. I just added the following to an asset file and it works!

    $(window).bind 'page:fetch', -> $('#big-loader').show()
    $(window).bind 'page:change', -> $('#big-loader').hide()

CSS Assets

In all my years working as a web developer, I usually work with a UI developer so I don’t have to worry about the site styling. Sure, I can do some basic PSD slicing and converting them to CSS, but that’s it. Some known CSS rules for UI developers may sound Greek to me.

So we have all our CSS files under the public/ directory which is the standard for Rails 3.0. With the introduction of the asset pipeline, assets such as stylesheets, images and javascript have been moved to app/assets. I thought it may be as easy as moving the stylesheets to app/assets/stylesheets. Sure, the site has some similarities with the production version but I’m expecting that it should be the same up to the last pixel.

So I read a bit more, this time, about the asset pipeline and sprockets and manifest files used to load the CSS and JavaScript assets, but I really can’t figure out the difference between my version and the production one. Looking at the html generated by a page tells me that all stylesheets are being loaded. Although they are not being loaded in the same order as the live site, it should… wait ,what? That’s it! Yep, that’s it!

I forgot that CSS files have some kind of hierarchy that they follow when loading the styles. Once I figured this out, making my version look like the live site was a cakewalk.

These are some of the things I encountered while working with the new version of Triggerapp.

We are currently adding new features. If you are intrigued and or impressed by what you see, we’re very close to releasing our next version so let us know if you’d like to sign-up for the free trial, when it happens and we’ll be in touch soon.