Forms with data-turbo-action? #122
Comments
|
That's an interesting thought. Would data-turbo="false" be another way to solve this? |
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this issue
Oct 14, 2021
Closes hotwired#421 Closes hotwired#122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this issue
Oct 14, 2021
Closes hotwired#421 Closes hotwired#122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this issue
Oct 14, 2021
Closes hotwired#421 Closes hotwired#122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this issue
Oct 14, 2021
Closes hotwired#421 Closes hotwired#122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this issue
Oct 14, 2021
Closes hotwired#421 Closes hotwired#122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Visit actions --- Prior to this change, a `<form method="get">` would _always_ result in two Visits: the first with `{ action: "advance" }`, then a second with `{ action: "replace" }`. Since the response to a `<form method="get">` has the potential to be a [200 OK][] or a [201 Created][], this commit also modifies the `Visit` class to skip the `followRedirect()` call when the request is idempotent and the response is not a redirect. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144 [200 OK]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200 [200 Created]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
dhh
pushed a commit
that referenced
this issue
Oct 18, 2021
Closes #421 Closes #122 --- Fire the same sequence of events for `<form method="get">` submissions as for `<form method="post">` submissions. The [FormSubmission.prepareHeadersForRequest][] already accounts for `[method="get"]` forms by omitting the `Accept:` header with the custom `turbo-stream` MIME type. Visit actions --- Prior to this change, a `<form method="get">` would _always_ result in two Visits: the first with `{ action: "advance" }`, then a second with `{ action: "replace" }`. Since the response to a `<form method="get">` has the potential to be a [200 OK][] or a [201 Created][], this commit also modifies the `Visit` class to skip the `followRedirect()` call when the request is idempotent and the response is not a redirect. Test changes --- The `eventLogs` mechanisms we have in place declared in `src/tests/fixutres/test.js` cannot properly serialize `Element` instances, so adding `turbo:submit-start` and `turbo:submit-end` listeners to serialize events for our test suite isn't possible in the current configuration. To that end, this commit adds assertions for `<form>` submit event sequences for all events except those two. In their place, the suite adds listeners to set `[data-form-submit-start]` and `[data-form-submit-end]` to the `<html>` element when they fire. [FormSubmission.prepareHeadersForRequest]: https://github.com/hotwired/turbo/blob/58d2261274533a80a2c5efda7da211b3f20efcbb/src/core/drive/form_submission.ts#L136-L144 [200 OK]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200 [200 Created]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
are form submissions meant to abide by the data-turbo-action attribute of a form/submit button similar to the way links behave?
Something akin to: jwagener@f55dbb3
My use case is that a devise login page that should be replaced by a logged in screen upon successful login in my native app.
Is that something worthwhile to create a PR for when cleaned up and tested?
Or have I gotten a wrong understanding of something?
Thanks!
Johannes
The text was updated successfully, but these errors were encountered: