You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When prefetching data-turbo-stream="true" links, Instantclick evaluates turbo-stream tags immediately, effectively turning hover event into a click one.
When hovering over data-turbo-confirm links, the request is being made immediately, bypassing the confirmation requirement.
My use case
I'm using data-turbo-stream="true" to open selected forms in modal <dialog>. The page needs to open a dialog when link is engaged directly, but render a separate usable form page when link is pasted or is otherwise taken out of the page lifecycle (e.g. middle click). The problem boiled down to either discerning turbo-frame as html variant, which seems to be justifiably discouraged, or introducing modals as a streamed enhancement. I chose the latter.
General argument
With data-turbo-stream and data-turbo-confirm being official parts of the framework, InstantClick should be aware and compatible.
"GET" requests are idempotent on server side, but responses to those requests have effect on browser state. Regular navigation takes care of replays by effectively cleaning the slate, but in case of Turbo Drive, we're skipping that phase, which allows for effects to accumulate.
Both data-turbo-stream and data-turbo-confirm imply that important or at least noticeable client-side effects are probable, and as such InstantClick should either be disabled by default for such links, or contain prefetched data without triggering its effects (stream processing, connecting stimulus controllers, etc.) until it is actually requested by the user.
This is similar to #1170 but contains a reproduction code, an additional issue, and an attempt to provide minimal reasonable expectations with justification.
The text was updated successfully, but these errors were encountered:
Ran into this problem today when upgrading turbo/turbo-rails. For anyone else coming across this issue, the temporary solution is to add data-turbo-prefetch="false" to any link that triggers a turbo stream. Disabling prefetch causes streams and confirmations to work as they previously did.
This issue only seems to impact links which would trigger a GET request. If data-turbo-method is set to any other method, they work as expected.
Reproduction is available here
When prefetching
data-turbo-stream="true"
links, Instantclick evaluatesturbo-stream
tags immediately, effectively turning hover event into a click one.When hovering over
data-turbo-confirm
links, the request is being made immediately, bypassing the confirmation requirement.My use case
I'm using
data-turbo-stream="true"
to open selected forms in modal<dialog>
. The page needs to open a dialog when link is engaged directly, but render a separate usable form page when link is pasted or is otherwise taken out of the page lifecycle (e.g. middle click). The problem boiled down to either discerningturbo-frame
as html variant, which seems to be justifiably discouraged, or introducing modals as a streamed enhancement. I chose the latter.General argument
With
data-turbo-stream
anddata-turbo-confirm
being official parts of the framework, InstantClick should be aware and compatible."GET" requests are idempotent on server side, but responses to those requests have effect on browser state. Regular navigation takes care of replays by effectively cleaning the slate, but in case of Turbo Drive, we're skipping that phase, which allows for effects to accumulate.
Both
data-turbo-stream
anddata-turbo-confirm
imply that important or at least noticeable client-side effects are probable, and as such InstantClick should either be disabled by default for such links, or contain prefetched data without triggering its effects (stream processing, connecting stimulus controllers, etc.) until it is actually requested by the user.This is similar to #1170 but contains a reproduction code, an additional issue, and an attempt to provide minimal reasonable expectations with justification.
The text was updated successfully, but these errors were encountered: