2022-05-02 12:18:16 +02:00
|
|
|
import { createNext, FileRef } from 'e2e-utils'
|
2022-09-09 00:17:15 +02:00
|
|
|
import crypto from 'crypto'
|
2022-05-02 12:18:16 +02:00
|
|
|
import { NextInstance } from 'test/lib/next-modes/base'
|
2022-08-31 15:13:47 +02:00
|
|
|
import { check, fetchViaHTTP, renderViaHTTP, waitFor } from 'next-test-utils'
|
2022-05-02 12:18:16 +02:00
|
|
|
import path from 'path'
|
|
|
|
import cheerio from 'cheerio'
|
|
|
|
import webdriver from 'next-webdriver'
|
|
|
|
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
describe('app dir', () => {
|
2022-07-15 13:02:37 +02:00
|
|
|
const isDev = (global as any).isNextDev
|
|
|
|
|
2022-05-21 11:46:16 +02:00
|
|
|
if ((global as any).isNextDeploy) {
|
|
|
|
it('should skip next deploy for now', () => {})
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2022-05-05 13:15:32 +02:00
|
|
|
if (process.env.NEXT_TEST_REACT_VERSION === '^17') {
|
|
|
|
it('should skip for react v17', () => {})
|
|
|
|
return
|
|
|
|
}
|
2022-05-02 12:18:16 +02:00
|
|
|
let next: NextInstance
|
|
|
|
|
2022-09-20 03:17:16 +02:00
|
|
|
function runTests() {
|
2022-08-02 00:34:23 +02:00
|
|
|
beforeAll(async () => {
|
|
|
|
next = await createNext({
|
2022-09-14 01:01:43 +02:00
|
|
|
files: new FileRef(path.join(__dirname, 'app')),
|
2022-08-02 00:34:23 +02:00
|
|
|
dependencies: {
|
|
|
|
react: 'experimental',
|
|
|
|
'react-dom': 'experimental',
|
|
|
|
},
|
|
|
|
skipStart: true,
|
|
|
|
})
|
2022-07-13 09:27:09 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
await next.start()
|
|
|
|
})
|
|
|
|
afterAll(() => next.destroy())
|
2022-06-29 21:28:48 +02:00
|
|
|
|
2022-09-18 22:49:05 +02:00
|
|
|
it('should use application/octet-stream for flight', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/dashboard/deployments/123?__flight__'
|
|
|
|
)
|
|
|
|
expect(res.headers.get('Content-Type')).toBe('application/octet-stream')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should use application/octet-stream for flight with edge runtime', async () => {
|
|
|
|
const res = await fetchViaHTTP(next.url, '/dashboard?__flight__')
|
|
|
|
expect(res.headers.get('Content-Type')).toBe('application/octet-stream')
|
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should pass props from getServerSideProps in root layout', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('title').text()).toBe('hello world')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve from pages', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/')
|
|
|
|
expect(html).toContain('hello from pages/index')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve dynamic route from pages', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/blog/first')
|
|
|
|
expect(html).toContain('hello from pages/blog/[slug]')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve from public', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/hello.txt')
|
|
|
|
expect(html).toContain('hello world')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve from app', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard')
|
|
|
|
expect(html).toContain('hello from app/dashboard')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve /index as separate page', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/index')
|
|
|
|
expect(html).toContain('hello from app/dashboard/index')
|
|
|
|
// should load chunks generated via async import correctly with React.lazy
|
|
|
|
expect(html).toContain('hello from lazy')
|
|
|
|
// should support `dynamic` in both server and client components
|
|
|
|
expect(html).toContain('hello from dynamic on server')
|
|
|
|
expect(html).toContain('hello from dynamic on client')
|
|
|
|
})
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// TODO-APP: handle css modules fouc in dev
|
|
|
|
it.skip('should handle css imports in next/dynamic correctly', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/dashboard/index')
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('#css-text-dynamic-server')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(0, 0, 255)')
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('#css-text-lazy')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(128, 0, 128)')
|
|
|
|
})
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should include layouts when no direct parent layout', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/integrations')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
// Should not be nested in dashboard
|
|
|
|
expect($('h1').text()).toBe('Dashboard')
|
|
|
|
// Should include the page text
|
|
|
|
expect($('p').text()).toBe('hello from app/dashboard/integrations')
|
|
|
|
})
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: handle new root layout
|
2022-08-02 00:34:23 +02:00
|
|
|
it.skip('should not include parent when not in parent directory with route in directory', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/hello')
|
|
|
|
const $ = cheerio.load(html)
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// new root has to provide it's own custom root layout or the default
|
|
|
|
// is used instead
|
|
|
|
expect(html).toContain('<html')
|
|
|
|
expect(html).toContain('<body')
|
|
|
|
expect($('html').hasClass('this-is-the-document-html')).toBeFalsy()
|
|
|
|
expect($('body').hasClass('this-is-the-document-body')).toBeFalsy()
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not be nested in dashboard
|
|
|
|
expect($('h1').text()).toBeFalsy()
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render the page text
|
|
|
|
expect($('p').text()).toBe('hello from app/dashboard/rootonly/hello')
|
|
|
|
})
|
2022-05-10 18:57:14 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should use new root layout when provided', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/another')
|
|
|
|
const $ = cheerio.load(html)
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// new root has to provide it's own custom root layout or the default
|
|
|
|
// is used instead
|
|
|
|
expect($('html').hasClass('this-is-another-document-html')).toBeTruthy()
|
|
|
|
expect($('body').hasClass('this-is-another-document-body')).toBeTruthy()
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not be nested in dashboard
|
|
|
|
expect($('h1').text()).toBeFalsy()
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render the page text
|
|
|
|
expect($('p').text()).toBe('hello from newroot/dashboard/another')
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should not create new root layout when nested (optional)', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/dashboard/deployments/breakdown'
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// new root has to provide it's own custom root layout or the default
|
|
|
|
// is used instead
|
|
|
|
expect($('html').hasClass('this-is-the-document-html')).toBeTruthy()
|
|
|
|
expect($('body').hasClass('this-is-the-document-body')).toBeTruthy()
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should be nested in dashboard
|
|
|
|
expect($('h1').text()).toBe('Dashboard')
|
|
|
|
expect($('h2').text()).toBe('Custom dashboard')
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render the page text
|
|
|
|
expect($('p').text()).toBe(
|
|
|
|
'hello from app/dashboard/(custom)/deployments/breakdown'
|
|
|
|
)
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should include parent document when no direct parent layout', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/integrations')
|
|
|
|
const $ = cheerio.load(html)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('html').hasClass('this-is-the-document-html')).toBeTruthy()
|
|
|
|
expect($('body').hasClass('this-is-the-document-body')).toBeTruthy()
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should not include parent when not in parent directory', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/changelog')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
// Should not be nested in dashboard
|
|
|
|
expect($('h1').text()).toBeFalsy()
|
|
|
|
// Should include the page text
|
|
|
|
expect($('p').text()).toBe('hello from app/dashboard/changelog')
|
|
|
|
})
|
2022-07-22 16:26:37 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve nested parent', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/deployments/123')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
// Should be nested in dashboard
|
|
|
|
expect($('h1').text()).toBe('Dashboard')
|
|
|
|
// Should be nested in deployments
|
|
|
|
expect($('h2').text()).toBe('Deployments hello')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve dynamic parameter', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard/deployments/123')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
// Should include the page text with the parameter
|
|
|
|
expect($('p').text()).toBe(
|
|
|
|
'hello from app/dashboard/deployments/[id]. ID is: 123'
|
|
|
|
)
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should include document html and body', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard')
|
|
|
|
const $ = cheerio.load(html)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('html').hasClass('this-is-the-document-html')).toBeTruthy()
|
|
|
|
expect($('body').hasClass('this-is-the-document-body')).toBeTruthy()
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should not serve when layout is provided but no folder index', async () => {
|
|
|
|
const res = await fetchViaHTTP(next.url, '/dashboard/deployments')
|
|
|
|
expect(res.status).toBe(404)
|
|
|
|
expect(await res.text()).toContain('This page could not be found')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: do we want to make this only work for /root or is it allowed
|
2022-08-02 00:34:23 +02:00
|
|
|
// to work for /pages as well?
|
|
|
|
it.skip('should match partial parameters', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/partial-match-123')
|
|
|
|
expect(html).toContain('hello from app/partial-match-[id]. ID is: 123')
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-09-15 16:53:51 +02:00
|
|
|
describe('rewrites', () => {
|
|
|
|
// TODO-APP:
|
|
|
|
it.skip('should support rewrites on initial load', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/rewritten-to-dashboard')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Dashboard')
|
|
|
|
expect(await browser.url()).toBe(`${next.url}/rewritten-to-dashboard`)
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should support rewrites on client-side navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/rewrites')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the link.
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#from-dashboard')
|
|
|
|
|
|
|
|
// Check to see that we were rewritten and not redirected.
|
|
|
|
expect(await browser.url()).toBe(`${next.url}/rewritten-to-dashboard`)
|
|
|
|
|
|
|
|
// Check to see that the page we navigated to is in fact the dashboard.
|
|
|
|
expect(await browser.elementByCss('#from-dashboard').text()).toBe(
|
|
|
|
'hello from app/dashboard'
|
|
|
|
)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-08-02 00:34:23 +02:00
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// TODO-APP: Enable in development
|
|
|
|
;(isDev ? it.skip : it)(
|
|
|
|
'should not rerender layout when navigating between routes in the same layout',
|
|
|
|
async () => {
|
|
|
|
const browser = await webdriver(next.url, '/same-layout/first')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Get the render id from the dom and click the first link.
|
|
|
|
const firstRenderID = await browser.elementById('render-id').text()
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#second-page')
|
|
|
|
|
|
|
|
// Get the render id from the dom again, it should be the same!
|
|
|
|
const secondRenderID = await browser.elementById('render-id').text()
|
|
|
|
expect(secondRenderID).toBe(firstRenderID)
|
|
|
|
|
|
|
|
// Navigate back to the first page again by clicking the link.
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#first-page')
|
|
|
|
|
|
|
|
// Get the render id from the dom again, it should be the same!
|
|
|
|
const thirdRenderID = await browser.elementById('render-id').text()
|
|
|
|
expect(thirdRenderID).toBe(firstRenderID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
2022-07-14 18:51:57 +02:00
|
|
|
}
|
2022-08-02 00:34:23 +02:00
|
|
|
)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should handle hash in initial url', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/dashboard#abc')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
|
|
|
try {
|
2022-08-02 00:34:23 +02:00
|
|
|
// Check if hash is preserved
|
|
|
|
expect(await browser.eval('window.location.hash')).toBe('#abc')
|
|
|
|
await waitFor(1000)
|
|
|
|
// Check again to be sure as it might be timed different
|
|
|
|
expect(await browser.eval('window.location.hash')).toBe('#abc')
|
2022-07-14 18:51:57 +02:00
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
2022-09-14 11:09:01 +02:00
|
|
|
describe('parallel routes', () => {
|
|
|
|
it('should match parallel routes', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/parallel/nested')
|
|
|
|
expect(html).toContain('parallel/layout')
|
|
|
|
expect(html).toContain('parallel/@foo/nested/layout')
|
|
|
|
expect(html).toContain('parallel/@foo/nested/@a/page')
|
|
|
|
expect(html).toContain('parallel/@foo/nested/@b/page')
|
|
|
|
expect(html).toContain('parallel/@bar/nested/layout')
|
|
|
|
expect(html).toContain('parallel/@bar/nested/@a/page')
|
|
|
|
expect(html).toContain('parallel/@bar/nested/@b/page')
|
|
|
|
expect(html).toContain('parallel/nested/page')
|
|
|
|
})
|
2022-09-06 19:03:21 +02:00
|
|
|
|
2022-09-14 11:09:01 +02:00
|
|
|
it('should match parallel routes in route groups', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/parallel/nested-2')
|
|
|
|
expect(html).toContain('parallel/layout')
|
|
|
|
expect(html).toContain('parallel/(new)/layout')
|
|
|
|
expect(html).toContain('parallel/(new)/@baz/nested/page')
|
|
|
|
})
|
2022-09-06 19:03:21 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('<Link />', () => {
|
2022-09-06 19:29:09 +02:00
|
|
|
it('should hard push', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/link-hard-push/123')
|
2022-08-02 00:34:23 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the link on the page, and verify that the history entry was
|
|
|
|
// added.
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
await browser.elementById('link').click()
|
2022-09-06 19:29:09 +02:00
|
|
|
await browser.waitForElementByCss('#render-id-456')
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.eval('window.history.length')).toBe(3)
|
|
|
|
|
|
|
|
// Get the id on the rendered page.
|
2022-09-06 19:29:09 +02:00
|
|
|
const firstID = await browser.elementById('render-id-456').text()
|
2022-08-02 00:34:23 +02:00
|
|
|
|
|
|
|
// Go back, and redo the navigation by clicking the link.
|
|
|
|
await browser.back()
|
|
|
|
await browser.elementById('link').click()
|
2022-09-06 19:29:09 +02:00
|
|
|
await browser.waitForElementByCss('#render-id-456')
|
2022-08-02 00:34:23 +02:00
|
|
|
|
|
|
|
// Get the id again, and compare, they should not be the same.
|
2022-09-06 19:29:09 +02:00
|
|
|
const secondID = await browser.elementById('render-id-456').text()
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(secondID).not.toBe(firstID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-09-06 19:29:09 +02:00
|
|
|
it('should hard replace', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/link-hard-replace/123')
|
2022-08-02 00:34:23 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the link on the page, and verify that the history entry was NOT
|
|
|
|
// added.
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
2022-09-06 19:29:09 +02:00
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id-456')
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Get the date again, and compare, they should not be the same.
|
2022-09-06 19:29:09 +02:00
|
|
|
const firstId = await browser.elementById('render-id-456').text()
|
2022-08-02 00:34:23 +02:00
|
|
|
|
|
|
|
// Navigate to the subpage, verify that the history entry was NOT added.
|
2022-09-06 19:29:09 +02:00
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id-123')
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Navigate back again, verify that the history entry was NOT added.
|
2022-09-06 19:29:09 +02:00
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id-456')
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Get the date again, and compare, they should not be the same.
|
2022-09-06 19:29:09 +02:00
|
|
|
const secondId = await browser.elementById('render-id-456').text()
|
|
|
|
expect(firstId).not.toBe(secondId)
|
2022-08-02 00:34:23 +02:00
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should soft push', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/link-soft-push')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the link on the page, and verify that the history entry was
|
|
|
|
// added.
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id')
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(3)
|
|
|
|
|
|
|
|
// Get the id on the rendered page.
|
|
|
|
const firstID = await browser.elementById('render-id').text()
|
|
|
|
|
|
|
|
// Go back, and redo the navigation by clicking the link.
|
|
|
|
await browser.back()
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
|
|
|
|
// Get the date again, and compare, they should be the same.
|
|
|
|
const secondID = await browser.elementById('render-id').text()
|
|
|
|
expect(firstID).toBe(secondID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-09-09 20:50:18 +02:00
|
|
|
// TODO-APP: investigate this test
|
|
|
|
it.skip('should soft replace', async () => {
|
2022-08-02 00:34:23 +02:00
|
|
|
const browser = await webdriver(next.url, '/link-soft-replace')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Get the render ID so we can compare it.
|
|
|
|
const firstID = await browser.elementById('render-id').text()
|
|
|
|
|
|
|
|
// Click the link on the page, and verify that the history entry was NOT
|
|
|
|
// added.
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
await browser.elementById('self-link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id')
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Get the id on the rendered page.
|
|
|
|
const secondID = await browser.elementById('render-id').text()
|
|
|
|
expect(secondID).toBe(firstID)
|
|
|
|
|
|
|
|
// Navigate to the subpage, verify that the history entry was NOT added.
|
|
|
|
await browser.elementById('subpage-link').click()
|
|
|
|
await browser.waitForElementByCss('#back-link')
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Navigate back again, verify that the history entry was NOT added.
|
|
|
|
await browser.elementById('back-link').click()
|
|
|
|
await browser.waitForElementByCss('#render-id')
|
|
|
|
expect(await browser.eval('window.history.length')).toBe(2)
|
|
|
|
|
|
|
|
// Get the date again, and compare, they should be the same.
|
|
|
|
const thirdID = await browser.elementById('render-id').text()
|
|
|
|
expect(thirdID).toBe(firstID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should be soft for back navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/with-id')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
try {
|
|
|
|
// Get the id on the rendered page.
|
|
|
|
const firstID = await browser.elementById('render-id').text()
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Click the link, and go back.
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#from-navigation')
|
|
|
|
await browser.back()
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Get the date again, and compare, they should be the same.
|
|
|
|
const secondID = await browser.elementById('render-id').text()
|
|
|
|
expect(firstID).toBe(secondID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should be soft for forward navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/with-id')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
try {
|
|
|
|
// Click the link.
|
|
|
|
await browser.elementById('link').click()
|
|
|
|
await browser.waitForElementByCss('#from-navigation')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Get the id on the rendered page.
|
|
|
|
const firstID = await browser.elementById('render-id').text()
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Go back, then forward.
|
|
|
|
await browser.back()
|
|
|
|
await browser.forward()
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Get the date again, and compare, they should be the same.
|
|
|
|
const secondID = await browser.elementById('render-id').text()
|
|
|
|
expect(firstID).toBe(secondID)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should allow linking from app page to pages page', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/pages-linking')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the link.
|
|
|
|
await browser.elementById('app-link').click()
|
|
|
|
await browser.waitForElementByCss('#pages-link')
|
|
|
|
|
|
|
|
// Click the other link.
|
|
|
|
await browser.elementById('pages-link').click()
|
|
|
|
await browser.waitForElementByCss('#app-link')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('server components', () => {
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: why is this not servable but /dashboard+rootonly/hello.server.js
|
2022-08-02 00:34:23 +02:00
|
|
|
// should be? Seems like they both either should be servable or not
|
|
|
|
it('should not serve .server.js as a path', async () => {
|
|
|
|
// Without .server.js should serve
|
|
|
|
const html = await renderViaHTTP(next.url, '/should-not-serve-server')
|
|
|
|
expect(html).toContain('hello from app/should-not-serve-server')
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not serve `.server`
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/should-not-serve-server.server'
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
)
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(res.status).toBe(404)
|
|
|
|
expect(await res.text()).toContain('This page could not be found')
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not serve `.server.js`
|
|
|
|
const res2 = await fetchViaHTTP(
|
2022-07-14 18:51:57 +02:00
|
|
|
next.url,
|
2022-08-02 00:34:23 +02:00
|
|
|
'/should-not-serve-server.server.js'
|
2022-07-14 18:51:57 +02:00
|
|
|
)
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(res2.status).toBe(404)
|
|
|
|
expect(await res2.text()).toContain('This page could not be found')
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should not serve .client.js as a path', async () => {
|
|
|
|
// Without .client.js should serve
|
|
|
|
const html = await renderViaHTTP(next.url, '/should-not-serve-client')
|
|
|
|
expect(html).toContain('hello from app/should-not-serve-client')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not serve `.client`
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/should-not-serve-client.client'
|
|
|
|
)
|
2022-07-14 18:51:57 +02:00
|
|
|
expect(res.status).toBe(404)
|
|
|
|
expect(await res.text()).toContain('This page could not be found')
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should not serve `.client.js`
|
|
|
|
const res2 = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/should-not-serve-client.client.js'
|
2022-05-16 11:46:45 +02:00
|
|
|
)
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(res2.status).toBe(404)
|
|
|
|
expect(await res2.text()).toContain('This page could not be found')
|
2022-05-16 11:46:45 +02:00
|
|
|
})
|
2022-05-02 12:18:16 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should serve shared component', async () => {
|
|
|
|
// Without .client.js should serve
|
|
|
|
const html = await renderViaHTTP(next.url, '/shared-component-route')
|
|
|
|
expect(html).toContain('hello from app/shared-component-route')
|
2022-05-16 11:46:45 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('dynamic routes', () => {
|
|
|
|
it('should only pass params that apply to the layout', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/dynamic/books/hello-world'
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
2022-05-24 16:54:26 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('#dynamic-layout-params').text()).toBe('{}')
|
|
|
|
expect($('#category-layout-params').text()).toBe(
|
|
|
|
'{"category":"books"}'
|
|
|
|
)
|
|
|
|
expect($('#id-layout-params').text()).toBe(
|
|
|
|
'{"category":"books","id":"hello-world"}'
|
|
|
|
)
|
|
|
|
expect($('#id-page-params').text()).toBe(
|
|
|
|
'{"category":"books","id":"hello-world"}'
|
|
|
|
)
|
|
|
|
})
|
2022-05-16 11:46:45 +02:00
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('catch-all routes', () => {
|
|
|
|
it('should handle optional segments', async () => {
|
|
|
|
const params = ['this', 'is', 'a', 'test']
|
|
|
|
const route = params.join('/')
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
`/optional-catch-all/${route}`
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('#text').attr('data-params')).toBe(route)
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should handle optional segments root', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, `/optional-catch-all`)
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('#text').attr('data-params')).toBe('')
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should handle required segments', async () => {
|
|
|
|
const params = ['this', 'is', 'a', 'test']
|
|
|
|
const route = params.join('/')
|
|
|
|
const html = await renderViaHTTP(next.url, `/catch-all/${route}`)
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('#text').attr('data-params')).toBe(route)
|
2022-08-26 20:21:53 +02:00
|
|
|
|
|
|
|
// Components under catch-all should not be treated as route that errors during build.
|
|
|
|
// They should be rendered properly when imported in page route.
|
|
|
|
expect($('#widget').text()).toBe('widget')
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should handle required segments root as not found', async () => {
|
|
|
|
const res = await fetchViaHTTP(next.url, `/catch-all`)
|
|
|
|
expect(res.status).toBe(404)
|
|
|
|
expect(await res.text()).toContain('This page could not be found')
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('should serve client component', () => {
|
|
|
|
it('should serve server-side', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/client-component-route')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('p').text()).toBe(
|
|
|
|
'hello from app/client-component-route. count: 0'
|
|
|
|
)
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: investigate hydration not kicking in on some runs
|
2022-09-20 15:28:07 +02:00
|
|
|
it('should serve client-side', async () => {
|
2022-08-02 00:34:23 +02:00
|
|
|
const browser = await webdriver(next.url, '/client-component-route')
|
|
|
|
|
|
|
|
// After hydration count should be 1
|
|
|
|
expect(await browser.elementByCss('p').text()).toBe(
|
|
|
|
'hello from app/client-component-route. count: 1'
|
|
|
|
)
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('should include client component layout with server component route', () => {
|
|
|
|
it('should include it server-side', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/client-nested')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
// Should not be nested in dashboard
|
|
|
|
expect($('h1').text()).toBe('Client Nested. Count: 0')
|
|
|
|
// Should include the page text
|
|
|
|
expect($('p').text()).toBe('hello from app/client-nested')
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-09-20 15:28:07 +02:00
|
|
|
it('should include it client-side', async () => {
|
2022-08-02 00:34:23 +02:00
|
|
|
const browser = await webdriver(next.url, '/client-nested')
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// After hydration count should be 1
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe(
|
|
|
|
'Client Nested. Count: 1'
|
|
|
|
)
|
|
|
|
|
|
|
|
// After hydration count should be 1
|
|
|
|
expect(await browser.elementByCss('p').text()).toBe(
|
|
|
|
'hello from app/client-nested'
|
|
|
|
)
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('Loading', () => {
|
|
|
|
it('should render loading.js in initial html for slow page', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/slow-page-with-loading')
|
|
|
|
const $ = cheerio.load(html)
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('#loading').text()).toBe('Loading...')
|
|
|
|
})
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should render loading.js in browser for slow page', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/slow-page-with-loading', {
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
waitHydration: false,
|
2022-08-02 00:34:23 +02:00
|
|
|
})
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: `await webdriver()` causes waiting for the full page to complete streaming. At that point "Loading..." is replaced by the actual content
|
2022-08-02 00:34:23 +02:00
|
|
|
// expect(await browser.elementByCss('#loading').text()).toBe('Loading...')
|
Implement new client-side router (#37551)
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-07-06 23:16:47 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.elementByCss('#slow-page-message').text()).toBe(
|
|
|
|
'hello from slow page'
|
|
|
|
)
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should render loading.js in initial html for slow layout', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/slow-layout-with-loading/slow'
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('#loading').text()).toBe('Loading...')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should render loading.js in browser for slow layout', async () => {
|
|
|
|
const browser = await webdriver(
|
|
|
|
next.url,
|
|
|
|
'/slow-layout-with-loading/slow',
|
|
|
|
{
|
|
|
|
waitHydration: false,
|
|
|
|
}
|
|
|
|
)
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: `await webdriver()` causes waiting for the full page to complete streaming. At that point "Loading..." is replaced by the actual content
|
2022-08-02 00:34:23 +02:00
|
|
|
// expect(await browser.elementByCss('#loading').text()).toBe('Loading...')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(
|
|
|
|
await browser.elementByCss('#slow-layout-message').text()
|
|
|
|
).toBe('hello from slow layout')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.elementByCss('#page-message').text()).toBe(
|
|
|
|
'Hello World'
|
|
|
|
)
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should render loading.js in initial html for slow layout and page', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
2022-07-14 18:51:57 +02:00
|
|
|
next.url,
|
2022-08-02 00:34:23 +02:00
|
|
|
'/slow-layout-and-page-with-loading/slow'
|
2022-07-14 18:51:57 +02:00
|
|
|
)
|
2022-08-02 00:34:23 +02:00
|
|
|
const $ = cheerio.load(html)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect($('#loading-layout').text()).toBe('Loading layout...')
|
|
|
|
expect($('#loading-page').text()).toBe('Loading page...')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should render loading.js in browser for slow layout and page', async () => {
|
|
|
|
const browser = await webdriver(
|
2022-07-14 18:51:57 +02:00
|
|
|
next.url,
|
2022-08-02 00:34:23 +02:00
|
|
|
'/slow-layout-and-page-with-loading/slow',
|
|
|
|
{
|
|
|
|
waitHydration: false,
|
|
|
|
}
|
2022-07-14 18:51:57 +02:00
|
|
|
)
|
2022-09-15 16:53:51 +02:00
|
|
|
// TODO-APP: `await webdriver()` causes waiting for the full page to complete streaming. At that point "Loading..." is replaced by the actual content
|
2022-08-02 00:34:23 +02:00
|
|
|
// expect(await browser.elementByCss('#loading-layout').text()).toBe('Loading...')
|
|
|
|
// expect(await browser.elementByCss('#loading-page').text()).toBe('Loading...')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(
|
|
|
|
await browser.elementByCss('#slow-layout-message').text()
|
|
|
|
).toBe('hello from slow layout')
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
expect(await browser.elementByCss('#slow-page-message').text()).toBe(
|
|
|
|
'hello from slow page'
|
|
|
|
)
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2022-09-15 16:53:51 +02:00
|
|
|
describe('middleware', () => {
|
|
|
|
it.each(['rewrite', 'redirect'])(
|
|
|
|
`should strip internal query parameters from requests to middleware for %s`,
|
|
|
|
async (method) => {
|
|
|
|
const browser = await webdriver(next.url, '/internal')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Wait for and click the navigation element, this should trigger
|
|
|
|
// the flight request that'll be caught by the middleware. If the
|
|
|
|
// middleware sees any flight data on the request it'll redirect to
|
|
|
|
// a page with an element of #failure, otherwise, we'll see the
|
|
|
|
// element for #success.
|
|
|
|
await browser
|
|
|
|
.waitForElementByCss(`#navigate-${method}`)
|
|
|
|
.elementById(`navigate-${method}`)
|
|
|
|
.click()
|
|
|
|
expect(
|
|
|
|
await browser.waitForElementByCss('#success', 3000).text()
|
|
|
|
).toBe('Success')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
)
|
|
|
|
})
|
|
|
|
|
2022-08-23 21:29:29 +02:00
|
|
|
describe('next/router', () => {
|
|
|
|
it('should always return null when accessed from /app', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/old-router')
|
|
|
|
|
|
|
|
try {
|
|
|
|
await browser.waitForElementByCss('#old-router')
|
|
|
|
|
|
|
|
const notNull = await browser.elementsByCss('.was-not-null')
|
|
|
|
expect(notNull.length).toBe(0)
|
|
|
|
|
|
|
|
const wasNull = await browser.elementsByCss('.was-null')
|
|
|
|
expect(wasNull.length).toBe(6)
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('hooks', () => {
|
|
|
|
describe('useCookies', () => {
|
|
|
|
it('should retrive cookies in a server component', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/hooks/use-cookies')
|
|
|
|
|
|
|
|
try {
|
|
|
|
await browser.waitForElementByCss('#does-not-have-cookie')
|
|
|
|
browser.addCookie({ name: 'use-cookies', value: 'value' })
|
|
|
|
browser.refresh()
|
|
|
|
|
|
|
|
await browser.waitForElementByCss('#has-cookie')
|
|
|
|
browser.deleteCookies()
|
|
|
|
browser.refresh()
|
|
|
|
|
|
|
|
await browser.waitForElementByCss('#does-not-have-cookie')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should access cookies on <Link /> navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/navigation')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Click the cookies link to verify it can't see the cookie that's
|
|
|
|
// not there.
|
|
|
|
await browser.elementById('use-cookies').click()
|
|
|
|
await browser.waitForElementByCss('#does-not-have-cookie')
|
|
|
|
|
|
|
|
// Go back and add the cookies.
|
|
|
|
await browser.back()
|
|
|
|
await browser.waitForElementByCss('#from-navigation')
|
|
|
|
browser.addCookie({ name: 'use-cookies', value: 'value' })
|
|
|
|
|
|
|
|
// Click the cookies link again to see that the cookie can be picked
|
|
|
|
// up again.
|
|
|
|
await browser.elementById('use-cookies').click()
|
|
|
|
await browser.waitForElementByCss('#has-cookie')
|
|
|
|
|
|
|
|
// Go back and remove the cookies.
|
|
|
|
await browser.back()
|
|
|
|
await browser.waitForElementByCss('#from-navigation')
|
|
|
|
browser.deleteCookies()
|
|
|
|
|
|
|
|
// Verify for the last time that after clicking the cookie link
|
|
|
|
// again, there are no cookies.
|
|
|
|
await browser.elementById('use-cookies').click()
|
|
|
|
await browser.waitForElementByCss('#does-not-have-cookie')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useHeaders', () => {
|
|
|
|
it('should have access to incoming headers in a server component', async () => {
|
|
|
|
// Check to see that we can't see the header when it's not present.
|
|
|
|
let html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-headers',
|
|
|
|
{},
|
|
|
|
{ headers: {} }
|
|
|
|
)
|
|
|
|
let $ = cheerio.load(html)
|
|
|
|
expect($('#does-not-have-header').length).toBe(1)
|
|
|
|
expect($('#has-header').length).toBe(0)
|
|
|
|
|
|
|
|
// Check to see that we can see the header when it's present.
|
|
|
|
html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-headers',
|
|
|
|
{},
|
|
|
|
{ headers: { 'x-use-headers': 'value' } }
|
|
|
|
)
|
|
|
|
$ = cheerio.load(html)
|
|
|
|
expect($('#has-header').length).toBe(1)
|
|
|
|
expect($('#does-not-have-header').length).toBe(0)
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should access headers on <Link /> navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/navigation')
|
|
|
|
|
|
|
|
try {
|
|
|
|
await browser.elementById('use-headers').click()
|
|
|
|
await browser.waitForElementByCss('#has-referer')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('usePreviewData', () => {
|
|
|
|
it('should return no preview data when there is none', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/hooks/use-preview-data')
|
|
|
|
|
|
|
|
try {
|
|
|
|
await browser.waitForElementByCss('#does-not-have-preview-data')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should return preview data when there is some', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/api/preview')
|
|
|
|
|
|
|
|
try {
|
|
|
|
await browser.loadPage(next.url + '/hooks/use-preview-data', {
|
|
|
|
disableCache: false,
|
|
|
|
beforePageLoad: null,
|
|
|
|
})
|
|
|
|
await browser.waitForElementByCss('#has-preview-data')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useRouter', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(next.url, '/hooks/use-router/server')
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useParams', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(next.url, '/hooks/use-params/server')
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useSearchParams', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-search-params/server'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('usePathname', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-pathname/server'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useLayoutSegments', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-layout-segments/server'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useSelectedLayoutSegment', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-selected-layout-segment/server'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
})
|
2022-08-02 00:34:23 +02:00
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('client components', () => {
|
|
|
|
describe('hooks', () => {
|
|
|
|
describe('useCookies', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-cookies/client'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('usePreviewData', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-preview-data/client'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useHeaders', () => {
|
|
|
|
// TODO-APP: should enable when implemented
|
|
|
|
it.skip('should throw an error when imported', async () => {
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-headers/client'
|
|
|
|
)
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain('Internal Server Error')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('usePathname', () => {
|
|
|
|
it('should have the correct pathname', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/hooks/use-pathname')
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
expect($('#pathname').attr('data-pathname')).toBe(
|
|
|
|
'/hooks/use-pathname'
|
|
|
|
)
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useSearchParams', () => {
|
|
|
|
it('should have the correct search params', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/hooks/use-search-params?first=value&second=other%20value&third'
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
const el = $('#params')
|
|
|
|
expect(el.attr('data-param-first')).toBe('value')
|
|
|
|
expect(el.attr('data-param-second')).toBe('other value')
|
|
|
|
expect(el.attr('data-param-third')).toBe('')
|
|
|
|
expect(el.attr('data-param-not-real')).toBe('N/A')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('useRouter', () => {
|
|
|
|
it('should allow access to the router', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/hooks/use-router')
|
|
|
|
|
|
|
|
try {
|
|
|
|
// Wait for the page to load, click the button (which uses a method
|
|
|
|
// on the router) and then wait for the correct page to load.
|
|
|
|
await browser.waitForElementByCss('#router')
|
|
|
|
await browser.elementById('button-push').click()
|
|
|
|
await browser.waitForElementByCss('#router-sub-page')
|
|
|
|
|
|
|
|
// Go back (confirming we did do a hard push), and wait for the
|
|
|
|
// correct previous page.
|
|
|
|
await browser.back()
|
|
|
|
await browser.waitForElementByCss('#router')
|
|
|
|
} finally {
|
|
|
|
await browser.close()
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should have consistent query and params handling', async () => {
|
|
|
|
const html = await renderViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/param-and-query/params?slug=query'
|
|
|
|
)
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
const el = $('#params-and-query')
|
|
|
|
expect(el.attr('data-params')).toBe('params')
|
|
|
|
expect(el.attr('data-query')).toBe('query')
|
|
|
|
})
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2022-08-31 15:13:47 +02:00
|
|
|
if (isDev) {
|
2022-09-19 14:30:32 +02:00
|
|
|
it('should throw an error when getServerSideProps is used', async () => {
|
2022-08-31 15:13:47 +02:00
|
|
|
const pageFile =
|
2022-09-18 02:00:16 +02:00
|
|
|
'app/client-with-errors/get-server-side-props/page.js'
|
2022-08-31 15:13:47 +02:00
|
|
|
const content = await next.readFile(pageFile)
|
|
|
|
const uncomment = content.replace(
|
|
|
|
'// export function getServerSideProps',
|
|
|
|
'export function getServerSideProps'
|
|
|
|
)
|
|
|
|
await next.patchFile(pageFile, uncomment)
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/client-with-errors/get-server-side-props'
|
|
|
|
)
|
|
|
|
await next.patchFile(pageFile, content)
|
2022-07-14 18:51:57 +02:00
|
|
|
|
2022-08-31 15:13:47 +02:00
|
|
|
await check(async () => {
|
|
|
|
const { status } = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/client-with-errors/get-server-side-props'
|
|
|
|
)
|
|
|
|
return status
|
|
|
|
}, /200/)
|
|
|
|
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain(
|
2022-09-19 14:30:32 +02:00
|
|
|
'`getServerSideProps` is not allowed in Client Components'
|
2022-08-31 15:13:47 +02:00
|
|
|
)
|
|
|
|
})
|
|
|
|
|
2022-09-19 14:30:32 +02:00
|
|
|
it('should throw an error when getStaticProps is used', async () => {
|
2022-09-18 02:00:16 +02:00
|
|
|
const pageFile = 'app/client-with-errors/get-static-props/page.js'
|
2022-08-31 15:13:47 +02:00
|
|
|
const content = await next.readFile(pageFile)
|
|
|
|
const uncomment = content.replace(
|
|
|
|
'// export function getStaticProps',
|
|
|
|
'export function getStaticProps'
|
|
|
|
)
|
|
|
|
await next.patchFile(pageFile, uncomment)
|
|
|
|
const res = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/client-with-errors/get-static-props'
|
|
|
|
)
|
|
|
|
await next.patchFile(pageFile, content)
|
|
|
|
await check(async () => {
|
|
|
|
const { status } = await fetchViaHTTP(
|
|
|
|
next.url,
|
|
|
|
'/client-with-errors/get-static-props'
|
|
|
|
)
|
|
|
|
return status
|
|
|
|
}, /200/)
|
|
|
|
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
expect(await res.text()).toContain(
|
2022-09-19 14:30:32 +02:00
|
|
|
'`getStaticProps` is not allowed in Client Components'
|
2022-08-31 15:13:47 +02:00
|
|
|
)
|
|
|
|
})
|
|
|
|
}
|
2022-07-14 18:51:57 +02:00
|
|
|
})
|
2022-07-05 00:35:29 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('css support', () => {
|
|
|
|
describe('server layouts', () => {
|
|
|
|
it('should support global css inside server layouts', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/dashboard')
|
|
|
|
|
|
|
|
// Should body text in red
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('.p')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(255, 0, 0)')
|
|
|
|
|
|
|
|
// Should inject global css for .green selectors
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('.green')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(0, 128, 0)')
|
|
|
|
})
|
2022-07-12 11:42:46 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should support css modules inside server layouts', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/css/css-nested')
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('#server-cssm')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(0, 128, 0)')
|
|
|
|
})
|
2022-07-12 11:42:46 +02:00
|
|
|
})
|
2022-07-11 17:23:21 +02:00
|
|
|
|
2022-08-28 02:49:59 +02:00
|
|
|
describe('server pages', () => {
|
|
|
|
it('should support global css inside server pages', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/css/css-page')
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('h1')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(255, 0, 0)')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should support css modules inside server pages', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/css/css-page')
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('#cssm')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(0, 0, 255)')
|
|
|
|
})
|
2022-07-12 11:42:46 +02:00
|
|
|
})
|
2022-07-11 17:23:21 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('client layouts', () => {
|
|
|
|
it('should support css modules inside client layouts', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/client-nested')
|
2022-07-05 00:35:29 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render h1 in red
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('h1')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(255, 0, 0)')
|
|
|
|
})
|
2022-07-06 01:07:13 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should support global css inside client layouts', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/client-nested')
|
2022-07-06 19:57:35 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render button in red
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('button')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(255, 0, 0)')
|
|
|
|
})
|
2022-07-12 11:42:46 +02:00
|
|
|
})
|
2022-07-06 19:57:35 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
describe('client pages', () => {
|
|
|
|
it('should support css modules inside client pages', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/client-component-route')
|
2022-07-06 01:07:13 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render p in red
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('p')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(255, 0, 0)')
|
|
|
|
})
|
2022-07-06 19:57:35 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
it('should support global css inside client pages', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/client-component-route')
|
2022-07-06 19:57:35 +02:00
|
|
|
|
2022-08-02 00:34:23 +02:00
|
|
|
// Should render `b` in blue
|
|
|
|
expect(
|
|
|
|
await browser.eval(
|
|
|
|
`window.getComputedStyle(document.querySelector('b')).color`
|
|
|
|
)
|
|
|
|
).toBe('rgb(0, 0, 255)')
|
|
|
|
})
|
2022-07-12 11:42:46 +02:00
|
|
|
})
|
2022-07-06 19:57:35 +02:00
|
|
|
})
|
2022-09-09 00:17:15 +02:00
|
|
|
;(isDev ? describe.skip : describe)('Subresource Integrity', () => {
|
|
|
|
function fetchWithPolicy(policy: string | null) {
|
|
|
|
return fetchViaHTTP(next.url, '/dashboard', undefined, {
|
|
|
|
headers: policy
|
|
|
|
? {
|
|
|
|
'Content-Security-Policy': policy,
|
|
|
|
}
|
|
|
|
: {},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
async function renderWithPolicy(policy: string | null) {
|
|
|
|
const res = await fetchWithPolicy(policy)
|
|
|
|
|
|
|
|
expect(res.ok).toBe(true)
|
|
|
|
|
|
|
|
const html = await res.text()
|
|
|
|
|
|
|
|
return cheerio.load(html)
|
|
|
|
}
|
|
|
|
|
|
|
|
it('does not include nonce when not enabled', async () => {
|
|
|
|
const policies = [
|
|
|
|
`script-src 'nonce-'`, // invalid nonce
|
|
|
|
'style-src "nonce-cmFuZG9tCg=="', // no script or default src
|
|
|
|
'', // empty string
|
|
|
|
]
|
|
|
|
|
|
|
|
for (const policy of policies) {
|
|
|
|
const $ = await renderWithPolicy(policy)
|
|
|
|
|
|
|
|
// Find all the script tags without src attributes and with nonce
|
|
|
|
// attributes.
|
|
|
|
const elements = $('script[nonce]:not([src])')
|
|
|
|
|
|
|
|
// Expect there to be none.
|
|
|
|
expect(elements.length).toBe(0)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('includes a nonce value with inline scripts when Content-Security-Policy header is defined', async () => {
|
|
|
|
// A random nonce value, base64 encoded.
|
|
|
|
const nonce = 'cmFuZG9tCg=='
|
|
|
|
|
|
|
|
// Validate all the cases where we could parse the nonce.
|
|
|
|
const policies = [
|
|
|
|
`script-src 'nonce-${nonce}'`, // base case
|
|
|
|
` script-src 'nonce-${nonce}' `, // extra space added around sources and directive
|
|
|
|
`style-src 'self'; script-src 'nonce-${nonce}'`, // extra directives
|
|
|
|
`script-src 'self' 'nonce-${nonce}' 'nonce-othernonce'`, // extra nonces
|
|
|
|
`default-src 'nonce-othernonce'; script-src 'nonce-${nonce}';`, // script and then fallback case
|
|
|
|
`default-src 'nonce-${nonce}'`, // fallback case
|
|
|
|
]
|
|
|
|
|
|
|
|
for (const policy of policies) {
|
|
|
|
const $ = await renderWithPolicy(policy)
|
|
|
|
|
|
|
|
// Find all the script tags without src attributes.
|
|
|
|
const elements = $('script:not([src])')
|
|
|
|
|
|
|
|
// Expect there to be at least 1 script tag without a src attribute.
|
|
|
|
expect(elements.length).toBeGreaterThan(0)
|
|
|
|
|
|
|
|
// Expect all inline scripts to have the nonce value.
|
|
|
|
elements.each((i, el) => {
|
|
|
|
expect(el.attribs['nonce']).toBe(nonce)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('includes an integrity attribute on scripts', async () => {
|
|
|
|
const html = await renderViaHTTP(next.url, '/dashboard')
|
|
|
|
|
|
|
|
const $ = cheerio.load(html)
|
|
|
|
|
|
|
|
// Find all the script tags with src attributes.
|
|
|
|
const elements = $('script[src]')
|
|
|
|
|
|
|
|
// Expect there to be at least 1 script tag with a src attribute.
|
|
|
|
expect(elements.length).toBeGreaterThan(0)
|
|
|
|
|
|
|
|
// Collect all the scripts with integrity hashes so we can verify them.
|
|
|
|
const files: [string, string][] = []
|
|
|
|
|
|
|
|
// For each of these attributes, ensure that there's an integrity
|
|
|
|
// attribute and starts with the correct integrity hash prefix.
|
|
|
|
elements.each((i, el) => {
|
|
|
|
const integrity = el.attribs['integrity']
|
|
|
|
expect(integrity).toBeDefined()
|
|
|
|
expect(integrity).toStartWith('sha256-')
|
|
|
|
|
|
|
|
const src = el.attribs['src']
|
|
|
|
expect(src).toBeDefined()
|
|
|
|
|
|
|
|
files.push([src, integrity])
|
|
|
|
})
|
|
|
|
|
|
|
|
// For each script tag, ensure that the integrity attribute is the
|
|
|
|
// correct hash of the script tag.
|
|
|
|
for (const [src, integrity] of files) {
|
|
|
|
const res = await fetchViaHTTP(next.url, src)
|
|
|
|
expect(res.status).toBe(200)
|
|
|
|
const content = await res.text()
|
|
|
|
|
|
|
|
const hash = crypto
|
|
|
|
.createHash('sha256')
|
|
|
|
.update(content)
|
|
|
|
.digest()
|
|
|
|
.toString('base64')
|
|
|
|
|
|
|
|
expect(integrity).toEndWith(hash)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('throws when escape characters are included in nonce', async () => {
|
|
|
|
const res = await fetchWithPolicy(
|
|
|
|
`script-src 'nonce-"><script></script>"'`
|
|
|
|
)
|
|
|
|
|
|
|
|
expect(res.status).toBe(500)
|
|
|
|
})
|
|
|
|
})
|
2022-09-09 14:44:12 +02:00
|
|
|
|
|
|
|
describe('template component', () => {
|
|
|
|
it('should render the template that holds state in a client component and reset on navigation', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/template/clientcomponent')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Template 0')
|
|
|
|
await browser.elementByCss('button').click()
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Template 1')
|
|
|
|
|
|
|
|
await browser.elementByCss('#link').click()
|
|
|
|
await browser.waitForElementByCss('#other-page')
|
|
|
|
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Template 0')
|
|
|
|
await browser.elementByCss('button').click()
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Template 1')
|
|
|
|
|
|
|
|
await browser.elementByCss('#link').click()
|
|
|
|
await browser.waitForElementByCss('#page')
|
|
|
|
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Template 0')
|
|
|
|
})
|
|
|
|
|
2022-09-09 20:50:18 +02:00
|
|
|
// TODO-APP: disable failing test and investigate later
|
|
|
|
it.skip('should render the template that is a server component and rerender on navigation', async () => {
|
2022-09-09 14:44:12 +02:00
|
|
|
const browser = await webdriver(next.url, '/template/servercomponent')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toStartWith('Template')
|
|
|
|
|
|
|
|
const currentTime = await browser
|
|
|
|
.elementByCss('#performance-now')
|
|
|
|
.text()
|
|
|
|
|
|
|
|
await browser.elementByCss('#link').click()
|
|
|
|
await browser.waitForElementByCss('#other-page')
|
|
|
|
|
|
|
|
expect(await browser.elementByCss('h1').text()).toStartWith('Template')
|
|
|
|
|
|
|
|
// template should rerender on navigation even when it's a server component
|
|
|
|
expect(await browser.elementByCss('#performance-now').text()).toBe(
|
|
|
|
currentTime
|
|
|
|
)
|
|
|
|
|
|
|
|
await browser.elementByCss('#link').click()
|
|
|
|
await browser.waitForElementByCss('#page')
|
|
|
|
|
|
|
|
expect(await browser.elementByCss('#performance-now').text()).toBe(
|
|
|
|
currentTime
|
|
|
|
)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
// TODO-APP: This is disabled for development as the error overlay needs to be reworked.
|
|
|
|
;(isDev ? describe.skip : describe)('error component', () => {
|
|
|
|
it('should trigger error component when an error happens during rendering', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/error/clientcomponent')
|
|
|
|
await browser
|
|
|
|
.elementByCss('#error-trigger-button')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('#error-boundary-message')
|
|
|
|
|
|
|
|
expect(
|
|
|
|
await browser.elementByCss('#error-boundary-message').text()
|
|
|
|
).toBe('An error occurred: this is a test')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should allow resetting error boundary', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/error/clientcomponent')
|
|
|
|
|
|
|
|
// Try triggering and resetting a few times in a row
|
|
|
|
for (let i = 0; i < 5; i++) {
|
|
|
|
await browser
|
|
|
|
.elementByCss('#error-trigger-button')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('#error-boundary-message')
|
|
|
|
|
|
|
|
expect(
|
|
|
|
await browser.elementByCss('#error-boundary-message').text()
|
|
|
|
).toBe('An error occurred: this is a test')
|
|
|
|
|
|
|
|
await browser
|
|
|
|
.elementByCss('#reset')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('#error-trigger-button')
|
|
|
|
|
|
|
|
expect(
|
|
|
|
await browser.elementByCss('#error-trigger-button').text()
|
|
|
|
).toBe('Trigger Error!')
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should hydrate empty shell to handle server-side rendering errors', async () => {
|
|
|
|
const browser = await webdriver(
|
|
|
|
next.url,
|
|
|
|
'/error/ssr-error-client-component'
|
|
|
|
)
|
|
|
|
const logs = await browser.log()
|
|
|
|
const errors = logs
|
|
|
|
.filter((x) => x.source === 'error')
|
|
|
|
.map((x) => x.message)
|
|
|
|
.join('\n')
|
|
|
|
expect(errors).toInclude('Error during SSR')
|
|
|
|
})
|
|
|
|
})
|
2022-09-12 14:45:37 +02:00
|
|
|
|
|
|
|
describe('known bugs', () => {
|
|
|
|
it('should not share flight data between requests', async () => {
|
|
|
|
const fetches = await Promise.all(
|
|
|
|
[...new Array(5)].map(() =>
|
|
|
|
renderViaHTTP(next.url, '/loading-bug/electronics')
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
|
|
|
for (const text of fetches) {
|
|
|
|
const $ = cheerio.load(text)
|
|
|
|
expect($('#category-id').text()).toBe('electronicsabc')
|
|
|
|
}
|
|
|
|
})
|
|
|
|
})
|
2022-09-20 15:28:07 +02:00
|
|
|
|
|
|
|
describe('redirect', () => {
|
|
|
|
describe('components', () => {
|
|
|
|
it.skip('should redirect in a server component', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/redirect/servercomponent')
|
|
|
|
await browser.waitForElementByCss('#result-page')
|
|
|
|
expect(await browser.elementByCss('#result-page').text()).toBe(
|
|
|
|
'Result Page'
|
|
|
|
)
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should redirect in a client component', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/redirect/clientcomponent')
|
|
|
|
await browser.waitForElementByCss('#result-page')
|
|
|
|
expect(await browser.elementByCss('#result-page').text()).toBe(
|
|
|
|
'Result Page'
|
|
|
|
)
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should redirect client-side', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/redirect/client-side')
|
|
|
|
await browser
|
|
|
|
.elementByCss('button')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('#result-page')
|
|
|
|
expect(await browser.elementByCss('#result-page').text()).toBe(
|
|
|
|
'Result Page'
|
|
|
|
)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('next.config.js redirects', () => {
|
|
|
|
it('should redirect from next.config.js', async () => {
|
|
|
|
const browser = await webdriver(next.url, '/redirect/a')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Dashboard')
|
|
|
|
expect(await browser.url()).toBe(next.url + '/dashboard')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should redirect from next.config.js with link navigation', async () => {
|
|
|
|
const browser = await webdriver(
|
|
|
|
next.url,
|
|
|
|
'/redirect/next-config-redirect'
|
|
|
|
)
|
|
|
|
await browser
|
|
|
|
.elementByCss('#redirect-a')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('h1')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Dashboard')
|
|
|
|
expect(await browser.url()).toBe(next.url + '/dashboard')
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('middleware redirects', () => {
|
|
|
|
it('should redirect from middleware', async () => {
|
|
|
|
const browser = await webdriver(
|
|
|
|
next.url,
|
|
|
|
'/redirect-middleware-to-dashboard'
|
|
|
|
)
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Dashboard')
|
|
|
|
expect(await browser.url()).toBe(next.url + '/dashboard')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should redirect from middleware with link navigation', async () => {
|
|
|
|
const browser = await webdriver(
|
|
|
|
next.url,
|
|
|
|
'/redirect/next-middleware-redirect'
|
|
|
|
)
|
|
|
|
await browser
|
|
|
|
.elementByCss('#redirect-middleware')
|
|
|
|
.click()
|
|
|
|
.waitForElementByCss('h1')
|
|
|
|
expect(await browser.elementByCss('h1').text()).toBe('Dashboard')
|
|
|
|
expect(await browser.url()).toBe(next.url + '/dashboard')
|
|
|
|
})
|
|
|
|
})
|
|
|
|
})
|
2022-08-02 00:34:23 +02:00
|
|
|
}
|
|
|
|
|
2022-09-20 03:17:16 +02:00
|
|
|
runTests()
|
2022-05-02 12:18:16 +02:00
|
|
|
})
|