Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Replace LinkInterceptor with LinkClickObserver #412

Merged
merged 1 commit into from
Aug 1, 2022
Merged

Replace LinkInterceptor with LinkClickObserver #412

merged 1 commit into from
Aug 1, 2022

Conversation

seanpdoyle
Copy link
Contributor

@seanpdoyle seanpdoyle commented Sep 30, 2021 •
edited
Loading

Follow-up to #382

In the same style as hotwired/turbo#382, replace instances of
LinkInterceptor with LinkClickObserver, making the necessary
interface changes in classes that used to extend
LinkInterceptorDelegate.

Conditional logic that was once covered in the LinkInterceptor is
moved into the predicate methods of the delegates (for example, the
FrameController.willFollowLinkToLocation and
FrameRedirector.willFollowLinkToLocation).

Since the recently introduced FormLinkInterceptor was named after
the LinkInterceptor, this commit also renames that class (and its call
sites) to match the LinkClickObserver-suffix, along with the
LinkInterceptorDelegate method structure.

@seanpdoyle seanpdoyle force-pushed the frame-link-click-observer branch from 159e600 to 4c25b6c Compare November 9, 2021 13:38
@dhh
Copy link
Member

dhh commented Jul 18, 2022

Same re: rebase and 7.2.0.

@dhh dhh added this to the 7.2.0 milestone Jul 18, 2022
@seanpdoyle seanpdoyle force-pushed the frame-link-click-observer branch 6 times, most recently from 719137f to 9701ebf Compare July 19, 2022 00:45
@seanpdoyle seanpdoyle force-pushed the frame-link-click-observer branch 5 times, most recently from d0e50f6 to c261589 Compare July 30, 2022 11:25
@seanpdoyle
Replace LinkInterceptor with LinkClickObserver
9bef653 
Follow-up to hotwired#382

---

In the same style as [hotwired#382][], replace instances of
`LinkInterceptor` with `LinkClickObserver`, making the necessary
interface changes in classes that used to extend
`LinkInterceptorDelegate`.

Conditional logic that was once covered in the `LinkInterceptor` is
moved into the predicate methods of the delegates (for example, the
`FrameController.willFollowLinkToLocation` and
`FrameRedirector.willFollowLinkToLocation`).

Since the recently introduced [FormLinkInterceptor][] was named after
the `LinkInterceptor`, this commit also renames that class (and its call
sites) to match the `LinkClickObserver`-suffix, along with the
`LinkInterceptorDelegate` method structure.

[hotwired#382]: hotwired#382
[FormLinkInterceptor]: hotwired@f8a94c5
@seanpdoyle seanpdoyle force-pushed the frame-link-click-observer branch from c261589 to 9bef653 Compare July 31, 2022 23:50
@dhh dhh merged commit 11591fd into hotwired:main Aug 1, 2022
@seanpdoyle seanpdoyle deleted the frame-link-click-observer branch August 1, 2022 18:09
dhh added a commit to seanpdoyle/turbo that referenced this pull request Aug 3, 2022
@dhh
Merge branch 'main' into pr/445
52c9ced 
* main:
  Add turbo:fetch-request-error event on frame and form network errors (hotwired#640)
  Return `Promise<void>` from `FrameElement.reload` (hotwired#661)
  Replace LinkInterceptor with LinkClickObserver (hotwired#412)
  Don't convert `data-turbo-stream` links to forms (hotwired#647)
@manuelpuyol manuelpuyol mentioned this pull request Sep 20, 2022
Closed
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
a26880e 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for canceling page-wide navigations when
`turbo:click` events are canceled.

In support of those changes, first, change the `cancelNextVisit`
signature to accept the name of a Turbo event that is cancellable (in
this case, `turbo:click` and `turbo:before-visit`). Next, change all the
call sites. Finally, extract it to the shared `helpers/page` utility
module for re-use elsewhere.

Next, use the `cancelNextVisit` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame.

[hotwired#412]: hotwired#412
@seanpdoyle seanpdoyle mentioned this pull request Sep 21, 2022
Merged
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
401ccb2 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, change the `cancelNextVisit`
signature to accept the name of a Turbo event that is cancellable (in
this case, `turbo:click` and `turbo:before-visit`). Next, change all the
call sites. Finally, extract it to the shared `helpers/page` utility
module for re-use elsewhere.

Next, use the `cancelNextVisit` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
6227e4f 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, introduce the `cancelNextEvent`
helper to accept the name of a Turbo event that is cancellable (in this
case, `turbo:click` and `turbo:before-visit`). Next, implement
`cancelNextVisit` in terms of `cancelNextEvent`.

Finally, use the `cancelNextEvent` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
719306c 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, introduce the `cancelNextEvent`
helper to accept the name of a Turbo event that is cancellable (in this
case, `turbo:click` and `turbo:before-visit`). Next, implement
`cancelNextVisit` in terms of `cancelNextEvent`.

Finally, use the `cancelNextEvent` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
be9091a 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, introduce the `cancelNextEvent`
helper to accept the name of a Turbo event that is cancellable (in this
case, `turbo:click` and `turbo:before-visit`). Next, implement
`cancelNextVisit` in terms of `cancelNextEvent`.

Finally, use the `cancelNextEvent` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 21, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame
950f247 
Closes hotwired#726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [hotwired#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, introduce the `cancelNextEvent`
helper to accept the name of a Turbo event that is cancellable (in this
case, `turbo:click` and `turbo:before-visit`). Next, implement
`cancelNextVisit` in terms of `cancelNextEvent`.

Finally, use the `cancelNextEvent` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[hotwired#412]: hotwired#412
dhh pushed a commit that referenced this pull request Sep 22, 2022
@seanpdoyle
Fix: Dispatch turbo:click when driving a Frame (#729)
329e837 
Closes #726

Prior to this commit, clicking on `<a>` elements nested within
`<turbo-frame>` elements, or `<a>` elements that drive `<turbo-frame>`
elements did not dispatch `turbo:click` events in the same way that they
did before [#412][].

This commit re-instates those events as part of the `FrameController`
and `FrameRedirector` implementations for the `willFollowLinkToLocation`
methods they define as part of the `LinkClickObserverDelegate`
interface.

To be consistent with the existing `turbo:click` dispatch behavior, and
to guard against introducing similar regressions in the future, this
commit also adds test coverage for falling back to page-wide navigations
when `turbo:click` events are canceled.

In support of those changes, first, introduce the `cancelNextEvent`
helper to accept the name of a Turbo event that is cancellable (in this
case, `turbo:click` and `turbo:before-visit`). Next, implement
`cancelNextVisit` in terms of `cancelNextEvent`.

Finally, use the `cancelNextEvent` helper in the Frame test coverage to
ensure that canceling a `turbo:click` prevents navigating the Frame and
falls back to built-in browser behavior.

[#412]: #412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 28, 2022
@seanpdoyle
Prevent double requests from within turbo-frame
c131833 
The change in behavior can be traced back to [hotwired#412][].
When the overlap between the `LinkInterceptor` and the
`LinkClickObserver` were unified, the technique used by the
`LinkInterceptor` to prevent duplicate event handlers from responding to
the same `click` event was changed in a subtle way.

In its place, this commit changes the `LinkClickObserver` to monopolize
its handling of `click` events on `<a>` elements that navigate the page
or drive `<turbo-frame>` elements. In tandem with the existing call to
[Event.preventDefault][], this commit adds a call to
[Event.stopImmediatePropagation][].

To exercise this edge case, this commit also adds a `ujs.html` fixture
file along with a `ujs_tests.ts` module to cover situations when
`@rails/ujs` and `@hotwired/turbo` co-exist.

[hotwired#412]: hotwired#412
[Event.preventDefault]: https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault
[Event.stopImmediatePropagation]: https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation
@seanpdoyle seanpdoyle mentioned this pull request Sep 28, 2022
Merged
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 28, 2022
@seanpdoyle
Prevent double requests from within turbo-frame
1213774 
Closes hotwired#743

The change in behavior can be traced back to [hotwired#412][].
When the overlap between the `LinkInterceptor` and the
`LinkClickObserver` were unified, the technique used by the
`LinkInterceptor` to prevent duplicate event handlers from responding to
the same `click` event was changed in a subtle way.

In its place, this commit changes the `LinkClickObserver` to monopolize
its handling of `click` events on `<a>` elements that navigate the page
or drive `<turbo-frame>` elements. In tandem with the existing call to
[Event.preventDefault][], this commit adds a call to
[Event.stopImmediatePropagation][].

To exercise this edge case, this commit also adds a `ujs.html` fixture
file along with a `ujs_tests.ts` module to cover situations when
`@rails/ujs` and `@hotwired/turbo` co-exist.

[hotwired#412]: hotwired#412
[Event.preventDefault]: https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault
[Event.stopImmediatePropagation]: https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 30, 2022
@seanpdoyle
Prevent double requests from within turbo-frame
3db3efd 
Closes hotwired#743

The change in behavior can be traced back to [hotwired#412][].
When the overlap between the `LinkInterceptor` and the
`LinkClickObserver` were unified, the technique used by the
`LinkInterceptor` to prevent duplicate event handlers from responding to
the same `click` event was changed in a subtle way.

In its place, this commit changes the `LinkClickObserver` and
`FormSubmitObserver` to ignore `<a>` clicks and `<form>` submissions if
they're annotated with `[data-remote="true"]`.

To exercise these edge cases, this commit also adds a `ujs.html` fixture
file along with a `ujs_tests.ts` module to cover situations when
`@rails/ujs` and `@hotwired/turbo` co-exist.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Sep 30, 2022
@seanpdoyle
Prevent double requests from within turbo-frame
5871173 
Closes hotwired#743

The change in behavior can be traced back to [hotwired#412][].
When the overlap between the `LinkInterceptor` and the
`LinkClickObserver` were unified, the technique used by the
`LinkInterceptor` to prevent duplicate event handlers from responding to
the same `click` event was changed in a subtle way.

In its place, this commit changes the `LinkClickObserver` and
`FormSubmitObserver` to ignore `<a>` clicks and `<form>` submissions if
they're annotated with `[data-remote="true"]`.

To exercise these edge cases, this commit also adds a `ujs.html` fixture
file along with a `ujs_tests.ts` module to cover situations when
`@rails/ujs` and `@hotwired/turbo` co-exist.

[hotwired#412]: hotwired#412
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Oct 6, 2022
@seanpdoyle
adjust after reverting hotwired#412
6391da6
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Oct 6, 2022
@seanpdoyle
adjust after reverting hotwired#412
1b780ba
seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Oct 6, 2022
@seanpdoyle
adjust after reverting hotwired#412
fa20fcd
dhh pushed a commit that referenced this pull request Oct 8, 2022
@seanpdoyle
Ignore UJS <a> clicks and <form> submissions (#744)
2345af9 
* Prevent double requests from within `turbo-frame`

Closes #743

The change in behavior can be traced back to [#412][].
When the overlap between the `LinkInterceptor` and the
`LinkClickObserver` were unified, the technique used by the
`LinkInterceptor` to prevent duplicate event handlers from responding to
the same `click` event was changed in a subtle way.

In its place, this commit changes the `LinkClickObserver` and
`FormSubmitObserver` to ignore `<a>` clicks and `<form>` submissions if
they're annotated with `[data-remote="true"]`.

To exercise these edge cases, this commit also adds a `ujs.html` fixture
file along with a `ujs_tests.ts` module to cover situations when
`@rails/ujs` and `@hotwired/turbo` co-exist.

[#412]: #412

* Revert "Replace LinkInterceptor with LinkClickObserver"

This reverts commit 9bef653.

* adjust after reverting #412

* Restore `<form data-remote="true">`+`<turbo-frame>` behavior from 7.1.0

[comment]: #744 (comment)
[FormInterceptor]: https://github.com/hotwired/turbo/blob/v7.1.0/src/core/frames/form_interceptor.ts#L31
@manuelpuyol manuelpuyol mentioned this pull request Nov 4, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
7.2.0
Development

Successfully merging this pull request may close these issues.
2 participants
@seanpdoyle @dhh