-
Notifications
You must be signed in to change notification settings - Fork 29
TODO Document: Turbo compatibility #219
Copy link
Copy link
Closed
Labels
area:coreA bug/feature for the core code-input.js/code-input.css filesA bug/feature for the core code-input.js/code-input.css filesarea:externalA bug/feature due to integration with another library / JavaScript framework, but not the browser.A bug/feature due to integration with another library / JavaScript framework, but not the browser.bugSomething isn't workingSomething isn't workingpriority:mediumstatus:workedaroundA workaround has been sent.A workaround has been sent.
Metadata
Metadata
Assignees
Labels
area:coreA bug/feature for the core code-input.js/code-input.css filesA bug/feature for the core code-input.js/code-input.css filesarea:externalA bug/feature due to integration with another library / JavaScript framework, but not the browser.A bug/feature due to integration with another library / JavaScript framework, but not the browser.bugSomething isn't workingSomething isn't workingpriority:mediumstatus:workedaroundA workaround has been sent.A workaround has been sent.
I was looking at using this in a Rails app that uses Turbo on the frontend. Turbo intercepts page visits and handles them with
fetchto give an SPA-like experience. Turbo maintains an internal page cache, so the injected HTML needs to be cleaned up.This causes a problem because if you render a code-input, navigate to another page, then hit the Back button, the code-input renders with the HTML
I can get most of the way there by removing all the non-textarea elements before cache using the following but it still leaves the
textareaHTML in the code like you see in the above screenshot.I think this comes down to how the
textarea[data-code-input-fallback]is handled since that attribute seems to be removed.code-input/code-input.js
Line 741 in 877e596