-
Notifications
You must be signed in to change notification settings - Fork 442
Support data-turbo-action="..."
on Form Submits
#231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The `Navigator` class translates `<form method="get">` submissions into `proposeVisit` calls, skipping the rest of the `FormSubmission` architecture. This commit adds support for declaring `[data-turbo-action="replace"]` (or `"restore"` or `"advance"`) as a [Visit Action][]. Prior to this commit, specifying a `Visit` action was limited to an `<a>` click-initiated `Visit` only. This can be useful for a `GET` form driven by auto-submission driving the current page's URL, like a Typeahead autocomplete `<input type="search">` field or a bounding-box scrolling Map. In those scenarios, a series of `"advance"` page visits would yield an essentially broken "Back" and "Forward" navigation experience. [Visit Action]: https://turbo.hotwire.dev/handbook/drive#application-visits
Excellent! |
@seanpdoyle Apologies for posting this on an old merge, but should this make the following work?
or
I'm trying to get this to fire on Turbo-iOS but I'm always getting an |
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
Closes hotwired/turbo-ios#44 Follow-up to hotwired#231 --- This commit follows-up [hotwired#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [hotwired#231]: hotwired#231
* Re-structure existing Navigation tests In preparation for `<form method="post">`-driven navigations, this commit removes unnecessary `[method]` attributes, and renames `[id]` attributes to communicate the verb to the test cases. * Read `[data-turbo-action]` during Form Submissions Closes hotwired/turbo-ios#44 Follow-up to #231 --- This commit follows-up [#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [#231]: #231 Co-authored-by: David Heinemeier Hansson <[email protected]>
Hey @olliekav, were you able to make this work? I'm also trying to achieve a |
@lutzcc1 Yep, it's working for me. I had to set a resolution in my
This has now been merged into the main branch now, so you can use that... #409 |
* Re-structure existing Navigation tests In preparation for `<form method="post">`-driven navigations, this commit removes unnecessary `[method]` attributes, and renames `[id]` attributes to communicate the verb to the test cases. * Read `[data-turbo-action]` during Form Submissions Closes hotwired/turbo-ios#44 Follow-up to hotwired/turbo#231 --- This commit follows-up [#231][], which added `[data-turbo-action]` support for idempotent form submissions to maintain parity with `<a>`-initiated Visits. These changes re-use the existent `Navigator.getActionForFormSubmission` function to determine the value for the `VisitOptions.action` options. [#231]: hotwired/turbo#231 Co-authored-by: David Heinemeier Hansson <[email protected]>
The
Navigator
class translates<form method="get">
submissions intoproposeVisit
calls, skipping the rest of theFormSubmission
architecture.
This commit adds support for declaring
[data-turbo-action="replace"]
(or
"restore"
or"advance"
) as a Visit Action. Prior to thiscommit, specifying a
Visit
action was limited to an<a>
click-initiated
Visit
only.This can be useful for a
GET
form driven by auto-submission drivingthe current page's URL, like a Typeahead autocomplete
<input type="search">
field or a bounding-box scrolling Map. In thosescenarios, a series of
"advance"
page visits would yield anessentially broken "Back" and "Forward" navigation experience.