-
Notifications
You must be signed in to change notification settings - Fork 430
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
Replace LinkInterceptor with LinkClickObserver #412
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
seanpdoyle
force-pushed
the
frame-link-click-observer
branch
from
November 9, 2021 13:38
159e600
to
4c25b6c
Compare
Same re: rebase and 7.2.0. |
seanpdoyle
force-pushed
the
frame-link-click-observer
branch
6 times, most recently
from
July 19, 2022 00:45
719137f
to
9701ebf
Compare
seanpdoyle
force-pushed
the
frame-link-click-observer
branch
5 times, most recently
from
July 30, 2022 11:25
d0e50f6
to
c261589
Compare
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
force-pushed
the
frame-link-click-observer
branch
from
July 31, 2022 23:50
c261589
to
9bef653
Compare
dhh
added a commit
to seanpdoyle/turbo
that referenced
this pull request
Aug 3, 2022
* 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)
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this pull request
Sep 21, 2022
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
added a commit
to seanpdoyle/turbo
that referenced
this pull request
Sep 21, 2022
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
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
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
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
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
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
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 28, 2022
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
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
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
added a commit
to seanpdoyle/turbo
that referenced
this pull request
Oct 6, 2022
seanpdoyle
added a commit
to seanpdoyle/turbo
that referenced
this pull request
Oct 6, 2022
dhh
pushed a commit
that referenced
this pull request
Oct 8, 2022
* 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #382
In the same style as hotwired/turbo#382, replace instances of
LinkInterceptor
withLinkClickObserver
, making the necessaryinterface changes in classes that used to extend
LinkInterceptorDelegate
.Conditional logic that was once covered in the
LinkInterceptor
ismoved into the predicate methods of the delegates (for example, the
FrameController.willFollowLinkToLocation
andFrameRedirector.willFollowLinkToLocation
).Since the recently introduced FormLinkInterceptor was named after
the
LinkInterceptor
, this commit also renames that class (and its callsites) to match the
LinkClickObserver
-suffix, along with theLinkInterceptorDelegate
method structure.