Hard fork of turbolinks, adding partial page replacement strategies, and utilities.
The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
Turbograft extends Turbolinks, allowing you to perform partial page refreshes.
Graft- (noun) a shoot or twig inserted into a slit on the trunk or stem of a living plant, from which it receives sap.
In botany, one can take parts of a tree and splice it onto another tree. The DOM is a tree. In this library, we're cutting off sub-trees of the DOM and splicing new ones on.
Turbolinks works by intercepting navigation requests and loading them via Ajax when possible, swapping the body tag of the document with the newly loaded copy. Turbograft builds on this to allow you to perform a partial page refresh on specified DOM nodes by adding a refresh key. This allows you reduce page load time, while the feeling of a native, single-page application.
Turbograft gives you the ability to maintain a single, canonical render path for views. Your ERB views are the single definition of what will be rendered, without the worry of conditionally fetching snippets of HTML from elsewhere. This approach leads to clear, simplified code.
Turbograft was built with simplicity in mind. It intends to offer the smallest amount of overhead required on top of a traditional Rails stack to solve the problem of making a Rails app feel native to the browser.
gem "turbograft"in your Gemfile
//= require turbolinkswith
Much of Turbograft’s functionality relies on attributes HTML elements. These attributes are currently namespaced to
Versions of Turbograft older than 0.2.0 did not use this namespacing. The old attribute names (e.g.
refresh) are deprecated.
This performs a
GETrequest, but our client state is maintained. Using the
data-tg-refreshattribute, we tell TurboGraft to grab the new page, but only refresh elements where
data-tg-refresh="page". This is the lowest-level way to use TurboGraft.
data-tg-refreshattributes on your DOM nodes can be considered somewhat analoguous to how
classwill apply styles to any nodes with that class. That is to say, many nodes can be decorated
data-tg-refresh="foo"and all matching nodes will be replaced with
onlyKeys: ['foo']. Each node with
data-tg-refreshmust have its own unique ID (this is how nodes are matched during the replacement stage). At the moment,
data-tg-refreshdoes not support multiple keys (e.g.,
data-tg-refresh="foo bar") like the
You can specify multiple refresh keys on a page, and you can tell TurboGraft to refresh on one or more refresh keys for a given action.
Refresh Section A and B
You can also tell TurboGraft to refresh the page, but exclude certain elements from being refreshed.
Refresh everything but Section A and B
data-tg-refresh-neverattribute will cause a node only appear once in the
bodyof the document. This can be used to include and initialize a tracking pixel or script just once inside the body.
true. When set to false it prevents
Page.refresh()from updating the url in the browser.
data-tg-remoteoption allows you to query methods on or submit forms to different endpoints, and gives partial page replacement on specified refresh keys depending on the response status.
It requires your,
data-tg-remote: (optionally valueless for , but requires an HTTP method for links) the HTTP method you wish to call on your endpoint
href: (if node is
data-tg-refresh-on-success: (optional) The refresh keys to be refreshed, using the body of the response. This is space-delimited
data-tg-full-refresh-on-success-except: (optional) Replaces body except for specififed refresh keys, using the body of the XHR which has succeeded
data-tg-refresh-on-error: (optional) The refresh keys to be refreshed, but using body of XHR which has failed. Only works with error 422. If the XHR returns and error and you do not supply a refresh-on-error, nothing is changed
data-tg-full-refresh-on-error-except: (optional) Replaces body except for specified refresh keys, using the body of the XHR which has failed. Only works with error 422
data-tg-remote-once: (optional) The action will only be performed once. Removes
data-tg-remote-oncefrom element after consumption
data-tg-full-refresh: Rather than using the content of the XHR response for partial page replacement, a full page refresh is performed. If
data-tg-refresh-on-erroris defined, the page will be reloaded on those keys. If both
data-tg-refresh-on-errorare not defined, a full page refresh is performed. Defaults to true if neither refresh-on-success nor refresh-on-error are provided
Page.refresh()from being called, allowing methods to be executed without updating client state
Note that as
data-tg-refresh-on-*pertains to partial refreshes and
data-tg-full-refresh-on-*-exceptpertains to full refreshes, they are incompatible with each other and should not be combined.
Call a remote method:
The Rails way:
'page section-a section-b', 'data-tg-full-refresh' => 'true', 'data-tg-remote' => 'post' %>
Post to a remote form:
SubmitUse the field below to submit some content, and get a result.
turbograft:remote:init: Before XHR is sent
turbograft:remote:start: When XHR is sent
turbograft:remote:always: Always fires when XHR is complete
turbograft:remote:success: Always fires when XHR was successful
turbograft:remote:fail: Always fires when XHR failed
turbograft:remote:fail:unhandled: Fires after
turbograft:remote:fail, but when no partial replacement with refresh-on-error was performed (because no
data-tg-refresh-on-errorwas supplied or because
Each event also is sent with a copy of the XHR, as well as a reference to the element that initated the
data-tg-staticattribute decorating a node, we can make sure that this node is not replaced during a fullpage refresh. Contrast this to partial page refreshes, where we normally specify the set of elements that need to change. With
data-tg-static, we can define a set of elements (by annotating them with this attribute) that must never change.
The internal state of any nodes marked with
data-tg-staticwill remain, even though the entire page has been swapped out. A partial page refresh with
onlyKeystargeting a node inside of the
data-tg-staticnode is also possible, persisting your static element but swapping the innards.
Though, if you were to refresh the page at a higher level -- e.g., refreshing an ancestor of the
data-tg-static, the static aspect is no longer obeyed and it is replaced!
Examples of where this may be useful include:
For the lazy developer in all of us, we can use the attribute
data-tg-refresh-alwayswhen we want to be sure we've absolutely replaced a certain element, if it exists. An example of such a node you may want to apply this might be an unread notification count -- always being sure to update it if it exists in the response.
When serializing forms for tg-remote calls, turbograft will check to ensure inputs meet the following criteria:
data-tg-remote-noserializeis useful in scenarios where a whole section of the page should be editable, i.e. not
disabled, but should only conditionally be submitted to the server.
When aor tag with a unique name in it's
data-turbolinks-trackis encountered in a response document Turbograft will insert it into the active DOM and, if it's a script, force it to execute.
If an asset with a different
hrefbut the same
data-turbolinks-trackvalue is found upstream, turbograft will force a full page refresh. This prevents potential multiple executions of a script bundle when a new version of your app is shipped.
As of version
0.4.0, this functionality has been made backwards compatible. If
data-turbolinks-track="true"head assets are present, turbograft will cause a full page refresh when the set is changed in any way.
There is an example app that you can boot to play with TurboGraft. Open the console and network inspector and see it in action! This same app is also used in the TurboGraft browser testing suite.
When turbograft replaces or removes a node it uses native DOM API to do so. If any objects use jQuery to listen to events on a node then these objects will leak when the node is replaced because jQuery will still have references to it. To clean these up you'll need to tell jQuery that they're removed. This can be done with something like:
document.addEventListener 'page:after-node-removed', (event) -> $(event.data).remove()
git checkout -b my-new-feature)
git commit -am 'Add some feature')
git push origin my-new-feature)
./serverand visit http://localhost:3000/teaspoon to run the JS test suite in the browser
bundle exec teaspoonwill run the JS test suite from the command line. Uses Selenium by default, but can be configured using the TEASPOON_DRIVER environment variable
bundle exec rake testto run the browser test suite