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

Turbo Frame events question #56

Closed
jonsgreen opened this issue Dec 29, 2020 · 2 comments
Closed

Turbo Frame events question #56

jonsgreen opened this issue Dec 29, 2020 · 2 comments

Comments

@jonsgreen
Copy link

First of all, thanks to all of the developers on this project for this lovely holiday surprise gift.

I am part of a small team of developers and today we were playing with adding some javascript/css that would add some minimal styling of turbo-frames for debugging/learning purposes. This mostly worked well when hooking into a turbo:load event; however, when just a frame was being replaced we found that there was not an event we could handle in order to update an attribute on the frame being used for debugging. Is there a way to hook into the replace event?

Also, I am very excited about the direction of hotwire and would like to contribute in some way that would be helpful while also giving me a better understanding of the internals of the code. What is the best way to get involved at this time?
@seanpdoyle
Copy link
Contributor

Is this similar to hotwired/turbo#54?

seanpdoyle added a commit to hotwired/turbo that referenced this issue Dec 30, 2020
@seanpdoyle
Dispatch lifecycle events within turbo-frames
82a291b 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch life cycle events from within the `FrameController` and
`FrameRedirector` when a `<turbo-frame>` element is navigated. The
events _do not bubble_ since the conventional (and historical) style of
`turbolinks:` and `turbo:` event listeners has been to declare them on
the page's `document.documentElement`. If the `<turbo-frame>` events
were to bubble, either _all_ application-land event listeners would be
required to change, or else they would fire multiple times as the event
bubbled up the document.

Some tangential changes:

* Change `dispatch` default `{ bubbles: true }` value to be an argument
  instead
* Delete `TimingData` in favor of `TimingMetrics` and `TimingMetric`
seanpdoyle added a commit to hotwired/turbo that referenced this issue Dec 30, 2020
@seanpdoyle
Dispatch lifecycle events within turbo-frames
7922187 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch life cycle events from within the `FrameController` and
`FrameRedirector` when a `<turbo-frame>` element is navigated. The
events _do not bubble_ since the conventional (and historical) style of
`turbolinks:` and `turbo:` event listeners has been to declare them on
the page's `document.documentElement`. If the `<turbo-frame>` events
were to bubble, either _all_ application-land event listeners would be
required to change, or else they would fire multiple times as the event
bubbled up the document.

Some tangential changes:

* Change `dispatch` default `{ bubbles: true }` value to be an argument
  instead
* Delete `TimingData` in favor of `TimingMetrics` and `TimingMetric`
@seanpdoyle seanpdoyle mentioned this issue Dec 30, 2020
Closed
@dhh
Copy link
Member

dhh commented Dec 30, 2020

Yeah, I'd love to have a debug CSS mode that calls out both frame replacements and stream updates. This should go on hotwired/turbo, though. Please give it a go.

@dhh dhh closed this as completed Dec 30, 2020
seanpdoyle added a commit to hotwired/turbo that referenced this issue Feb 4, 2021
@seanpdoyle
Dispatch lifecycle events within turbo-frames
6483ef0 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-*` and `turbo:before-frame-*` life cycle events
from within the `FrameController` and `FrameRedirector` when a
`<turbo-frame>` element is navigated. The events bubble, and
`turbo:before-frame-visit` is cancellable.

Some tangential changes:
---

* Delete `TimingData` interface in favor of the pre-existing
  `TimingMetrics` and `TimingMetric`

Loose ends:
---

* In an effort to maintain symmetry with existing `turbo:` events, this
  change includes `turbo:before-frame-cache`, but since Turbo Frames
  does not have any caching infrastructure in place for `<turbo-frame>`
  elements, it fires immediately before `turbo:before-frame-render`.

* Does not dispatch `turbo:submit-start` or `turbo:submit-end` events,
  since they bubble up from the forms themselves.

* Does not dispatch `turbo:before-fetch-request` or
  `turbo:before-fetch-response`, since I couldn't find away to access
  the source element to serve as the dispatcher.

* Dispatches `turbo:frame-visit` and `turbo:frame-load` as part of the
  `visit` call's `resolveVisitPromise` chain. I had attempted to call
  them as part of the `FetchRequestDelegate.request{Started,Finished}`
  methods, but the asynchronicity involved there caused them to fire out
  of order
seanpdoyle added a commit to hotwired/turbo that referenced this issue Feb 4, 2021
@seanpdoyle
Dispatch lifecycle events within turbo-frames
d65f931 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-*` and `turbo:before-frame-*` life cycle events
from within the `FrameController` and `FrameRedirector` when a
`<turbo-frame>` element is navigated. The events bubble, and
`turbo:before-frame-visit` is cancellable.

Some tangential changes:
---

* Delete `TimingData` interface in favor of the pre-existing
  `TimingMetrics` and `TimingMetric`

Loose ends:
---

* In an effort to maintain symmetry with existing `turbo:` events, this
  change includes `turbo:before-frame-cache`, but since Turbo Frames
  does not have any caching infrastructure in place for `<turbo-frame>`
  elements, it fires immediately before `turbo:before-frame-render`.

* Does not dispatch `turbo:submit-start` or `turbo:submit-end` events,
  since they bubble up from the forms themselves.

* Does not dispatch `turbo:before-fetch-request` or
  `turbo:before-fetch-response`, since I couldn't find away to access
  the source element to serve as the dispatcher.

* Dispatches `turbo:frame-visit` and `turbo:frame-load` as part of the
  `visit` call's `resolveVisitPromise` chain. I had attempted to call
  them as part of the `FetchRequestDelegate.request{Started,Finished}`
  methods, but the asynchronicity involved there caused them to fire out
  of order
seanpdoyle added a commit to hotwired/turbo that referenced this issue Feb 12, 2021
@seanpdoyle
Dispatch lifecycle events within turbo-frames
4979adf 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-*` and `turbo:before-frame-*` life cycle events
from within the `FrameController` and `FrameRedirector` when a
`<turbo-frame>` element is navigated. The events bubble, and
`turbo:before-frame-visit` is cancellable.

Some tangential changes:
---

* Delete `TimingData` interface in favor of the pre-existing
  `TimingMetrics` and `TimingMetric`

Loose ends:
---

* In an effort to maintain symmetry with existing `turbo:` events, this
  change includes `turbo:before-frame-cache`, but since Turbo Frames
  does not have any caching infrastructure in place for `<turbo-frame>`
  elements, it fires immediately before `turbo:before-frame-render`.

* Does not dispatch `turbo:submit-start` or `turbo:submit-end` events,
  since they bubble up from the forms themselves.

* Does not dispatch `turbo:before-fetch-request` or
  `turbo:before-fetch-response`, since I couldn't find away to access
  the source element to serve as the dispatcher.

* Dispatches `turbo:frame-visit` and `turbo:frame-load` as part of the
  `visit` call's `resolveVisitPromise` chain. I had attempted to call
  them as part of the `FetchRequestDelegate.request{Started,Finished}`
  methods, but the asynchronicity involved there caused them to fire out
  of order
seanpdoyle added a commit to hotwired/turbo that referenced this issue Mar 6, 2021
@seanpdoyle
Dispatch lifecycle events within turbo-frames
d27b5cd 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-*` and `turbo:before-frame-*` life cycle events
from within the `FrameController` and `FrameRedirector` when a
`<turbo-frame>` element is navigated. The events bubble, and
`turbo:before-frame-visit` is cancellable.

Some tangential changes:
---

* Delete `TimingData` interface in favor of the pre-existing
  `TimingMetrics` and `TimingMetric`

Loose ends:
---

* In an effort to maintain symmetry with existing `turbo:` events, this
  change includes `turbo:before-frame-cache`, but since Turbo Frames
  does not have any caching infrastructure in place for `<turbo-frame>`
  elements, it fires immediately before `turbo:before-frame-render`.

* Does not dispatch `turbo:submit-start` or `turbo:submit-end` events,
  since they bubble up from the forms themselves.

* Does not dispatch `turbo:before-fetch-request` or
  `turbo:before-fetch-response`, since I couldn't find away to access
  the source element to serve as the dispatcher.

* Dispatches `turbo:frame-visit` and `turbo:frame-load` as part of the
  `visit` call's `resolveVisitPromise` chain. I had attempted to call
  them as part of the `FetchRequestDelegate.request{Started,Finished}`
  methods, but the asynchronicity involved there caused them to fire out
  of order
seanpdoyle added a commit to hotwired/turbo that referenced this issue Apr 14, 2021
@seanpdoyle
Dispatch turbo:frame-load on turbo-frame
a275260 
Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-load` lifecycle event when `<turbo-frame>` element
is navigated and finishes loading. The events bubble up, with the
`<turbo-frame>` element as the target.

Originally, this pull request involved numerous events, but in the
spirit of experimentation, we'll start with the one and see if others
are necessary.
kapantzak pushed a commit to kapantzak/turbo that referenced this issue Aug 25, 2021
@seanpdoyle
Dispatch turbo:frame-load on turbo-frame
e506c7d 
Closes hotwired#54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-load` lifecycle event when `<turbo-frame>` element
is navigated and finishes loading. The events bubble up, with the
`<turbo-frame>` element as the target.

Originally, this pull request involved numerous events, but in the
spirit of experimentation, we'll start with the one and see if others
are necessary.
dhh added a commit to hotwired/turbo that referenced this issue Aug 25, 2021
@kapantzak @dhh @seanpdoyle
Fire 'turbo:frame-render' event after turbo frame renders the view (#327
84b0a89 
)

* Fire 'turbo:after-fetch-render' event after turbo frame renders the view

* fixup! Fire 'turbo:after-fetch-render' event after turbo frame renders the view

* Change 'turbo:after-fetch-render' event to 'turbo:frame-render'

* Implement notifyApplicationAfterFrameRender in order to dispatch the 'turbo:frame-render' event

* Dispatch `turbo:frame-load` on turbo-frame

Closes #54
Closes hotwired/turbo-rails#56

Dispatch `turbo:frame-load` lifecycle event when `<turbo-frame>` element
is navigated and finishes loading. The events bubble up, with the
`<turbo-frame>` element as the target.

Originally, this pull request involved numerous events, but in the
spirit of experimentation, we'll start with the one and see if others
are necessary.

* fixup! Dispatch `turbo:frame-load` on turbo-frame

Co-authored-by: John Kapantzakis <kapantzak@192.168.2.2>
Co-authored-by: David Heinemeier Hansson <david@loudthinking.com>
Co-authored-by: Sean Doyle <sean.p.doyle24@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Dispatch turbo:frame-load on turbo-frame hotwired/turbo
3 participants
@dhh @jonsgreen @seanpdoyle