turbo: data-turbo="false" doesn't seem to work
Hello! I’m trying to migrate one of my turbolinks apps to turbo and i encountered an issue with one of the features. Basically, i have a sign-out link which signs user out and redirects him to a page that returns a 401 HTTP status.
The thing is, even though this sign-out link has a data-turbo="false"
set up, i can still see the request is being done in the background by Turbo, user gets signed out successfully but page never refreshes and i can see a warning message about 401 in javascript console. If it changes anything, this link also has data-method="delete"
attribute. So basically, if i’m getting it well, data-turbo="false"
does not really disables Turbo for this specific link.
I’m on 7.0.0-beta.3
EDIT: I just encountered an exact same issue but with a form that redirects to a different page. Form gets submitted in the background, response is a 302 with a redirect to different path but from user perspective - nothing is happening. Even with data-turbo="false"
or data-turbo-drive="false"
set on that form.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 18 (6 by maintainers)
omg. not only does it work, it’s even documented 😭
Sorry to waste your time here @seanpdoyle and thank you for stepping through it with me.
@seanpdoyle is this expected if you aren’t using
remote: true
?For example, this link:
Is being processed by Turbo. (We do have UJS running as well.)
@seanpdoyle Yes, the form is “mounted” to the page, and it can be picked up by Turbo. I’ve already tested this with a monkey-patch to the
Rails.handleMethod
function. Right now, it’s appended to thebody
, but like my 2nd suggestion, it might be better to append to the link’s parent node, which then potentially avoids the need to copy all the data attributes.@ghiculescu ahh, I think I understand now. Are you citing the fact that UJS constructs a
<form>
element entirely through JS?Does replacing the
link_to
with abutton_to
that accepts thedata: { turbo: "false" }
attribute work? That way, you can achieve the same behavior without relying on an<a>
to encode an HTTP verb, and you have direct control over the HTML that gets constructed.