RFC: Preview Mode #142
migueloller
started this conversation in
Ideas
Replies: 2 comments 3 replies
-
Looks great! One question - would this mean that preview mode is enabled if the site is loaded in any iframe, not just the Makeswift preview one? What if I'd like to be able to embed my site elsewhere without enabling these preview features? Could be worth exploring a quick back-and-forth with |
Beta Was this translation helpful? Give feedback.
3 replies
-
Preview Mode support has been released in v0.2.0! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Background
When integrating your Next.js app into Makeswift you have to create a preview page (e.g.,
pages/makeswift.js
). This page is is rendered by Makeswift in aniframe
and communicates with the Makeswift builder viapostMessage
so you can visually edit your Next.js app.When editing in the Makeswift builder you expect to see your page’s latest draft, not the published version. That’s why the preview page uses
getServerSideProps
and requests the page’s draft while other pages most likely usegetStaticProps
and request the published version of the page.Having this separate preview page has worked so far, but there are a couple of problems with it:
Proposal
We propose adding native support for Next.js’ Preview Mode to Makeswift.
When using the Makeswift builder (i.e., editing the draft version of the page in the
iframe
) Preview Mode should always be on.When visiting a published page, Preview Mode should always be off.
The goal is to make it transparent both for developers integrating Makeswift with their Next.js app and end-users using the Makeswift app to do visually edits.
Read on for details about how this will be implemented, what we’ve explored, and future plans ☕
Makeswift API Route
Inspired by NextAuth.js we propose an API route that must be created when integrating Makeswift into your Next.js app:
pages/api/makeswift/[...makeswift].js
.This API route will be used to handle Preview Mode functionality:
pages/api/makeswift/preview
pages/api/makeswift/clear-preview-mode-cookies
Future Plans
In addition to handling Preview Mode, the Makeswift API route will also be used for other features we’re currently working on:
Toggling Preview Mode On & Off
After trying different approaches, we found that the most reliable way to ensure Preview Mode is always-on in the Makeswift builder
iframe
and always-off when not in theiframe
was to use JavaScript to detect theiframe
and then redirecting to the relevant API route that configures Preview Mode.Configuring Preview Mode on initial page load with a
script
in thehead
To avoid a flash of incorrect data we need to make sure that our logic runs as soon as possible. We could try using
next/head
but placing ascript
innext/head
results in a Next.js warning to usenext/script
instead because of potential issues with Suspense and/or streaming.next/script
could be used with a strategy ofbeforeInteractive
but this is only allowed in_document.js
. We can check for Preview Mode in_document.js
usingprops.__NEXT_DATA__.isPreview
. Adding this logic to_document.js
would make it harder for us to eventually remove_document.js
as part of integrating Makeswift to your Next.js app.🚧 We will continue to explore more solutions and collaborate with the Next.js team to make sure this works well with Suspense and streaming once those features reach GA.
Configuring Preview Mode on client-side navigation by patching
fetch
andXMLHttpRequest
When doing client-side route changes, things get a bit trickier. Next.js will usually render the next page with the current Preview Mode state before the browser navigates away. The most reliable approach that we found was patching
fetch
andXMLHttpRequest
so that we can ensure the correct values for Preview Mode cookies are set. We’ve had success monkey-patching the Next.js router’sgetRouteInfo
method, though, doing something like this:Backwards Compatibility
We will be deprecating the preview page in favor of the new Makeswift API route and Next.js Preview Mode.
Alternative Approaches
Rewriting to an API route to proxy the page and inject Preview Mode cookies
One approach we considered early on was creating a rewrite rule to an API route that proxies all pages and configures Preview Mode. The rewrites could be added automatically by a Makeswift Next.js plugin.
This approach is not only the simplest in terms of integration surface area, but also potentially the most reliable, since it would handle both initial load and subsequent client-side navigation since Next.js’ router applies rewrites in the server and client.
Unfortunately this doesn’t work because during hydration, Next.js treats the rewrite destination as a page and attempts to load it at
_next/static/chunks/pages/api/makeswift/preview.js
, which results in a 404 error. This error then causes a reload of the page, and once hydration happens, the request fails again. This goes on and on in an infinite loop.Patching Next.js’ router instead of
fetch
andXMLHttpRequest
Before deciding to patch
fetch
andXMLHttpRequest
we explored patching Next.js’ router but found that this would be unreliable and would break as internal Next.js APIs changed. Patching platform APIs is much more reliable and stable.Beta Was this translation helpful? Give feedback.
All reactions