search

turbolinks / turbolinks-classic

Classic version of Turbolinks. Now deprecated in favor of Turbolinks 5.
MIT License
3.54k stars 428 forks source link

Is reloading turbolinks every x pages supported/recommended? #637

Closed matthewjsummers closed 8 years ago

matthewjsummers commented 8 years ago

We are investigating using turbolinks in an existing project. We are refactoring our (pretty well written) javascript to ensure that we unload timers and the like when moving pages using turbolinks.

However - we have a big codebase, and want a catch-all to ensure the javascript memory doesn't bloat during the transition. One approach is to count the number of page fetches turbolinks makes and every, say 100 fetches, perform a hard reload to ensure that the DOM/javascript is reset back to a clean state.

Does anyone have any thoughts on this approach and whether it should or shouldn't be used with turbolinks - or whether it is something supported by turbolinks today?

nicolasmlv commented 8 years ago

Is this feature something similar to Turbolinks.pagesCached(20); // Set the cache size ?https://github.com/rails/turbolinks#page-cache

matthewjsummers commented 8 years ago

I don't think so. You might want turbolinks to continue its caching strategy. Our concern is that (especially when moving to turbolinks) there might be leaky JS or global state that is being added to/polluted. Moving large JS codebases to turbolinks is an undertaking that shouldn't be take lightly - so we wondered whether building in the ability to hard reload every X requests would minimise potential issues. Our users have long running sessions - they will log in at the beginning of the day and use the app all day - so any issues in memory bloat or the like could be pronounced by the end of the day after several thousand page fetches inside one session.

Thibaut commented 8 years ago

This is should be easy to do. You can listen for the page:before-change event, which will pass you the new URL (for the hard refresh) and is cancellable.

Turbolinks already forces full-page refreshes when assets change (in the <head>), but if you don't deploy often and want to work-around memory issues, then I can't think of a less hacky way :P

No changes required in Turbolinks.