@nuxt/docs-nightly 5.0.0-29555264.66acadfc → 5.0.0-29555522.b030db42
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -348,6 +348,22 @@ If you define redirect route rules, the property name has changed:
|
|
|
348
348
|
- **Runtime hooks**: `nitroApp.hooks.hook('beforeResponse', ...)` and `nitroApp.hooks.hook('afterResponse', ...)` have been replaced by `nitroApp.hooks.hook('response', ...)`.
|
|
349
349
|
- **`getRouteRules()` from `nitro/app`**: On the server, the Nitro helper changed from `getRouteRules(event)` to `getRouteRules(method, pathname)`, which returns `{ routeRules }`.
|
|
350
350
|
|
|
351
|
+
### Removal of Legacy `_renderResponse` Support
|
|
352
|
+
|
|
353
|
+
🚦 **Impact Level**: Minimal
|
|
354
|
+
|
|
355
|
+
#### What Changed
|
|
356
|
+
|
|
357
|
+
`ssrContext._renderResponse` is no longer checked as a fallback. Only the internal `ssrContext['~renderResponse']` (set by Nuxt's own router composable) is used.
|
|
358
|
+
|
|
359
|
+
#### Reasons for Change
|
|
360
|
+
|
|
361
|
+
The `_renderResponse` property on `ssrContext` was kept as a backward-compatibility fallback after [#33896](https://github.com/nuxt/nuxt/pull/33896) migrated the internal API to `~renderResponse`. The TODO comments indicated it should be removed in Nuxt v5.
|
|
362
|
+
|
|
363
|
+
#### Migration Steps
|
|
364
|
+
|
|
365
|
+
If you were setting `ssrContext._renderResponse` directly (which was never a public API), use `ssrContext['~renderResponse']` instead. The Nuxt router composable already uses the new property, so no changes are needed if you're going through `navigateTo` or route middleware.
|
|
366
|
+
|
|
351
367
|
### Non-Async `callHook`
|
|
352
368
|
|
|
353
369
|
🚦 **Impact Level**: Minimal
|
|
@@ -168,7 +168,7 @@ This is useful when you want to manage layouts centrally in your configuration r
|
|
|
168
168
|
|
|
169
169
|
:link-example{to="/docs/4.x/examples/features/layouts"}
|
|
170
170
|
|
|
171
|
-
## Passing Props to Layouts
|
|
171
|
+
## Passing Props to Layouts :badge[+4.4]{color="primary" class="align-middle"}
|
|
172
172
|
|
|
173
173
|
You can pass props to layouts in several ways.
|
|
174
174
|
|
|
@@ -48,6 +48,10 @@ This is similar to using `v-html` with external content - the remote server can
|
|
|
48
48
|
The `dangerouslyLoadClientComponents` prop controls an additional layer of risk: whether to also download and execute client components from the remote source. Even with `dangerouslyLoadClientComponents` disabled (the default), you are still trusting the remote server's HTML output.
|
|
49
49
|
::
|
|
50
50
|
|
|
51
|
+
::note
|
|
52
|
+
Component props and context are sent as GET query parameters to enable caching. Query parameters may be visible in server access logs, CDN caches, and HTTP `Referer` headers.
|
|
53
|
+
::
|
|
54
|
+
|
|
51
55
|
::note
|
|
52
56
|
By default, component islands are scanned from the `~/components/islands/` directory. So the `~/components/islands/MyIsland.vue` component could be rendered with `<NuxtIsland name="MyIsland" />`.
|
|
53
57
|
::
|