Adding Turbolinks (front-end and backend)

[Obversity]

• Start Date: 09/02/2017
• Owner: BP
• RFC PR: n/a

Summary

In my experience, Turbolinks makes things feel faster. Turbolinks was revamped in Rails 5, and it's not going away any time soon.

Status

Work has started on this feature:
https://github.com/katalyst/koi/tree/feature/turbolinks

• CKEditor unloading before cache and reloading after cache
• Datepickers
• Magnific Popup (unfortunately required an update to the core JS file for magnific popup, just a one-liner)
• Drag and drop image uploader
• Orderables on an index listing
• Location field type geolocation issues
• Dirty form warning is persisting after page change

Possibly more things I haven't come across yet, feel free to edit this issue and add new tasks.

Motivation

The Gym experiment

As a trial, we added Turbolinks to the Gym when we did the rails rewrite. From what I can tell, this experiment was pretty successful. With a few reasonably minor code changes, and a couple of gotchas, Turbolinks gave the app a very smooth feel—on many pages, just as fast if not faster than the previous Ember build. Take a look yourself, have a click around, compare it to our other sites:

https://gymnastics-staging.vat.org.au/manager/gym-sports/1/athletes
manager@katalyst.com.au
Nw3WrunL

Native-ish apps

If the turbolinks native iOS and android wrappers end up being solid, having Turbolinks built into our projects would open us up to building more app-like projects—or building app-friendly views for existing projects to be shipped natively.

Koi slowness

The Koi backend feels sluggish a lot of the time. There are various reasons for this and various things we can do to improve this situation, but Turbolinks could go a long way towards making it feel snappier, assuming everything plays nice.

Detailed design

Adding Turbolinks should will be trivial. The hard part will be testing to make sure that everything in (a) ornament and (b) koi still functions as intended, and fixing it if it doesn't. Turbolinks does have some implications for javascript that relies on page-load events. Quoted from the docs:

Turbolinks is fast because it doesn’t reload the page when you follow a link. Instead, your application becomes a persistent, long-running process in the browser. This requires you to rethink the way you structure your JavaScript.

I suggest we set aside some time, give it a shot and see how much breaks. That'll give us a good idea on how easy it'll be.

Drawbacks

It might break things. Potentially lots of things. We won't know until we try, though! It may end up being more overhead than it's worth if it does cause problems, but we'll probably only be able to judge this after using it for some time. We'll want to make sure that it plays nice with all the plugins we regularly use on the front-end,

Things to worry about:

• ckeditor, especially in nested (aka inline) forms
• datepickers
• the sitemap
• multi-select form fields
• anywhere else we have jquery plugins doing stuff
• select2
• google maps
• React components

Among others. Feel free to add things to this list that rely on page-load hooks or that are reported to break with Turbolinks 5.

Alternatives

There are other options we can consider for the performance of both Koi and the Front-end (which I'll detail in other RFCs), but there's no reason we can't do both unless time becomes a constraint.

[dbaines]

I've run in to an issue with Turbolinks in Gym regarding anchoring that's a bit unfortuante: turbolinks/turbolinks#75

You can get around it by adding data-turbolinks="false" to the anchors manually.

[Obversity]

Another issue: if you get a 500 error, and then go back to the site, various javascripty things are screwed up—for example on gym, there's now a duplicate search bar for athletes, and toggling things basically toggles them twice, so it flashes them on and off.

[dbaines]

I've started a turbolinks branch:
https://github.com/katalyst/koi/tree/feature/turbolinks

Issues fixed so far:

• CKEditor unloading before cache and reloading after cache
• Datepickers
• Magnific Popup (unfortunately required an update to the core JS file for magnific popup, just a one-liner)
• Drag and drop image uploader
• Orderables on an index listing

Issues currently unresolved:

• Location field type - when failing to detect geolocation it closes the modal, empties the field and refuses to open the modal again. No JS errors, really baffling. Haven't spent much time on it though.
• Dirty form warning is persisting after page change.
• Possibly more things I haven't come across yet

I've updated the main issue with a list of done/not done tasks.

[Obversity]

Awesome. Will take a look soon, hopefully.

[dbaines]

We ran in to an issue with AddThis where it would cache the Facebook share links.