This is possibly the last minor release before Nuxt v4, and so we've packed it full of features and improvements we hope will delight you! ✨
When developing a Nuxt application and using console.log in your application, you may have noticed that these logs are not displayed in your browser console when refreshing the page (during server-side rendering). This can be frustrating, as it makes it difficult to debug your application. This is now a thing of the past!
Now, when you have server logs associated with a request, they will be bundled up and passed to the client and displayed in your browser console. Asynchronous context is used to track and associate these logs with the request that triggered them. (#25936).
For example, this code:
pages/index.vue
<script setup>
console.log('Log from index page')
const { data } = await useAsyncData(() => {
console.log('Log inside useAsyncData')
return $fetch('/api/test')
})
</script>
will now log to your browser console when you refresh the page:
Log from index page
[ssr] Log inside useAsyncData
at pages/index.vue
👉 We also plan to support streaming of subsequent logs to the Nuxt DevTools in future.
We've also added a dev:ssr-logs hook (both in Nuxt and Nitro) which is called on server and client, allowing you to handle them yourself if you want to.
If you encounter any issues with this, it is possible to disable them - or prevent them from logging to your browser console.
nuxt.config.ts
export default defineNuxtConfig({
features: {
devLogs: false
// or 'silent' to allow you to handle yourself with `dev:ssr-logs` hook
},
})
A new usePreviewMode composable aims to make it simple to use preview mode in your Nuxt app.
plugins/test.client.ts
const { enabled, state } = usePreviewMode()
When preview mode is enabled, all your data fetching composables, like useAsyncData and useFetch will rerun, meaning any cached data in the payload will be bypassed.
Read more in Docs > API > Composables > Use Preview Mode.
We now automatically cache-bust your payloads if you haven't disabled Nuxt's app manifest, meaning you shouldn't be stuck with outdated data after a deployment (#26068).
routeRulesIt's now possible to define middleware for page paths within the Vue app part of your application (that is, not your Nitro routes) (#25841).
nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/admin/**': {
// or appMiddleware: 'auth'
appMiddleware: ['auth']
},
'/admin/login': {
// You can 'turn off' middleware that would otherwise run for a page
appMiddleware: {
auth: false
}
},
},
})
Read more in Docs > Guide > Concepts > Rendering#route Rules.
clear data fetching utilityNow, useAsyncData and useFetch expose a clear utility. This is a function that can be used to set data to undefined, set error to null, set pending to false, set status to idle, and mark any currently pending requests as cancelled. (#26259)
<script setup lang="ts">
const { data, clear } = await useFetch('/api/test')
const route = useRoute()
watch(() => route.path, (path) => {
if (path === '/') clear()
})
</script>
Read more in Docs > Getting Started > Data Fetching.
#teleports targetNuxt now includes a new <div id="teleports"></div> element in your app within your <body> tag. It supports server-side teleports, meaning you can do this safely on the server:
app.vue
<template>
<Teleport to="#teleports">
<span>
Something
</span>
</Teleport>
</template>
It's now possible to set custom timings for hiding the loading indicator, and forcing the finish() method if needed (#25932).
There's also a new page:view-transition:start hook for hooking into the View Transitions API (#26045) if you have that feature enabled.
This release sees server- and client-only pages land in Nuxt! You can now add a .server.vue or .client.vue suffix to a page to get automatic handling of it.
Client-only pages will render entirely on the client-side, and skip server-rendering entirely, just as if the entire page was wrapped in <ClientOnly>. Use this responsibly. The flash of load on the client-side can be a bad user experience so make sure you really need to avoid server-side loading. Also consider using <ClientOnly> with a fallback slot to render a skeleton loader (#25037).
⚗️ Server-only pages are even more useful because they enable you to integrate fully-server rendered HTML within client-side navigation. They will even be prefetched when links to them are in the viewport - so you will get instantaneous loading (#24954).
When you are using server components, you can now use the nuxt-client attribute anywhere within your tree (#25479).
nuxt.config.ts
export default defineNuxtConfig({
experimental: {
componentIslands: {
selectiveClient: 'deep'
}
},
})
You can listen to an @error event from server components that will be triggered if there is any issue loading the component (#25798).
Finally, server-only components are now smartly enabled when you have a server-only component or a server-only page within your project or any of its layers (#26223).
Server components remain experimental and their API may change, so be careful before depending on implementation details.
We've shipped a number of performance improvements, including only updating changed virtual templates (#26250), using a 'layered' prerender cache (#26104) that falls back to filesystem instead of keeping everything in memory when prerendering - and lots of other examples.
We have shipped a reimplementation of Vite's public asset handling, meaning that public assets in your public/ directory or your layer directories are now resolved entirely by Nuxt (#26163), so if you have added nitro.publicAssets directories with a custom prefix, these will now work.
We have changed the default _nuxt/[name].[hash].js file name pattern for your JS chunks. Now, we default to _nuxt/[hash].js. This is to avoid false positives by ad blockers triggering off your component or chunk names, which can be a very difficult issue to debug. (#26203)
You can easily configure this to revert to previous behaviour if you wish:
nuxt.config.ts
export default defineNuxtConfig({
vite: {
$client: {
build: {
rollupOptions: {
output: {
chunkFileNames: '_nuxt/[name].[hash].js',
entryFileNames: '_nuxt/[name].[hash].js'
}
}
}
}
},
})
Previously users with shamefully-hoist=false may have encountered issues with types not being resolved or working correctly. You may also have encountered problems with excessive type instantiation.
We now try to tell TypeScript about certain key types so they can be resolved even if deeply nested (#26158).
There are a whole raft of other type fixes, including some regarding import types (#26218 and #25965) and module typings (#25548).
As usual, our recommendation for upgrading Nuxt is to run:
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
Read the full release notes of Nuxt v3.11.0.
Thank you for reading this far! We hope you enjoy the new release. Please do let us know if you have any feedback or issues.
Happy Nuxting ✨
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。