-
Notifications
You must be signed in to change notification settings - Fork 435
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
Check new snapshot (instead of previous) for refresh-method #1123
Check new snapshot (instead of previous) for refresh-method #1123
Conversation
@seanpdoyle @afcapel Could you give this a quick review. This is behavior a minor source of friction getting Turbo 8 adopted on Django projects. |
src/core/drive/page_view.js
Outdated
@@ -16,7 +16,7 @@ export class PageView extends View { | |||
} | |||
|
|||
renderPage(snapshot, isPreview = false, willRender = true, visit) { | |||
const shouldMorphPage = this.isPageRefresh(visit) && this.snapshot.shouldMorphPage | |||
const shouldMorphPage = this.isPageRefresh(visit) && snapshot.shouldMorphPage && this.snapshot.shouldMorphPage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scuml thank you for opening this PR.
Conceptually, I wonder if we should be checking the current snapshot at all. For example, when determining whether to initiate a Visit or a Full Reload, The PageRenderer
only scans the new snapshot head for a <meta>
element:
Similarly, when using the same <meta>
to determine whether to "Break out" of a Frame, the FrameController
scans the new snapshot:
@afcapel @jorgemanrubia I wonder, is this sufficient?
const shouldMorphPage = this.isPageRefresh(visit) && snapshot.shouldMorphPage && this.snapshot.shouldMorphPage | |
const shouldMorphPage = this.isPageRefresh(visit) && snapshot.shouldMorphPage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting you mention that, as that was my initial implementation: c3eacbc
I put the other check in as a safety if I missed a use-case - but thinking of it along the lines of "breaking out of a frame", I think you are right that the 'current page check' can be removed.
This would also offer the user an extra degree of freedom where they can now opt-out and opt-back in to a morph render.
Tests passing and ready to merge. |
Would it make sense to update the title of the PR to reflect the actual implemented behavior (ie. only check the new snapshot)? |
Title updated. Could we get this merged in? |
@jorgemanrubia @afcapel are either of you able to review this change? |
@jorgemanrubia @afcapel -- another request for your review. Should be quick. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afcapel Approved and ready to merge. |
Thanks @scuml ! |
While trying to port the Turbo Morph Demo over to Django, I found that if a form submission returns a classic django error page, the morph renderer is still used, causing an undesired blend of the previous pages tags with the error page's content.
Since morphing is predicated on the idea of a full-page refresh, the tag
<meta name="turbo-refresh-method" content="morph">
should be on all responses that intend to be morphed, and if not (as the case of an error page), it would be ideal to fallback on the full page renderer.This PR checks both the current page AND the upcoming snapshot for the meta setting
refresh-method='morph'
to determine if the morph renderer should be used, instead of just the originating page.ScreenFlow.mp4