-
Notifications
You must be signed in to change notification settings - Fork 330
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
turbo:frame-load in turbo_stream not triggering #379
Comments
Currently, a Having said that, I could see a case for dispatching a Unfortunately, the current implementation and documentation for I'll open a Pull Request against In the meantime, you might want to declare a Stimulus controller, render |
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
I've opened hotwired/turbo#702 to explore the implications of dispatching |
Amazing, thanks 🥳 |
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Closes hotwired/turbo-rails#379 Currently, a `<turbo-frame>` element only dispatches events when its contents are fetched over HTTP. The `turbo:frame-render` and `turbo:frame-load` events are dispatched sequentially and immediately following one another. The `turbo:frame-render` detail exposes a reference to the `FetchResponse`, while the `turbo:frame-load` event has no details. Consumer applications might expect a `<turbo-frame>` to dispatch a `turbo:frame-render` event immediately whenever a `<turbo-frame>` is connected to the document (similar to the way that `turbo:render` is dispatched prior to `turbo:load`, even on restoration Visits). For the sake of consistency and distinguishing between two events that are more or less equivalent and temporally interchangeable, this commit proposes that a `<turbo-frame>` should dispatch a `turbo:frame-render` _whenever its contents change_, including its initial render. As a complementary change to that behavior, the `turbo:frame-load` events will be dispatched with `detail.fetchResponse` as a reference to the `FetchResponse`. Ideally, the `turbo:frame-render` would not expose the `detail.fetchResponse` reference. However, removing it would be a breaking change. To that end, this commit dispatches a `detail` that prints a console warning (encouraging a migration to `turbo:frame-load`) whenever a `turbo:frame-render` listener reads the `detail.fetchResponse` property. Future major releases can remove the property and warning.
Just adding detail to the implementation mentioned. If you have a stimulus controller that has the method you want to execute already attached to some view then your turbo stream can render the view with a local like
when the view renders you can conditionally connect a new controller
And the new controller can call the existing controller's method
|
Hi,
I am trying to execute some common JS code whenever the contents of a turbo-frame are rendered. But I am having some issues when the turbo-frame is updated via turbo_stream. It seems like the
turbo:frame-load
event is not happening.edit.html.slim
academic_years_controller.rb
update.turbo_stream.erb
I don't see the
turbo:frame-load
happening, despite the fact that the frame is correctly updated.What am I misunderstanding? How can I execute code after a frame is updated via turbo_stream?
Thanks
The text was updated successfully, but these errors were encountered: