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:
- facilitating the removal of PJAX
- Upgrade Rails to 3.2 from 3.0
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!
$ -> mySampleJS() $(document).bind 'page:change', mySampleJS
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()
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.
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.