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.handleMethodfunction. 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_towith abutton_tothat 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.