I’ll start my response off by making sure we’re on the same page with Turbolinks. Turbolinks is fundamentally different than your current approach. Turbolinks expects an entirely new page to be loaded to replace the current page - it doesn’t come into play when replacing only pieces or parts of a page via AJAXy/single page app approaches. The two aren’t mutually exclusive by any means, it’s just Turbolinks doesn’t come into play here. Turbolinks is really meant to speed up “standard” web interactions (clicking links, submitting forms) but not reloading (even from cache) all JS and CSS and then reparsing all of that data. It also makes use of a local cache to feel even snappier. And it’s meant to all be pretty transparent to both dev and user.
Alright, with that out of the way - If you want to ditch the custom JS altogether, you could use a form for each action and just submit the form using the correct method (e.g.
POST) and let the server render the correct result. No need to explicitly trigger Turbolinks at all, it’ll “just work”.
Now let’s assume you want to stick with the current JS approach. Let’s say your stimulus controller makes a DELETE request. You would want to listen for the success of that request and then call Turbolinks.visit() to go to the current page afterwards. You likely want to clear the Turbolinks cache, as well, so that Turbolinks doesn’t present the now deleted data form it’s local cache.
So let’s say you’re on page
/products and click a delete button (passing any data, such as a product ID, via the Fetch API). In your fetch success handler, you’d do something like:
This would clear the cache and effectively reload the current page, which would be rendered by the server and no longer include the deleted item. It’s as simple as that.
Interestingly, if using a remote form in Rails (
I hope this was helpful. I’d be curious to hear if based on your actual use case Turbolinks still seems like the path you want to go down here!