-
Notifications
You must be signed in to change notification settings - Fork 423
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
Adds new Action Option :self
#546
Adds new Action Option :self
#546
Conversation
Seems like some of the older commits are also showing up here. I'll rebase with the latest main branch and re-push when I get the time. 👍 |
d52e9ee
to
615e8ab
Compare
Done. I've rebased the branch with the latest main. 🚀 |
I quite liked the clear distinction proposed in #530 (comment):
I think it will also read better: Is there a use case for |
@rik Sorry for replying late on this. I've been trying to also think of some use case for |
Let's just go with |
I think we should keep it as |
@marcoroth I'm okay with either. But I also agree with @rik and feel that |
Think we want to stick with |
I don't understand this point. The syntax proposed by @adrienpoly allows for self + prevent. You left a rocket emoji reaction to this proposal. I'm copying the examples here: # mixing event variant and event options
<div data-action="click.left->controller#vote:once:prevent">
# with global listener
<div data-action="keydown.left@window->tabs#prevTab"> |
@rik Sorry, I meant mixing things like left and self. IMO, self feels more like once/prevent than it does "left". Don't like the feel of "click.left.self->" either, even if that could be possible. |
I'm sorry to chime in so late, but I'm at a loss understanding Are |
:self
and :!self
:self
@seanpdoyle Good explanation from the same feature in Vue: https://stackoverflow.com/questions/42763940/vue-js-what-is-the-self-modifier |
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [turbo-events]: https://turbo.hotwired.dev/reference/events
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events
As a follow-up to [hotwired#535][] and [hotwired#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [hotwired#535]: hotwired#535 [hotwired#546]: hotwired#546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events
* Support custom Action Options As a follow-up to [#535][] and [#546][], add support for declaring custom action modifiers in the same style as `:prevent`, `:stop`, and `:self`. Take, for example, the [toggle][] event. It's dispatched whenever a `<details>` element toggles either open or closed. If an application were able to declare a custom `open` modifier, it could choose to route `toggle` events denoted with `:open` _only_ when the `<details open>`. Inversely, they could choose to route `toggle` events denoted with `:!open` _only_ when the `<details>` does not have `[open]`. Similarly, the same kind of customization could apply to custom events. For example, the [turbo:submit-end][turbo-events] fires after a `<form>` element submits, but does not distinguish between success or failure. A `:success` modifier could skip events with an unsuccessful HTTP response code. [#535]: #535 [#546]: #546 [toggle]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetailsElement/toggle_event [turbo-events]: https://turbo.hotwired.dev/reference/events * attempt to pass on Safari@14 failing test: https://github.com/hotwired/stimulus/runs/7566084180?check_suite_focus=true#step:6:138
This PR adds two new Action Options, namely
:self
and:!self
, as discussed in #530. For more context, please refer to the original issue.Feel free to provide any suggestions and I'll make sure to accommodate them.