From 7f5787369008f589d11c7cdbe3c0b71f164a4c76 Mon Sep 17 00:00:00 2001 From: Pooya Parsa Date: Tue, 18 Oct 2022 20:18:16 +0200 Subject: [PATCH 1/2] docs: add route rules to the concepts > rendering --- .../content/2.guide/1.concepts/3.rendering.md | 43 ++++++++++++++++--- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/docs/content/2.guide/1.concepts/3.rendering.md b/docs/content/2.guide/1.concepts/3.rendering.md index 74baa3608d6..f388abf5974 100644 --- a/docs/content/2.guide/1.concepts/3.rendering.md +++ b/docs/content/2.guide/1.concepts/3.rendering.md @@ -69,14 +69,47 @@ In most cases, universal rendering as performed in Nuxt 2 offers a good user and ### Hybrid Rendering -Hybrid rendering allows different caching rules per route and decides how the Server should respond to a new request on a given URL. - -At the moment, every page (or **route**) of a Nuxt application must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application. - -[Read the open RFC discussing implementation and gathering community feedback.](https://github.com/nuxt/framework/discussions/560) +Hybrid rendering allows different caching rules per route using **Route Rules** and decides how the Server should respond to a new request on a given URL. ### Rendering on CDN Edge Workers Traditionally, server-side and universal rendering was only possible using Node.js. Nuxt 3 takes it to another level by directly rendering code in CDN edge workers, reducing latency and costs. Nitro is the new [server engine](/guide/concepts/server-engine) that powers Nuxt 3. It offers cross-platform support for Node.js, Deno, Workers, and more. Nitro's design is platform-agnostic and allows rendering a Nuxt application at the edge, closer to your users, allowing replication and further optimizations. + +### Route Rules + +> 🧪 Route rules are still under active development, and subject to change. + +Previously every page (or **route**) of a Nuxt application and server must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application. + +Nuxt 3 starting from rc.12 comes with the public beta for route rules and hybrid rendering support. Using route rules you can define rules for a group of nuxt routes, change rendering mode or assign a cache strategy based on route! Nuxt server will automatically register corresponding middleware and wrap routes with cache handlers using [nitro caching layer](https://nitro.unjs.io/guide/introduction/cache). Whenever possible, route rules will be automatically applied to the deployment platform's native rules (currently netlify and vertical are supported). + +* `redirect` - Define server-side redirects. +* `ssr` - Disables server-side rendering for sections of your app and make them SPA-only with `ssr: false` +* `cors` - Automatically adds cors headers with `cors: true` - you can customize the output by overriding with `headers` +* `headers` - Add specific headers to sections of your site - for example, your assets +* `static` and `swr` - `static` enables a single (on-demand) build; `swr` enables a static build, that lasts for a configurable TTL. (currently enables full incremental static generation on netlify, with Vercel coming soon) + + +**Examples:** + +```ts +export default defineNuxtConfig({ + routeRules: { + // Static page generated on-demand, revalidates in background + '/blog/**': { swr: true }, + // Static page generated on-demand once + '/articles/**': { static: true }, + // Set custom headers matching paths + '/_nuxt/**': { headers: { 'cache-control': 's-maxage=0' } }, + // Render these routes with SPA + '/admin/**': { ssr: false }, + // Add cors headers + '/api/v1/**': { cors: true }, + // Add redirect headers + '/old-page': { redirect: '/new-page' }, + '/old-page2': { redirect: { to: '/new-page', statusCode: 302 } } + } +}) +``` From aff6d17a00dbfe9ff5e222ceea49615ec7bb2875 Mon Sep 17 00:00:00 2001 From: Pooya Parsa Date: Tue, 18 Oct 2022 21:12:28 +0200 Subject: [PATCH 2/2] small updates --- docs/content/2.guide/1.concepts/3.rendering.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/docs/content/2.guide/1.concepts/3.rendering.md b/docs/content/2.guide/1.concepts/3.rendering.md index f388abf5974..ab37405028c 100644 --- a/docs/content/2.guide/1.concepts/3.rendering.md +++ b/docs/content/2.guide/1.concepts/3.rendering.md @@ -81,16 +81,15 @@ Nitro is the new [server engine](/guide/concepts/server-engine) that powers Nuxt > 🧪 Route rules are still under active development, and subject to change. -Previously every page (or **route**) of a Nuxt application and server must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application. +Previously every route/page of a Nuxt application and server must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application. -Nuxt 3 starting from rc.12 comes with the public beta for route rules and hybrid rendering support. Using route rules you can define rules for a group of nuxt routes, change rendering mode or assign a cache strategy based on route! Nuxt server will automatically register corresponding middleware and wrap routes with cache handlers using [nitro caching layer](https://nitro.unjs.io/guide/introduction/cache). Whenever possible, route rules will be automatically applied to the deployment platform's native rules (currently netlify and vertical are supported). - -* `redirect` - Define server-side redirects. -* `ssr` - Disables server-side rendering for sections of your app and make them SPA-only with `ssr: false` -* `cors` - Automatically adds cors headers with `cors: true` - you can customize the output by overriding with `headers` -* `headers` - Add specific headers to sections of your site - for example, your assets -* `static` and `swr` - `static` enables a single (on-demand) build; `swr` enables a static build, that lasts for a configurable TTL. (currently enables full incremental static generation on netlify, with Vercel coming soon) +Nuxt 3 starting from rc.12 comes with the public beta for route rules and hybrid rendering support. Using route rules you can define rules for a group of nuxt routes, change rendering mode or assign a cache strategy based on route! Nuxt server will automatically register corresponding middleware and wrap routes with cache handlers using [nitro caching layer](https://nitro.unjs.io/guide/introduction/cache). Whenever possible, route rules will be automatically applied to the deployment platform's native rules (currently Netlify and Vercel are supported). +- `redirect` - Define server-side redirects. +- `ssr` - Disables server-side rendering for sections of your app and make them SPA-only with `ssr: false` +- `cors` - Automatically adds cors headers with `cors: true` - you can customize the output by overriding with `headers` +- `headers` - Add specific headers to sections of your site - for example, your assets +- `static` and `swr` - `static` enables a single (on-demand) build; `swr` enables a static build, that lasts for a configurable TTL. (currently enables full incremental static generation on Netlify, with Vercel coming soon) **Examples:**