-
-
Notifications
You must be signed in to change notification settings - Fork 455
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
Support Preview Mode #562
Support Preview Mode #562
Conversation
13fb79b
to
e54d915
Compare
bd82c46
to
5f28647
Compare
@danielcondemarin marking this as draft for now. I have added rollup and am bundling the default handler. As a result of this, the build step for this package is getting fragmented, with one thing for default lambda and another for the api lambda and the build function (also, the bundler needs a different tsconfig). Should we bundle the api lambda too? For now I am just telling the TS process for the existing build to ignore the default lambda file, and letting it get handled by rollup. We can have 2 sub-builds, one for the lambdas and one for the build function, with both going into the |
If it isn't much extra work go for it. There is refactor that could be made once the handler is bundled like splitting logic into other files etc.
Sounds good to me 👍 |
d40579b
to
2ce1d38
Compare
@danielcondemarin this is good for review. I will squash the commits before we merge and close this though.
|
- Fixed expected uri in origin response. - Added util to rollup externals as it was breaking.
- Fixed some erroneous logic in the router, since it's now being used in the response handler - Mocked console errors in tests
c60d647
to
6b95135
Compare
@@ -272,7 +313,17 @@ const handleOriginRequest = async ({ | |||
} |
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.
I think this can be moved into the else block below just before the await page.render(req, res)
, so we don't have to check whether it is error page every time
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.
Does that mean we know for a fact that data requests will not result in a possible error page?
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.
Ah, I guess unmatched data request can still go to pages/_error.js
, maybe still need this at the start
|
||
it("handles preview mode", async () => { | ||
const event = createCloudFrontEvent({ | ||
uri: "/preview", |
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.
I think you would need to append trailing slash if trailingSlash
is true to the URI, this test runs with both trailingSlash
true and false
} | ||
}); | ||
|
||
if (trailingSlash) { |
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.
You shouldn't need the trailingSlash
block here, I added a redirect test where you can add /preview
as one of the tests, it will test both kinds of redirects
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.
You mean changing the URI in createCloudFrontEvent
to be either /preview
or /preview/
depending on whether trailingSlash
is true, and then just testing for the expected response?
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.
Yep, basically if trailingSlash is true then you can pass /preview/
as the URI, otherwise it is /preview
.
Then you can add the same path /preview
as a test case in redirect test, it will auto append trailing slash and test the redirects
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.
Done.
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.
Also i think you can add /preview
to redirect test (around line 158).
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.
Done.
prerenderManifest.preview.previewModeSigningKey | ||
); | ||
} catch (e) { | ||
return { |
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.
Maybe some logging (at info level?) is useful here, I added it for 500 page as well, not sure if it's needed for this though
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.
I added a console.error
, similar to the logging for the 500 response.
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.
Seems fine to me besides minor comments, probably @danielcondemarin should approve since it's a bigger change
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.
🚀
I'll do some testing and get an alpha published tonight 👍 |
#355
Changes
lambda-at-edge-compat
res.writeHead(...).end()
, so we have to return the res inwriteHead
.lambda-at-edge
Caveat
Handling a client side transition in preview mode is not really supported beyond the first transition. After this, NextJS caches the JSON response in memory and does not even issue a new request if you navigate back to that page in the same session (without a refresh). Consider the following steps:
mysite.com/blog/1
(an SSG page)mysite.com/blog/1
is SSR'd because we are in preview modemysite.com/blog/2
usingnext/link
mysite.com/blog/1
usingnext/link