2022-12-19 10:20:01 +01:00
import { createNextDescribe } from 'e2e-utils'
2022-09-09 00:17:15 +02:00
import crypto from 'crypto'
2022-12-19 10:20:01 +01:00
import { check , getRedboxHeader , hasRedbox , waitFor } from 'next-test-utils'
2022-05-02 12:18:16 +02:00
import cheerio from 'cheerio'
2023-01-22 07:47:24 +01:00
import stripAnsi from 'strip-ansi'
2022-06-29 21:28:48 +02:00
2022-12-19 10:20:01 +01:00
createNextDescribe (
'app dir' ,
{
2022-12-21 14:16:52 +01:00
files : __dirname ,
2022-12-19 10:20:01 +01:00
} ,
( { next , isNextDev : isDev , isNextStart , isNextDeploy } ) = > {
2023-04-29 00:40:34 +02:00
if ( isNextStart ) {
it ( 'should have correct preferredRegion values in manifest' , async ( ) = > {
const middlewareManifest = JSON . parse (
await next . readFile ( '.next/server/middleware-manifest.json' )
)
expect (
middlewareManifest . functions [ '/(rootonly)/dashboard/hello/page' ]
. regions
) . toEqual ( [ 'iad1' , 'sfo1' ] )
expect ( middlewareManifest . functions [ '/dashboard/page' ] . regions ) . toEqual (
[ 'iad1' ]
)
expect (
middlewareManifest . functions [ '/slow-page-no-loading/page' ] . regions
2023-04-30 15:21:38 +02:00
) . toEqual ( [ 'global' ] )
2023-04-29 00:40:34 +02:00
expect ( middlewareManifest . functions [ '/test-page/page' ] . regions ) . toEqual (
[ 'home' ]
)
2023-05-01 11:58:36 +02:00
// Inherits from the root layout.
expect (
middlewareManifest . functions [ '/slow-page-with-loading/page' ] . regions
) . toEqual ( [ 'sfo1' ] )
2023-04-29 00:40:34 +02:00
} )
}
2023-04-05 23:14:40 +02:00
it ( 'should have correct searchParams and params (server)' , async ( ) = > {
const html = await next . render ( '/dynamic/category-1/id-2?query1=value2' )
const $ = cheerio . load ( html )
expect ( JSON . parse ( $ ( '#id-page-params' ) . text ( ) ) ) . toEqual ( {
category : 'category-1' ,
id : 'id-2' ,
} )
expect ( JSON . parse ( $ ( '#search-params' ) . text ( ) ) ) . toEqual ( {
query1 : 'value2' ,
} )
} )
it ( 'should have correct searchParams and params (client)' , async ( ) = > {
const browser = await next . browser (
'/dynamic-client/category-1/id-2?query1=value2'
)
const html = await browser . eval ( 'document.documentElement.innerHTML' )
const $ = cheerio . load ( html )
expect ( JSON . parse ( $ ( '#id-page-params' ) . text ( ) ) ) . toEqual ( {
category : 'category-1' ,
id : 'id-2' ,
} )
expect ( JSON . parse ( $ ( '#search-params' ) . text ( ) ) ) . toEqual ( {
query1 : 'value2' ,
} )
} )
2023-03-31 21:19:47 +02:00
if ( ! isDev ) {
it ( 'should successfully detect app route during prefetch' , async ( ) = > {
const browser = await next . browser ( '/' )
await check ( async ( ) = > {
const found = await browser . eval (
'!!window.next.router.components["/dashboard"]'
)
return found
? 'success'
: await browser . eval ( 'Object.keys(window.next.router.components)' )
} , 'success' )
await browser . elementByCss ( 'a' ) . click ( )
await browser . waitForElementByCss ( '#from-dashboard' )
} )
}
2023-03-03 23:17:07 +01:00
it ( 'should encode chunk path correctly' , async ( ) = > {
2023-03-17 18:38:19 +01:00
await next . fetch ( '/dynamic-client/first/second' )
2023-03-03 23:17:07 +01:00
const browser = await next . browser ( '/' )
const requests = [ ]
browser . on ( 'request' , ( req ) = > {
requests . push ( req . url ( ) )
} )
await browser . eval (
'window.location.href = "/dynamic-client/first/second"'
)
await check ( async ( ) = > {
return requests . some (
( req ) = >
req . includes ( encodeURI ( '/[category]/[id]' ) ) && req . endsWith ( '.js' )
)
? 'found'
: JSON . stringify ( requests )
} , 'found' )
} )
2023-02-23 07:02:31 +01:00
it . each ( [
{ pathname : '/redirect-1' } ,
{ pathname : '/redirect-2' } ,
{ pathname : '/blog/old-post' } ,
{ pathname : '/redirect-3/some' } ,
{ pathname : '/redirect-4' } ,
] ) (
'should match redirects in pages correctly $path' ,
async ( { pathname } ) = > {
2023-02-24 02:18:59 +01:00
let browser = await next . browser ( '/' )
2023-02-23 07:02:31 +01:00
await browser . eval ( ` next.router.push(" ${ pathname } ") ` )
await check ( async ( ) = > {
const href = await browser . eval ( 'location.href' )
return href . includes ( 'example.vercel.sh' ) ? 'yes' : href
} , 'yes' )
2023-02-24 02:18:59 +01:00
if ( pathname . includes ( '/blog' ) ) {
browser = await next . browser ( '/blog/first' )
await browser . eval ( 'window.beforeNav = 1' )
// check 5 times to ensure a reload didn't occur
for ( let i = 0 ; i < 5 ; i ++ ) {
await waitFor ( 500 )
expect (
await browser . eval ( 'document.documentElement.innerHTML' )
) . toContain ( 'hello from pages/blog/[slug]' )
expect ( await browser . eval ( 'window.beforeNav' ) ) . toBe ( 1 )
}
}
2023-02-23 07:02:31 +01:00
}
)
2023-03-04 01:02:02 +01:00
it ( 'should not apply client router filter on shallow' , async ( ) = > {
const browser = await next . browser ( '/' )
await browser . eval ( 'window.beforeNav = 1' )
await check ( async ( ) = > {
await browser . eval (
` window.next.router.push('/', '/redirect-1', { shallow: true }) `
)
return await browser . eval ( 'window.location.pathname' )
} , '/redirect-1' )
expect ( await browser . eval ( 'window.beforeNav' ) ) . toBe ( 1 )
} )
2023-01-22 07:47:24 +01:00
if ( isDev ) {
it ( 'should not have duplicate config warnings' , async ( ) = > {
await next . fetch ( '/' )
expect (
stripAnsi ( next . cliOutput ) . match (
/You have enabled experimental feature/g
) . length
) . toBe ( 1 )
expect (
stripAnsi ( next . cliOutput ) . match (
/Experimental features are not covered by semver/g
) . length
) . toBe ( 1 )
} )
}
2022-12-19 10:20:01 +01:00
if ( ! isNextDeploy ) {
2022-10-28 00:57:48 +02:00
it ( 'should not share edge workers' , async ( ) = > {
const controller1 = new AbortController ( )
const controller2 = new AbortController ( )
2022-12-19 10:20:01 +01:00
next
2023-01-05 16:31:03 +01:00
. fetch ( '/slow-page-no-loading' , {
2022-12-19 10:20:01 +01:00
signal : controller1.signal ,
} )
. catch ( ( ) = > { } )
next
2023-01-05 16:31:03 +01:00
. fetch ( '/slow-page-no-loading' , {
2022-12-19 10:20:01 +01:00
signal : controller2.signal ,
} )
. catch ( ( ) = > { } )
2022-10-14 07:56:42 +02:00
2022-10-28 00:57:48 +02:00
await waitFor ( 1000 )
controller1 . abort ( )
2022-10-14 07:56:42 +02:00
2022-10-28 00:57:48 +02:00
const controller3 = new AbortController ( )
2022-12-19 10:20:01 +01:00
next
2023-01-05 16:31:03 +01:00
. fetch ( '/slow-page-no-loading' , {
2022-12-19 10:20:01 +01:00
signal : controller3.signal ,
} )
. catch ( ( ) = > { } )
2022-10-28 00:57:48 +02:00
await waitFor ( 1000 )
controller2 . abort ( )
controller3 . abort ( )
2022-10-14 07:56:42 +02:00
2022-12-19 10:20:01 +01:00
const res = await next . fetch ( '/slow-page-no-loading' )
2022-10-28 00:57:48 +02:00
expect ( res . status ) . toBe ( 200 )
expect ( await res . text ( ) ) . toContain ( 'hello from slow page' )
expect ( next . cliOutput ) . not . toContain (
'A separate worker must be used for each render'
)
} )
}
2022-10-14 07:56:42 +02:00
2022-12-19 10:20:01 +01:00
if ( isNextStart ) {
2022-10-04 00:53:28 +02:00
it ( 'should generate build traces correctly' , async ( ) = > {
const trace = JSON . parse (
await next . readFile (
'.next/server/app/dashboard/deployments/[id]/page.js.nft.json'
)
) as { files : string [ ] }
expect ( trace . files . some ( ( file ) = > file . endsWith ( 'data.json' ) ) ) . toBe (
true
)
} )
}
2023-02-11 18:44:53 +01:00
it ( 'should use text/x-component for flight' , async ( ) = > {
2023-01-05 16:31:03 +01:00
const res = await next . fetch ( '/dashboard/deployments/123' , {
headers : {
[ 'RSC' . toString ( ) ] : '1' ,
} ,
} )
2023-02-11 18:44:53 +01:00
expect ( res . headers . get ( 'Content-Type' ) ) . toBe ( 'text/x-component' )
2022-09-18 22:49:05 +02:00
} )
2023-02-11 18:44:53 +01:00
it ( 'should use text/x-component for flight with edge runtime' , async ( ) = > {
2023-01-05 16:31:03 +01:00
const res = await next . fetch ( '/dashboard' , {
headers : {
[ 'RSC' . toString ( ) ] : '1' ,
} ,
} )
2023-02-11 18:44:53 +01:00
expect ( res . headers . get ( 'Content-Type' ) ) . toBe ( 'text/x-component' )
2022-09-18 22:49:05 +02:00
} )
2023-02-18 07:54:48 +01:00
it ( 'should return the `vary` header from edge runtime' , async ( ) = > {
const res = await next . fetch ( '/dashboard' )
expect ( res . headers . get ( 'x-edge-runtime' ) ) . toBe ( '1' )
expect ( res . headers . get ( 'vary' ) ) . toBe (
2023-04-11 22:26:49 +02:00
isNextDeploy
2023-04-02 15:17:15 +02:00
? 'RSC, Next-Router-State-Tree, Next-Router-Prefetch'
: 'RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding'
2023-02-18 07:54:48 +01:00
)
} )
it ( 'should return the `vary` header from pages for flight requests' , async ( ) = > {
const res = await next . fetch ( '/' , {
headers : {
[ 'RSC' . toString ( ) ] : '1' ,
} ,
} )
expect ( res . headers . get ( 'vary' ) ) . toBe (
2023-02-22 03:51:57 +01:00
isNextDeploy
? 'RSC, Next-Router-State-Tree, Next-Router-Prefetch'
: 'RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding'
2023-02-18 07:54:48 +01:00
)
} )
2022-08-02 00:34:23 +02:00
it ( 'should pass props from getServerSideProps in root layout' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard' )
2023-01-24 14:21:59 +01:00
expect ( $ ( 'title' ) . first ( ) . text ( ) ) . toBe ( 'hello world' )
2022-08-02 00:34:23 +02:00
} )
2022-05-02 12:18:16 +02:00
2022-08-02 00:34:23 +02:00
it ( 'should serve from pages' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/blog/first' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/hello.txt' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/dashboard' )
2022-08-02 00:34:23 +02:00
expect ( html ) . toContain ( 'hello from app/dashboard' )
} )
2022-05-02 12:18:16 +02:00
2023-05-19 20:25:04 +02:00
it ( 'should ensure the </body></html> suffix is at the end of the stream' , async ( ) = > {
const html = await next . render ( '/dashboard' )
// It must end with the suffix and not contain it anywhere else.
const suffix = '</body></html>'
expect ( html ) . toEndWith ( suffix )
expect ( html . slice ( 0 , - suffix . length ) ) . not . toContain ( suffix )
} )
2022-12-19 10:20:01 +01:00
if ( ! isNextDeploy ) {
2022-10-25 03:33:05 +02:00
it ( 'should serve /index as separate page' , async ( ) = > {
2022-12-16 17:47:30 +01:00
const stderr = [ ]
next . on ( 'stderr' , ( err ) = > {
stderr . push ( err )
} )
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/dashboard/index' )
2022-10-25 03:33:05 +02:00
expect ( html ) . toContain ( 'hello from app/dashboard/index' )
2022-12-16 17:47:30 +01:00
expect ( stderr . some ( ( err ) = > err . includes ( 'Invalid hook call' ) ) ) . toBe (
false
)
2022-12-07 19:42:10 +01:00
} )
2022-10-25 03:33:05 +02:00
it ( 'should serve polyfills for browsers that do not support modules' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/dashboard/index' )
2022-10-25 03:33:05 +02:00
expect ( html ) . toMatch (
2023-04-20 02:05:49 +02:00
/<script src="\/_next\/static\/chunks\/polyfills(-\w+)?\.js" noModule="">/
2022-10-25 03:33:05 +02:00
)
} )
}
2022-09-30 01:22:21 +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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/integrations' )
2022-08-02 00:34:23 +02:00
// 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/hello' )
const html = $ . 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/another' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/deployments/breakdown' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/integrations' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/changelog' )
2022-08-02 00:34:23 +02:00
// 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/deployments/123' )
2022-08-02 00:34:23 +02:00
// 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard/deployments/123' )
2022-08-02 00:34:23 +02:00
// 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-11-03 01:19:59 +01:00
// TODO-APP: fix to ensure behavior matches on deploy
2022-12-19 10:20:01 +01:00
if ( ! isNextDeploy ) {
2022-11-03 01:19:59 +01:00
it ( 'should serve page as a segment name correctly' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/dashboard/page' )
2022-11-03 01:19:59 +01:00
expect ( html ) . toContain ( 'hello dashboard/page!' )
} )
}
2022-11-02 16:16:59 +01:00
2022-08-02 00:34:23 +02:00
it ( 'should include document html and body' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dashboard' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const res = await next . fetch ( '/dashboard/deployments' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/partial-match-123' )
2022-08-02 00:34:23 +02:00
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' , ( ) = > {
2022-09-29 14:29:10 +02:00
// TODO-APP: rewrite url is broken
2022-10-07 15:01:02 +02:00
it ( 'should support rewrites on initial load' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/rewritten-to-dashboard' )
2022-09-15 16:53:51 +02:00
expect ( await browser . elementByCss ( 'h1' ) . text ( ) ) . toBe ( 'Dashboard' )
expect ( await browser . url ( ) ) . toBe ( ` ${ next . url } /rewritten-to-dashboard ` )
} )
2022-09-29 14:29:10 +02:00
it ( 'should support rewrites on client-side navigation from pages to app with existing pages path' , async ( ) = > {
2023-03-17 18:38:19 +01:00
await next . fetch ( '/exists-but-not-routed' )
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/link-to-rewritten-path' )
2022-09-29 14:29:10 +02:00
try {
// Click the link.
2023-03-17 18:38:19 +01:00
await check ( async ( ) = > {
await browser . elementById ( 'link-to-rewritten-path' ) . click ( )
await browser . waitForElementByCss ( '#from-dashboard' , 5000 )
// Check to see that we were rewritten and not redirected.
// TODO-APP: rewrite url is broken
// 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'
)
return 'success'
} , 'success' )
2022-09-29 14:29:10 +02:00
} finally {
await browser . close ( )
}
} )
2022-09-15 16:53:51 +02:00
it ( 'should support rewrites on client-side navigation' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/rewrites' )
2022-09-15 16:53:51 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/same-layout/first' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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-08-02 00:34:23 +02:00
describe ( '<Link />' , ( ) = > {
2022-09-06 19:29:09 +02:00
it ( 'should hard push' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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 )
// 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
} 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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 )
// 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 )
} finally {
await browser . close ( )
}
} )
2022-07-14 18:51:57 +02:00
2022-10-02 20:34:59 +02:00
// TODO-APP: Re-enable this test.
2022-10-05 15:45:46 +02:00
it ( 'should soft push' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/link-soft-push' )
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 ( )
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-12-19 10:20:01 +01:00
const browser = await next . browser ( '/link-soft-replace' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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-09-30 01:47:10 +02:00
it ( 'should allow linking from app page to pages page' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/pages-linking' )
2022-08-02 00:34:23 +02:00
try {
// Click the link.
await browser . elementById ( 'app-link' ) . click ( )
2022-09-30 01:47:10 +02:00
expect ( await browser . waitForElementByCss ( '#pages-link' ) . text ( ) ) . toBe (
'To App Page'
)
2022-08-02 00:34:23 +02:00
// Click the other link.
await browser . elementById ( 'pages-link' ) . click ( )
2022-09-30 01:47:10 +02:00
expect ( await browser . waitForElementByCss ( '#app-link' ) . text ( ) ) . toBe (
'To Pages Page'
)
2022-08-02 00:34:23 +02:00
} finally {
await browser . close ( )
}
} )
2022-11-22 00:52:12 +01:00
it ( 'should navigate to pages dynamic route from pages page if it overlaps with an app page' , async ( ) = > {
2023-03-17 18:38:19 +01:00
await next . fetch ( '/dynamic-pages-route-app-overlap/app-dir' )
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/dynamic-pages-route-app-overlap' )
2022-11-22 00:52:12 +01:00
try {
// Click the link.
2023-03-17 18:38:19 +01:00
await check ( async ( ) = > {
await browser . elementById ( 'pages-link' ) . click ( )
2022-11-22 00:52:12 +01:00
2023-03-17 18:38:19 +01:00
expect (
await browser . waitForElementByCss ( '#app-text' , 5000 ) . text ( )
) . toBe (
'hello from app/dynamic-pages-route-app-overlap/app-dir/page'
)
// When refreshing the browser, the app page should be rendered
await browser . refresh ( )
expect ( await browser . waitForElementByCss ( '#app-text' ) . text ( ) ) . toBe (
'hello from app/dynamic-pages-route-app-overlap/app-dir/page'
)
return 'success'
} , 'success' )
2022-11-22 00:52:12 +01:00
} finally {
await browser . close ( )
}
} )
2023-01-31 19:39:36 +01:00
it ( 'should push to external url' , async ( ) = > {
const browser = await next . browser ( '/link-external/push' )
expect ( await browser . eval ( 'window.history.length' ) ) . toBe ( 2 )
await browser . elementByCss ( '#external-link' ) . click ( )
expect ( await browser . waitForElementByCss ( 'h1' ) . text ( ) ) . toBe (
'Example Domain'
)
expect ( await browser . eval ( 'window.history.length' ) ) . toBe ( 3 )
} )
it ( 'should replace to external url' , async ( ) = > {
const browser = await next . browser ( '/link-external/replace' )
expect ( await browser . eval ( 'window.history.length' ) ) . toBe ( 2 )
await browser . elementByCss ( '#external-link' ) . click ( )
expect ( await browser . waitForElementByCss ( 'h1' ) . text ( ) ) . toBe (
'Example Domain'
)
expect ( await browser . eval ( 'window.history.length' ) ) . toBe ( 2 )
} )
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
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/should-not-serve-server' )
2022-08-02 00:34:23 +02:00
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`
2022-12-19 10:20:01 +01:00
const res = await next . fetch ( '/should-not-serve-server.server' )
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`
2022-12-19 10:20:01 +01:00
const res2 = await next . fetch ( '/should-not-serve-server.server.js' )
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
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/should-not-serve-client' )
2022-08-02 00:34:23 +02:00
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`
2022-12-19 10:20:01 +01:00
const res = await next . fetch ( '/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`
2022-12-19 10:20:01 +01:00
const res2 = await next . fetch ( '/should-not-serve-client.client.js' )
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
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/shared-component-route' )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/dynamic/books/hello-world' )
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 ( '/' )
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( ` /catch-all-optional/ ${ route } ` )
2022-08-02 00:34:23 +02:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( ` /catch-all-optional ` )
2022-08-02 00:34:23 +02:00
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-10-09 08:18:56 +02:00
it ( 'should handle optional catch-all segments link' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/catch-all-link' )
2022-10-09 08:18:56 +02:00
expect (
await browser
. elementByCss ( '#to-catch-all-optional' )
. click ( )
. waitForElementByCss ( '#text' )
. text ( )
) . toBe ( ` hello from /catch-all-optional/this/is/a/test ` )
} )
2022-08-02 00:34:23 +02:00
it ( 'should handle required segments' , async ( ) = > {
const params = [ 'this' , 'is' , 'a' , 'test' ]
const route = params . join ( '/' )
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( ` /catch-all/ ${ route } ` )
2022-08-02 00:34:23 +02:00
expect ( $ ( '#text' ) . attr ( 'data-params' ) ) . toBe ( route )
2022-11-16 22:46:04 +01:00
expect ( $ ( '#not-a-page' ) . text ( ) ) . toBe ( 'Not a page' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const res = await next . fetch ( ` /catch-all ` )
2022-08-02 00:34:23 +02:00
expect ( res . status ) . toBe ( 404 )
expect ( await res . text ( ) ) . toContain ( 'This page could not be found' )
} )
2022-10-09 08:18:56 +02:00
it ( 'should handle catch-all segments link' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/catch-all-link' )
2022-10-09 08:18:56 +02:00
expect (
await browser
. elementByCss ( '#to-catch-all' )
. click ( )
. waitForElementByCss ( '#text' )
. text ( )
) . toBe ( ` hello from /catch-all/this/is/a/test ` )
} )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/client-component-route' )
2022-08-02 00:34:23 +02:00
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-12-19 10:20:01 +01:00
const browser = await next . browser ( '/client-component-route' )
2022-08-02 00:34:23 +02:00
// 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/client-nested' )
2022-08-02 00:34:23 +02:00
// 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-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/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
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/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-12-19 10:20:01 +01:00
// TODO-APP: `await next.browser()` 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/slow-layout-with-loading/slow' )
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/slow-layout-with-loading/slow' , {
waitHydration : false ,
} )
// TODO-APP: `await next.browser()` 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ (
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
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser (
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-12-19 10:20:01 +01:00
// TODO-APP: `await next.browser()` 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 ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/internal' )
2022-09-15 16:53:51 +02:00
2023-02-15 01:18:21 +01:00
// 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 ( )
await check (
async ( ) = > await browser . elementByCss ( '#success' ) . text ( ) ,
/Success/
)
2022-09-15 16:53:51 +02:00
}
)
} )
2022-08-23 21:29:29 +02:00
describe ( 'next/router' , ( ) = > {
2022-10-20 13:54:17 +02:00
it ( 'should support router.back and router.forward' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/back-forward/1' )
2022-10-20 13:54:17 +02:00
const firstMessage = 'Hello from 1'
const secondMessage = 'Hello from 2'
expect ( await browser . elementByCss ( '#message-1' ) . text ( ) ) . toBe (
firstMessage
)
try {
const message2 = await browser
. waitForElementByCss ( '#to-other-page' )
. click ( )
. waitForElementByCss ( '#message-2' )
. text ( )
expect ( message2 ) . toBe ( secondMessage )
const message1 = await browser
. waitForElementByCss ( '#back-button' )
. click ( )
. waitForElementByCss ( '#message-1' )
. text ( )
expect ( message1 ) . toBe ( firstMessage )
const message2Again = await browser
. waitForElementByCss ( '#forward-button' )
. click ( )
. waitForElementByCss ( '#message-2' )
. text ( )
expect ( message2Again ) . toBe ( secondMessage )
} finally {
await browser . close ( )
2022-08-23 21:29:29 +02:00
}
} )
} )
2023-02-10 01:38:39 +01:00
describe ( 'client components' , ( ) = > {
if ( ! isNextDeploy ) {
it ( 'should have consistent query and params handling' , async ( ) = > {
const $ = await next . render $ ( '/param-and-query/params?slug=query' )
const el = $ ( '#params-and-query' )
expect ( el . attr ( 'data-params' ) ) . toBe ( 'params' )
expect ( el . attr ( 'data-query' ) ) . toBe ( 'query' )
2022-11-02 23:06:31 +01:00
} )
2023-02-10 01:38:39 +01:00
}
2022-07-14 18:51:57 +02:00
} )
} )
2022-07-05 00:35:29 +02:00
2022-12-08 02:19:58 +01:00
if ( isDev ) {
describe ( 'HMR' , ( ) = > {
it ( 'should HMR correctly for server component' , async ( ) = > {
const filePath = 'app/dashboard/index/page.js'
const origContent = await next . readFile ( filePath )
try {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/dashboard/index' )
2022-12-08 02:19:58 +01:00
expect ( await browser . elementByCss ( 'p' ) . text ( ) ) . toContain (
'hello from app/dashboard/index'
)
await next . patchFile (
filePath ,
origContent . replace ( 'hello from' , 'swapped from' )
)
await check ( ( ) = > browser . elementByCss ( 'p' ) . text ( ) , /swapped from/ )
} finally {
await next . patchFile ( filePath , origContent )
}
} )
it ( 'should HMR correctly for client component' , async ( ) = > {
const filePath = 'app/client-component-route/page.js'
const origContent = await next . readFile ( filePath )
try {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/client-component-route' )
2022-12-08 02:19:58 +01:00
2022-12-19 10:20:01 +01:00
const ssrInitial = await next . render ( '/client-component-route' )
2022-12-08 02:19:58 +01:00
expect ( ssrInitial ) . toContain (
'hello from app/client-component-route'
)
expect ( await browser . elementByCss ( 'p' ) . text ( ) ) . toContain (
'hello from app/client-component-route'
)
await next . patchFile (
filePath ,
origContent . replace ( 'hello from' , 'swapped from' )
)
2022-11-21 14:35:57 +01:00
2022-12-08 02:19:58 +01:00
await check ( ( ) = > browser . elementByCss ( 'p' ) . text ( ) , /swapped from/ )
2022-11-21 14:35:57 +01:00
2022-12-19 10:20:01 +01:00
const ssrUpdated = await next . render ( '/client-component-route' )
2022-12-08 02:19:58 +01:00
expect ( ssrUpdated ) . toContain ( 'swapped from' )
await next . patchFile ( filePath , origContent )
await check ( ( ) = > browser . elementByCss ( 'p' ) . text ( ) , /hello from/ )
2022-12-19 10:20:01 +01:00
expect ( await next . render ( '/client-component-route' ) ) . toContain (
'hello from'
)
2022-12-08 02:19:58 +01:00
} finally {
await next . patchFile ( filePath , origContent )
}
} )
it ( 'should HMR correctly when changing the component type' , async ( ) = > {
const filePath = 'app/dashboard/page/page.jsx'
const origContent = await next . readFile ( filePath )
try {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/dashboard/page' )
2022-12-08 02:19:58 +01:00
expect ( await browser . elementByCss ( 'p' ) . text ( ) ) . toContain (
'hello dashboard/page!'
)
// Test HMR with server component
await next . patchFile (
filePath ,
origContent . replace (
'hello dashboard/page!' ,
'hello dashboard/page in server component!'
2022-11-21 14:35:57 +01:00
)
2022-12-08 02:19:58 +01:00
)
await check (
( ) = > browser . elementByCss ( 'p' ) . text ( ) ,
/in server component/
)
2022-11-21 14:35:57 +01:00
2022-12-08 02:19:58 +01:00
// Change to client component
await next . patchFile (
filePath ,
origContent
. replace ( "// 'use client'" , "'use client'" )
. replace (
'hello dashboard/page!' ,
'hello dashboard/page in client component!'
)
)
await check (
( ) = > browser . elementByCss ( 'p' ) . text ( ) ,
/in client component/
)
// Change back to server component
await next . patchFile (
filePath ,
origContent . replace (
'hello dashboard/page!' ,
'hello dashboard/page in server component2!'
2022-11-22 19:54:44 +01:00
)
2022-12-08 02:19:58 +01:00
)
await check (
( ) = > browser . elementByCss ( 'p' ) . text ( ) ,
/in server component2/
)
// Change to client component again
await next . patchFile (
filePath ,
origContent
. replace ( "// 'use client'" , "'use client'" )
. replace (
'hello dashboard/page!' ,
'hello dashboard/page in client component2!'
)
)
await check (
( ) = > browser . elementByCss ( 'p' ) . text ( ) ,
/in client component2/
)
} finally {
await next . patchFile ( filePath , origContent )
}
2022-11-21 14:35:57 +01:00
} )
2022-12-08 02:19:58 +01:00
} )
}
2022-10-25 03:58:10 +02:00
describe ( 'searchParams prop' , ( ) = > {
describe ( 'client component' , ( ) = > {
it ( 'should have the correct search params' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ (
2022-10-25 03:58:10 +02:00
'/search-params-prop?first=value&second=other%20value&third'
)
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' )
} )
it ( 'should have the correct search params on rewrite' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/search-params-prop-rewrite' )
2022-10-25 03:58:10 +02:00
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' )
} )
it ( 'should have the correct search params on middleware rewrite' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/search-params-prop-middleware-rewrite' )
2022-10-25 03:58:10 +02:00
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' )
} )
} )
describe ( 'server component' , ( ) = > {
it ( 'should have the correct search params' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ (
2022-10-25 03:58:10 +02:00
'/search-params-prop/server?first=value&second=other%20value&third'
)
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' )
} )
it ( 'should have the correct search params on rewrite' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ ( '/search-params-prop-server-rewrite' )
2022-10-25 03:58:10 +02:00
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' )
} )
it ( 'should have the correct search params on middleware rewrite' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const $ = await next . render $ (
2022-10-25 03:58:10 +02:00
'/search-params-prop-server-middleware-rewrite'
)
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' )
} )
} )
} )
2023-01-17 00:39:54 +01:00
; ( isDev || isNextDeploy ? describe.skip : describe ) (
'Subresource Integrity' ,
( ) = > {
function fetchWithPolicy ( policy : string | null ) {
return next . fetch ( '/dashboard' , {
headers : policy
? {
'Content-Security-Policy' : policy ,
}
: { } ,
} )
}
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
async function renderWithPolicy ( policy : string | null ) {
const res = await fetchWithPolicy ( policy )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
expect ( res . ok ) . toBe ( true )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
const html = await res . text ( )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
return cheerio . load ( html )
}
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
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
]
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
for ( const policy of policies ) {
const $ = await renderWithPolicy ( policy )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Find all the script tags without src attributes and with nonce
// attributes.
const elements = $ ( 'script[nonce]:not([src])' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Expect there to be none.
expect ( elements . length ) . toBe ( 0 )
}
} )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
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=='
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// 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
]
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
for ( const policy of policies ) {
const $ = await renderWithPolicy ( policy )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Find all the script tags without src attributes.
const elements = $ ( 'script:not([src])' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Expect there to be at least 1 script tag without a src attribute.
expect ( elements . length ) . toBeGreaterThan ( 0 )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Expect all inline scripts to have the nonce value.
elements . each ( ( i , el ) = > {
expect ( el . attribs [ 'nonce' ] ) . toBe ( nonce )
} )
}
} )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
it ( 'includes an integrity attribute on scripts' , async ( ) = > {
const $ = await next . render $ ( '/dashboard' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Find all the script tags with src attributes.
const elements = $ ( 'script[src]' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Expect there to be at least 1 script tag with a src attribute.
expect ( elements . length ) . toBeGreaterThan ( 0 )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// Collect all the scripts with integrity hashes so we can verify them.
const files : [ string , string ] [ ] = [ ]
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// 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-' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
const src = el . attribs [ 'src' ]
expect ( src ) . toBeDefined ( )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
files . push ( [ src , integrity ] )
} )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
// 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 next . fetch ( src )
expect ( res . status ) . toBe ( 200 )
const content = await res . text ( )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
const hash = crypto
. createHash ( 'sha256' )
. update ( content )
. digest ( )
. toString ( 'base64' )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
expect ( integrity ) . toEndWith ( hash )
}
} )
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
it ( 'throws when escape characters are included in nonce' , async ( ) = > {
const res = await fetchWithPolicy (
` script-src 'nonce-"><script></script>"' `
)
2022-09-09 00:17:15 +02:00
2023-01-17 00:39:54 +01:00
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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/template/clientcomponent' )
2022-09-09 14:44:12 +02:00
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
2022-10-07 15:01:02 +02:00
; ( isDev ? it.skip : it ) (
'should render the template that is a server component and rerender on navigation' ,
async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/template/servercomponent' )
2022-10-07 15:01:02 +02:00
// eslint-disable-next-line jest/no-standalone-expect
expect ( await browser . elementByCss ( 'h1' ) . text ( ) ) . toStartWith (
'Template'
)
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
const currentTime = await browser
. elementByCss ( '#performance-now' )
. text ( )
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
await browser . elementByCss ( '#link' ) . click ( )
await browser . waitForElementByCss ( '#other-page' )
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
// eslint-disable-next-line jest/no-standalone-expect
expect ( await browser . elementByCss ( 'h1' ) . text ( ) ) . toStartWith (
'Template'
)
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
// template should rerender on navigation even when it's a server component
// eslint-disable-next-line jest/no-standalone-expect
expect ( await browser . elementByCss ( '#performance-now' ) . text ( ) ) . toBe (
currentTime
)
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
await browser . elementByCss ( '#link' ) . click ( )
await browser . waitForElementByCss ( '#page' )
2022-09-09 14:44:12 +02:00
2022-10-07 15:01:02 +02:00
// eslint-disable-next-line jest/no-standalone-expect
expect ( await browser . elementByCss ( '#performance-now' ) . text ( ) ) . toBe (
currentTime
)
}
)
2022-09-09 14:44:12 +02:00
} )
2022-10-11 11:17:10 +02:00
describe ( 'error component' , ( ) = > {
2022-09-09 14:44:12 +02:00
it ( 'should trigger error component when an error happens during rendering' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/error/client-component' )
2022-10-11 11:17:10 +02:00
await browser . elementByCss ( '#error-trigger-button' ) . click ( )
if ( isDev ) {
2023-01-16 08:20:16 +01:00
// TODO: investigate desired behavior here as it is currently
// minimized by default
// expect(await hasRedbox(browser, true)).toBe(true)
// expect(await getRedboxHeader(browser)).toMatch(/this is a test/)
2022-10-11 11:17:10 +02:00
} else {
2022-09-09 14:44:12 +02:00
await browser
expect (
2022-10-11 11:17:10 +02:00
await browser
. waitForElementByCss ( '#error-boundary-message' )
. elementByCss ( '#error-boundary-message' )
. text ( )
2022-09-09 14:44:12 +02:00
) . toBe ( 'An error occurred: this is a test' )
}
} )
2022-10-19 19:56:55 +02:00
it ( 'should trigger error component when an error happens during server components rendering' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/error/server-component' )
2022-10-19 19:56:55 +02:00
if ( isDev ) {
expect (
await browser
. waitForElementByCss ( '#error-boundary-message' )
. elementByCss ( '#error-boundary-message' )
. text ( )
) . toBe ( 'this is a test' )
expect (
await browser . waitForElementByCss ( '#error-boundary-digest' ) . text ( )
// Digest of the error message should be stable.
) . not . toBe ( '' )
// TODO-APP: ensure error overlay is shown for errors that happened before/during hydration
2023-01-16 08:20:16 +01:00
// expect(await hasRedbox(browser, true)).toBe(true)
2022-10-19 19:56:55 +02:00
// expect(await getRedboxHeader(browser)).toMatch(/this is a test/)
} else {
await browser
expect (
await browser . waitForElementByCss ( '#error-boundary-message' ) . text ( )
) . toBe (
'An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.'
)
expect (
await browser . waitForElementByCss ( '#error-boundary-digest' ) . text ( )
// Digest of the error message should be stable.
) . not . toBe ( '' )
}
} )
2022-10-11 11:17:10 +02:00
it ( 'should use default error boundary for prod and overlay for dev when no error component specified' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser (
2022-12-07 17:34:25 +01:00
'/error/global-error-boundary/client'
2022-09-09 14:44:12 +02:00
)
2022-10-11 11:17:10 +02:00
await browser . elementByCss ( '#error-trigger-button' ) . click ( )
if ( isDev ) {
2023-01-16 08:20:16 +01:00
expect ( await hasRedbox ( browser , true ) ) . toBe ( true )
2022-12-01 05:37:48 +01:00
expect ( await getRedboxHeader ( browser ) ) . toMatch ( /this is a test/ )
2022-10-11 11:17:10 +02:00
} else {
expect (
2022-12-07 17:34:25 +01:00
await browser . waitForElementByCss ( 'body' ) . elementByCss ( 'h2' ) . text ( )
2022-10-11 11:17:10 +02:00
) . toBe (
'Application error: a client-side exception has occurred (see the browser console for more information).'
)
}
2022-09-09 14:44:12 +02:00
} )
2022-10-11 11:17:10 +02:00
2022-12-07 17:34:25 +01:00
it ( 'should display error digest for error in server component with default error boundary' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser (
2022-12-07 17:34:25 +01:00
'/error/global-error-boundary/server'
)
if ( isDev ) {
2023-01-16 08:20:16 +01:00
expect ( await hasRedbox ( browser , true ) ) . toBe ( true )
2022-12-07 17:34:25 +01:00
expect ( await getRedboxHeader ( browser ) ) . toMatch ( /custom server error/ )
} else {
expect (
await browser . waitForElementByCss ( 'body' ) . elementByCss ( 'h2' ) . text ( )
) . toBe (
'Application error: a client-side exception has occurred (see the browser console for more information).'
)
expect (
await browser . waitForElementByCss ( 'body' ) . elementByCss ( 'p' ) . text ( )
) . toMatch ( /Digest: \w+/ )
}
} )
2022-10-11 11:17:10 +02:00
if ( ! isDev ) {
it ( 'should allow resetting error boundary' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/error/client-component' )
2022-10-11 11:17:10 +02:00
// 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 ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser (
2022-10-11 11:17:10 +02:00
'/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-09 14:44:12 +02:00
} )
2022-09-12 14:45:37 +02:00
describe ( 'known bugs' , ( ) = > {
2022-11-22 19:49:51 +01:00
describe ( 'should support React cache' , ( ) = > {
it ( 'server component' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-cache/server-component' )
2022-11-22 19:49:51 +01:00
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
it ( 'server component client-navigation' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-cache' )
2022-11-22 19:49:51 +01:00
await browser
. elementByCss ( '#to-server-component' )
. click ( )
. waitForElementByCss ( '#value-1' , 10000 )
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
it ( 'client component' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-cache/client-component' )
2022-11-22 19:49:51 +01:00
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
it ( 'client component client-navigation' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-cache' )
2022-11-22 19:49:51 +01:00
await browser
. elementByCss ( '#to-client-component' )
. click ( )
. waitForElementByCss ( '#value-1' , 10000 )
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
2023-02-17 16:34:35 +01:00
it ( 'middleware overriding headers' , async ( ) = > {
const browser = await next . browser ( '/searchparams-normalization-bug' )
await browser . eval ( ` window.didFullPageTransition = 'no' ` )
expect ( await browser . elementByCss ( '#header-empty' ) . text ( ) ) . toBe (
'Header value: empty'
)
expect (
await browser
. elementByCss ( '#button-a' )
. click ( )
. waitForElementByCss ( '#header-a' )
. text ( )
) . toBe ( 'Header value: a' )
expect (
await browser
. elementByCss ( '#button-b' )
. click ( )
. waitForElementByCss ( '#header-b' )
. text ( )
) . toBe ( 'Header value: b' )
expect (
await browser
. elementByCss ( '#button-c' )
. click ( )
. waitForElementByCss ( '#header-c' )
. text ( )
) . toBe ( 'Header value: c' )
expect ( await browser . eval ( ` window.didFullPageTransition ` ) ) . toBe ( 'no' )
} )
2022-11-22 19:49:51 +01:00
} )
describe ( 'should support React fetch instrumentation' , ( ) = > {
it ( 'server component' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-fetch/server-component' )
2022-11-22 19:49:51 +01:00
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
2023-01-16 08:20:16 +01:00
// TODO: enable when fetch cache is enabled in dev
if ( ! isDev ) {
expect ( val1 ) . toBe ( val2 )
}
2022-11-22 19:49:51 +01:00
} )
it ( 'server component client-navigation' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-fetch' )
2022-11-22 19:49:51 +01:00
await browser
. elementByCss ( '#to-server-component' )
. click ( )
. waitForElementByCss ( '#value-1' , 10000 )
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
2023-01-16 08:20:16 +01:00
// TODO: enable when fetch cache is enabled in dev
if ( ! isDev ) {
expect ( val1 ) . toBe ( val2 )
}
2022-11-22 19:49:51 +01:00
} )
// TODO-APP: React doesn't have fetch deduping for client components yet.
it . skip ( 'client component' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-fetch/client-component' )
2022-11-22 19:49:51 +01:00
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
// TODO-APP: React doesn't have fetch deduping for client components yet.
it . skip ( 'client component client-navigation' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/react-fetch' )
2022-11-22 19:49:51 +01:00
await browser
. elementByCss ( '#to-client-component' )
. click ( )
. waitForElementByCss ( '#value-1' , 10000 )
const val1 = await browser . elementByCss ( '#value-1' ) . text ( )
const val2 = await browser . elementByCss ( '#value-2' ) . text ( )
expect ( val1 ) . toBe ( val2 )
} )
} )
2022-09-12 14:45:37 +02:00
it ( 'should not share flight data between requests' , async ( ) = > {
const fetches = await Promise . all (
2022-12-19 10:20:01 +01:00
[ . . . new Array ( 5 ) ] . map ( ( ) = > next . render ( '/loading-bug/electronics' ) )
2022-09-12 14:45:37 +02:00
)
for ( const text of fetches ) {
const $ = cheerio . load ( text )
expect ( $ ( '#category-id' ) . text ( ) ) . toBe ( 'electronicsabc' )
}
} )
2023-01-12 15:48:59 +01:00
it ( 'should handle router.refresh without resetting state' , async ( ) = > {
const browser = await next . browser (
'/navigation/refresh/navigate-then-refresh-bug'
)
await browser
. elementByCss ( '#to-route' )
// Navigate to the page
. click ( )
// Wait for new page to be loaded
. waitForElementByCss ( '#refresh-page' )
// Click the refresh button to trigger a refresh
. click ( )
// Wait for element that is shown when refreshed and verify text
expect ( await browser . waitForElementByCss ( '#refreshed' ) . text ( ) ) . toBe (
'Refreshed page successfully!'
)
expect (
await browser . eval (
` window.getComputedStyle(document.querySelector('h1')).backgroundColor `
)
) . toBe ( 'rgb(34, 139, 34)' )
} )
2022-10-08 19:42:55 +02:00
it ( 'should handle as on next/link' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/link-with-as' )
2022-10-08 19:42:55 +02:00
expect (
await browser
. elementByCss ( '#link-to-info-123' )
. click ( )
. waitForElementByCss ( '#message' )
. text ( )
) . toBe ( ` hello from app/dashboard/deployments/info/[id]. ID is: 123 ` )
} )
2022-10-10 14:42:46 +02:00
it ( 'should handle next/link back to initially loaded page' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/linking/about' )
2022-10-10 14:42:46 +02:00
expect (
await browser
. elementByCss ( 'a[href="/linking"]' )
. click ( )
. waitForElementByCss ( '#home-page' )
. text ( )
) . toBe ( ` Home page ` )
expect (
await browser
. elementByCss ( 'a[href="/linking/about"]' )
. click ( )
. waitForElementByCss ( '#about-page' )
. text ( )
) . toBe ( ` About page ` )
} )
2022-11-10 19:06:57 +01:00
it ( 'should not do additional pushState when already on the page' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/linking/about' )
2022-11-10 19:06:57 +01:00
const goToLinkingPage = async ( ) = > {
expect (
await browser
. elementByCss ( 'a[href="/linking"]' )
. click ( )
. waitForElementByCss ( '#home-page' )
. text ( )
) . toBe ( ` Home page ` )
}
await goToLinkingPage ( )
await waitFor ( 1000 )
await goToLinkingPage ( )
await waitFor ( 1000 )
await goToLinkingPage ( )
await waitFor ( 1000 )
expect (
await browser . back ( ) . waitForElementByCss ( '#about-page' , 2000 ) . text ( )
) . toBe ( ` About page ` )
} )
2022-09-12 14:45:37 +02:00
} )
2022-09-20 15:28:07 +02:00
2022-10-09 17:08:51 +02:00
describe ( 'next/script' , ( ) = > {
2022-12-19 10:20:01 +01:00
if ( ! isNextDeploy ) {
2022-10-25 03:33:05 +02:00
it ( 'should support next/script and render in correct order' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/script' )
2022-10-25 03:33:05 +02:00
// Wait for lazyOnload scripts to be ready.
2023-02-22 00:52:40 +01:00
await check ( async ( ) = > {
expect ( await browser . eval ( ` window._script_order ` ) ) . toStrictEqual ( [
1 ,
1.5 ,
2 ,
2.5 ,
'render' ,
3 ,
4 ,
] )
return 'yes'
} , 'yes' )
2022-10-25 03:33:05 +02:00
} )
}
2022-10-09 17:08:51 +02:00
it ( 'should insert preload tags for beforeInteractive and afterInteractive scripts' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const html = await next . render ( '/script' )
2022-10-09 17:08:51 +02:00
expect ( html ) . toContain (
2023-02-28 10:13:02 +01:00
'<link rel="preload" as="script" href="/test1.js"/>'
2022-10-09 17:08:51 +02:00
)
expect ( html ) . toContain (
2023-02-28 10:13:02 +01:00
'<link rel="preload" as="script" href="/test2.js"/>'
2022-10-09 17:08:51 +02:00
)
expect ( html ) . toContain (
2023-02-28 10:13:02 +01:00
'<link rel="preload" as="script" href="/test3.js"/>'
2022-10-09 17:08:51 +02:00
)
// test4.js has lazyOnload which doesn't need to be preloaded
expect ( html ) . not . toContain (
2023-02-28 10:13:02 +01:00
'<script rel="preload" as="script" src="/test4.js"/>'
2022-10-09 17:08:51 +02:00
)
} )
} )
2022-10-30 16:52:35 +01:00
describe ( 'data fetch with response over 16KB with chunked encoding' , ( ) = > {
2022-11-03 01:19:59 +01:00
it ( 'should load page when fetching a large amount of data' , async ( ) = > {
2022-12-19 10:20:01 +01:00
const browser = await next . browser ( '/very-large-data-fetch' )
2022-11-03 01:19:59 +01:00
expect ( await ( await browser . waitForElementByCss ( '#done' ) ) . text ( ) ) . toBe (
'Hello world'
)
expect ( await browser . elementByCss ( 'p' ) . text ( ) ) . toBe ( 'item count 128000' )
} )
2022-10-30 16:52:35 +01:00
} )
2022-08-02 00:34:23 +02:00
}
2022-12-19 10:20:01 +01:00
)