-
Notifications
You must be signed in to change notification settings - Fork 328
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
Render full documents for requests with Turbo-Frame:
header
#534
base: main
Are you sure you want to change the base?
Render full documents for requests with Turbo-Frame:
header
#534
Conversation
As an alternative, we could send the Turbo Action in the Turbo-Action: header, then conditionally include the full layout if that header is present. |
98b0854
to
925c707
Compare
@jorgemanrubia is this change worth re-considering after the introduction of Page Morphing? To paraphrase the Morphing mental model: "render full HTML documents on the server, then let the client decide how to insert that new content into the document". Rendering full and valid documents for Turbo Frames is likely to result in similar levels of queries, template renders, and over-the-wire traffic as a full page refresh with Morphing. That also means they stand to benefit from the same kinds of rendering mechanisms that Morphing might influence you to adopt (fragment caching, HTTP caching, etc). |
@seanpdoyle the removed layout should only kick in for requests with a Turbo Frame header. Could you put an example of how page refreshes with morphing doesn't play well with this? They seem like unrelated systems to me. |
I'm sorry for being unclear. I'm suggesting that the Turbo Frame server-side mental model change to be more like Morphing. MorphingWhen submitting a form that redirects back or navigating a link that replaces the page, the server sends a fully formed document. As I understand, the value proposition of a Morphing page refresh is that the server does not care about the diff between what its rendering and what's on the client -- the client will handle negotiating the new content into the existing content. Even if the entirety of the new content is a new flash message, the full Furthermore, the client doesn't communicate anything special to the server. Other than being FramesFrom the client's perspective, frames behave in a similar way. Regardless of the contents of the response HTML, Turbo will find the From the server's perspective, the similarities break down. The The concept of Frames pre-dates Morphing. In a world where applications are encouraged to enable Morphing for the majority of their pages (instead of other approaches like Frame or Stream form submission responses), any gains won by So what?Over time, the The proposal is that by reversing the optimization and re-establishing the traditional Turbolinks expectations (that the servers responds with full HTML documents and the client expects full HTML documents), we have an opportunity to posit a singular simplified mental model and simplify some of |
925c707
to
8e4c72b
Compare
Re-submission of [hotwired#232][] Related to [hotwired/turbo#1047][] Render full documents, including default layout rendering behavior. Rendering a minimal layout forces `turbo:reload` events because of the severe difference in the contents of the minimal layout's `<head>` and the requesting document's fully populated `<head>`. [hotwired#232]: hotwired#232 [hotwired/turbo#1047]: hotwired/turbo#1047
8e4c72b
to
7ca7a35
Compare
Re-submission of #232
Related to hotwired/turbo#1047
Render full documents, including default layout rendering behavior.
Rendering a minimal layout forces
turbo:reload
events because of the severe difference in the contents of the minimal layout's<head>
and the requesting document's fully populated<head>
.