My Page
Hello
```
**Good - 1 root element**
```vue
My Page
Hello
I'll be doing a talk on this release at the upcoming [NuxtNation](https://nuxtnation.com/), make sure you catch it! :: ## Pre v1 Achievements Taking over maintenance was pretty daunting. There were a number of tricky problems to solve. I started with some low-hanging fruit: `useHead` TypeScript support ([6f919c7](https://github.com/vueuse/head/pull/85)). This one was pretty tedious, but well worth it for developer experience. In creating the types, I made the [zhead](https://github.com/harlan-zw/zhead) package to share the types with the ecosystem and some other small utils. Next up was computed getter support ([b6d74dbeb](https://github.com/vueuse/head/commit/b6d74dbebd32f772923f722c399091c73e21b6ed)). With VueUse 9, the recommended way to deal with computed data was with a computed getter, which is simply a function. However, `useHead` only let you use `computed` or `ref`. This was a pretty easy fix, however it illuminated a major performance bottleneck. So my full attention went into performance ([e1bc8d2](https://github.com/vueuse/head/commit/e1bc8d2e35a9104adbd3a62c29bdadb89181b3fc), [691bcc8](https://github.com/vueuse/head/commit/691bcc88ae3526879238995866daeec39e8bc4c6)). 🏎️ And with that the package was now \~5x faster in patching the DOM. ## Why a major bump? While most issues were closed and easy to solve, there was a major outstanding issue that I wanted to address, *Server Only Tags* (removed, `nuxt/framework` discussions were retired after the Nuxt 3 merge into `nuxt/nuxt`). There was also a nasty issue with tags disappearing unexpectedly when hydrating. Both of these were blocked by how the DOM patching was designed. The old strategy was to add state to the DOM and use this to determine what tags to remove. ```html ``` You can see in the above, we're tracking the attributes being added and the number of tags. The `head:count` element is used as an anchor to start rendering tags from. It would take all tags to be rendered, check the dom elements upwards from the `head:count` meta tag if any needed to be inserted or if they already existed, otherwise delete them. This had a issues when you look closely: ### Deleting DOM elements it doesn't own It would modify whatever element is in the position regardless if it's an element created from `@vueuse/head`. This led to issues with a third-party script inserting something in between these DOM elements, and it getting deleted. It also blocked server only tags, as the client would overwrite them when hydrating. ### Performance Previous DOM patching would delete and re-render tags which shared dedupe keys. Not noticeable functionally but a performance consideration. To solve these issues, a new DOM patching algorithm was needed that tracked side effects gracefully. ### State in DOM isn't so nice Purely from a DX perspective, it's not nice to have state in the DOM that isn't needed. It's not a big deal, but it's not ideal. ## Unhead This was a major piece of work, and I figured if I'm going to have to refactor the entire package, I should aim to also solve another outstanding issue, *Universal Head Management*. So I started on [Unhead](https://github.com/harlan-zw/unhead), a Universal document tag manager. My initial concern was just feature parity with `@vueuse/head` while supporting server tags, but I quickly realised that I could do better. So Unhead was born. It has first-party support for Vue, but there is planned work to support any and all other frameworks (eventually). @vueuse/head v1 is now a thin wrapper for unhead, while being fully backwards compatible. There are too many enhancements and feature improvements to mention here, check the below release notes or jump straight to the [docs](https://unhead.unjs.io). I'm excited about this new package, and I hope you are too! I'll be writing a dedicated blog post about it soon. ## v1.0.0 Release ### 🤖 Core Now powered by [unhead](https://github.com/harlan-zw/unhead). Featuring: - a new DOM patching algorithm that tracks side effects gracefully, less aggressive removal of tags and attributes - ⚡ DOM rendering optimisations, 5x faster (\~10ms for an avg site), async for quicker initial main thread load. - 🧹 No more non-essential state in DOM ### ✨ Enhancements - Vue 2.7 Support ([docs](https://unhead.unjs.io)) - Options API Support ([docs](https://unhead.unjs.io)) #### htmlAttrs / bodyAttrs merging [Documentation](https://unhead.unjs.io) Now merged by default instead of replace. ```ts useHead({ htmlAttrs: { class: 'my-class', }, }) // we don't want that class to be on a specific page, instead we want a new class useHead({ htmlAttrs: { class: 'another-class', }, }) // ``` #### Array / Object Classes [Documentation](https://unhead.unjs.io) When using the htmlAttrs or bodyAttrs options, you can use the class attribute to add classes to the html or body elements. ```ts const darkMode = false useHead({ htmlAttrs: { class: { // will be rendered dark: darkMode, // will not be rendered light: !darkMode, } }, bodyAttrs: { class: ['layout-id', 'page-id'] } }) ``` #### Better deduping [Documentation](https://unhead.unjs.io) Tag deduping is now vastly improved. It's likely you won't need `key` anymore. Includes support for meta content array support, reduces boilerplate by using arrays for meta tags. ```ts useHead({ meta: [ { name: 'og:image', content: [ 'https://example.com/image.png', 'https://example.com/image2.png', ], }, ], }) ``` #### Prop promises You can provide a promise to props and it will be resolved when rendering the tags. ```ts useHead({ script: [ { children: new Promise(resolve => resolve('console.log("hello world")')) }, ], }) ``` ### 🚀 New Features #### useServerHead [Documentation](https://unhead.unjs.io) Lets you render tags on the server only. This has the same API as `useHead`. ```ts useServerHead({ scripts: [ { // this wouldn't work on the client, so we use useServerHead src: import('~/assets/my-script.js?url'), } ] }) ``` #### useSeoMeta [Documentation](https://unhead.unjs.io) Define meta tags in a flat object, fully typed. ```ts useSeoMeta({ description: 'My about page', ogDescription: 'Still about my about page', ogTitle: 'About', ogImage: 'https://example.com/image.png', twitterCard: 'summary_large_image', }) ``` #### tagPosition [Documentation](https://unhead.unjs.io) Lets you define the position of a tag in the DOM. ```ts useHead({ script: [ { src: 'https://example.com/script.js', tagPosition: 'bodyOpen', } ] }) ``` #### tagPriority [Documentation](https://unhead.unjs.io) Lets you define the priority of a tag with a number or string. ```ts useHead({ script: [{ key: 'not-important', src: '/not-important-script.js', },], }) useHead({ script: [ { // script is the tag name to target, `not-important` is the key we're targeting tagPriority: 'before:script:not-important', src: '/must-be-first-script.js', }, ], }) ``` #### tagDuplicateStrategy [Documentation](https://unhead.unjs.io) #### DOM Event Handlers [Documentation](https://unhead.unjs.io) Function support for DOM event handlers. ```ts useHead({ bodyAttrs: { onresize: (e) => { console.log('resized', e) } }, script: [ { src: 'https://example.com/analytics.js', onload: (el) => { console.log('loaded', el) } } ] }) ``` #### Hooks Engine is now powered by hooks, provided by [hookable](https://github.com/unjs/hookable). This allows you to hook into any of the core functionality. See [API hooks](https://unhead.unjs.io) and [Infer SEO MetaTags](https://unhead.unjs.io), not documented properly yet. #### New shortcut composables Same API as `useHead`, but targeted as a specific tag type. - useTagTitle - useTagBase - useTagMeta - useTagLink - useTagScript - useTagStyle - useTagNoscript - useHtmlAttrs - useBodyAttrs - useTitleTemplate ## Migration Guide ⚠️ Breaking changes are minimal, but there are some changes to be aware of. Please report any issues you find and they will fixed be promptly. You may consider using [@unhead/vue](https://unhead.unjs.io) directly if you [don't need @vueuse/head](https://unhead.unjs.io). ### Verify your tags The new DOM patching algorithm has not been tested in all possible scenarios, it's possible that there are unforeseen edge cases. ### `htmlAttrs` and `bodyAttrs` merge strategy If you had built your code around with the assumption that setting `htmlAttrs` or `bodyAttrs` would clear the old tags, this is now different. ```ts // old useHead({ htmlAttrs: { class: 'my-class', }, }) useHead({ htmlAttrs: { class: 'new-class', }, }) // ``` ```ts // new useHead({ htmlAttrs: { class: 'my-class', }, }) useHead({ htmlAttrs: { class: 'new-class', }, }) // ``` Check the [documentation](https://unhead.unjs.io) to learn more. ### Duplicate tags in `useHead` To make duplicate tag handling more intuitive, duplicate tags are now allowed in the same `useHead` call. Previously you would have to use `key` to differentiate them. ```ts // old - key is required useHead({ meta: [ { name: 'og:locale:alternate', content: 'es_ES', key: 'locale_es' }, { name: 'og:locale:alternate', content: 'fr_FR', key: 'locale_fr' }, ], }) // // ``` You can safely remove `key` now. ```ts // new - key is no longer required useHead({ meta: [ { name: 'og:locale:alternate', content: 'es_ES' }, { name: 'og:locale:alternate', content: 'fr_FR' }, ], }) // // ``` It's worth checking that if you did have duplicate tags in the same entry, you will now be rendering both of them potentially. ## Next Steps If you have any issues and/or questions related to v1, please comment in the [discussion](https://github.com/vueuse/head/discussions/161). If you have any ideas on the future of unhead and @vueuse/head please get in touch with me through an issue, Discord or Twitter. Thanks for reading! --- - **Page:** Nuxt 3 Migration Simplified: A Cheat Sheet - **Source:** https://harlanzw.com/blog/nuxt-3-migration-cheatsheet - **Description:** A simplified cheat sheet for migrating from Nuxt 2 to Nuxt 3. Includes a list of all the changes you need to make to your Nuxt 2 project to get it working with Nuxt 3. ## Introduction Upgrading to Nuxt 3 from Nuxt 2 can be a little intimidating. There are a ton of changes to keep track of, and it's easy to feel like you're lost in a maze of code. But don't worry, I'm here to help! I've started this cheat sheet to simplify the upgrade process for myself and for others who are brave enough to tackle it. It's a work in progress, and not intended to be exhaustive. I'll be updating it as I migrate more sites. Just remember that the migration process will take some time, patience, and persistence, depending on the size of your project and your prior experience. But hey, at least you'll learn a bunch. And if you're just looking to upgrade some modules, I've written an [upgrade guide](#2-modules) for 23 of them. Let's do this! ## Resources ### Links **Docs** - [Nuxt 3 - Docs](https://nuxt.com/docs/getting-started/introduction) - [Nuxt 3 - Official Migration Guide](https://nuxt.com/docs/migration/overview) - Nuxt 3 - Migration guide discussion (removed, `nuxt/framework` discussions were retired after the Nuxt 3 merge into `nuxt/nuxt`) - [Vue 3 - Migration Guide](https://v3-migration.vuejs.org/) **Tech** - [UnJS](https://unjs.io/) – A collection of packages which make up the Nuxt core. - [VueUse](https://vueuse.org/) – Essential Vue Composition API utilities. - [Vite.js](https://vitejs.dev) and [Rollup](https://rollupjs.org/) – Backbone of Nuxt 3 bundling. **Nuxt 3 Examples** - [Nuxt Examples](https://nuxt.com/docs/examples/essentials/hello-world) - Minimal scoped examples - [NuxtBnB](https://web.archive.org/web/20230106223315/https://github.com/MasteringNuxt/NuxtBnB) - Complex app (repo removed; archived snapshot) - [Nuxt Movies](https://github.com/nuxt/movies) - Complex app - [harlanzw.com](https://github.com/harlan-zw/harlanzw.com) - @nuxt/content app ### Education - Free: NuxtNation 2022 [YouTube playlist](https://www.youtube.com/playlist?list=PLxddmVXxb3Hu4yg6jEUBcQ6xix6QM0ews) - Paid: [Mastering Nuxt](https://masteringnuxt.com/) ### Getting help - [Discord](https://discord.com/invite/ps2h6QT): create a post in `#nuxt3-help` if you get stuck - Twitter Nuxt Community (removed, the community no longer exists) - Post on StackOverflow with the tag [Nuxt](https://stackoverflow.com/questions/tagged/nuxt), [kissu](https://stackoverflow.com/users/8816585/kissu) may help you if you're lucky - [Reddit Nuxt.js](https://www.reddit.com/r/nuxtjs/) ::tip Need quicker help? Try providing a [reproduction repo](https://nuxt.com/docs/community/reporting-bugs#create-a-minimal-reproduction).
At a minimal, provide the output of `npx nuxi info`. :: ## Pre-migration Before you start upgrading, it's important to familiarise yourself with the new features and changes in Nuxt 3 and prepare your project for the upgrade. ### 1. Get familiar with Nuxt 3 Learn the key differences between Nuxt 2 and Nuxt 3 and the new technologies that power it. ::checkbox #default Nuxt 3 Architecture #tip While there are many similarities to Nuxt 2, the underlying architecture is completely new, more complex and more powerful. Start by learning the differences between: - [Nuxt](https://nuxt.com/docs/guide/going-further/internals#the-nuxt-interface) (core context) - [Nuxt App](https://nuxt.com/docs/guide/going-further/internals#the-nuxtapp-interface) (app context) - [Nitro](https://nuxt.com/docs/guide/concepts/server-engine) (server engine) - Nuxi (command line interface) You may want to re-familiarise yourself with the [Rendering modes](https://nuxt.com/docs/guide/concepts/rendering) (SSR, SPA, Static). Daniel Roe's talk [What happens when you start Nuxt 3](https://www.youtube.com/watch?v=IVA_76hKEwE) is a great place to start. :: ::checkbox #default Read the official migration guide #tip Having a rough understanding of the [migration process](https://nuxt.com/docs/migration/overview) will allow you avoid common pitfalls. Keep this open as you'll reference this as you continue on with the migration process. :: ::checkbox #default Play with Nuxt 3 #tip Create a new fresh Nuxt 3 project using [nuxt.new](https://nuxt.new), play around with it. This will help you get a feel for the new features and how they work. :: ::checkbox #default Learn Vue 3 / Composition API #tip Vue 3 is a major upgrade from Vue 2. You will need to learn the new syntax and features to be able to use Nuxt 3, particularly the [Composition API](https://vuejs.org/guide/extras/composition-api-faq.html). :: ::checkbox #default Learn the basics of TypeScript #tip Whether you like TypeScript or not is irrelevant. Nuxt 3 is written in TypeScript, trying to avoid it will only make your life harder. You don't need to be an expert, but you should be able to read and understand the Nuxt 3 code. You can learn the basics with [TypeScript in 5 minutes](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html). :: ::checkbox #default Learn about modules: CJS and ESM #tip Nuxt 3 requires ECMAScript modules, so you'll need to convert your CommonJS modules. See the Nuxt [ES modules](https://nuxt.com/docs/guide/concepts/esm) page. Many of the issues you'll come across are due to using dependencies which are CJS. So understanding the difference between them can be critical. Node modules can be a challenging subject, if you need further guidance see [this article](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/). :: ### 2. Prepare your Nuxt 2 app Before you start migrating, you should prepare your Nuxt 2 app to make the upgrade process easier. ::checkbox #default Upgrade Nuxt 2 #tip If you are on an earlier version, the first step is upgrading. The latest Nuxt 2 uses [Vue 2.7](https://blog.vuejs.org/posts/vue-2-7-naruto.html), which supports the Composition API. ```bash npm i nuxt@^2.15.4 # yarn add nuxt@^2.15.4 ``` :: ::checkbox #default Upgrade Modules #tip Upgrade your modules to the latest version that supports Nuxt 2. This will make the upgrade process easier. Be careful not to upgrade modules which may only support Nuxt 3 in future versions. :: ::checkbox #default Enable component auto-imports #tip Nuxt 3 has auto-imports enabled by default, if you're not using this feature in Nuxt 2, you should enable it to identify any component paths that need to be updated. All manual component imports should be removed. See [Components Discovery](https://nuxtjs.org/docs/directory-structure/components/#components-discovery) for more information. ```ts [nuxt.config.ts] export default { components: true } ``` :: ::checkbox #default Audit your dependencies #tip Having hard dependencies in your project that aren't compatible with Nuxt 3 / Vue 3 is going to massively slow you down. You should go through all your node dependencies, checking the following: - Vue plugin: Supports Vue 3 - Nuxt module: Supports Nuxt 3 or has an upgrade path. See [Migration - 2. modules](#2-modules) and the [Nuxt 3 modules](https://nuxt.com/modules). - Other: Scan with [bundlephobia](https://bundlephobia.com/) to find ESM support / alternatives. You can use CJS dependencies, but you'll need to [transpile](https://nuxt.com/docs/guide/concepts/esm#transpiling-libraries) them. This is a good opportunity to drop any dependencies you don't need, migrate to dependencies which have better maintenance and / or are smaller. :: ## Migration This cheat sheet requires a fresh Nuxt 3 project and migrating things over one by one. In each step of migrating, you should test to see if everything is working. If there are bugs, then you will be able to debug them easily. ### 1. Create the new app The first step is creating the new apps boilerplate and migrate over safe config from `nuxt.config.ts`. ::checkbox #default Create a Fresh Nuxt 3 App #tip You can do so with `npx nuxi init my-app`. This will create a new Nuxt 3 project. :: ::checkbox #default Create Boilerplate #tip By default, Nuxt 3 does not provide page routing and layouts. To make the migration easier, you'll be modifying the files to be Nuxt 2 compatible. To enable them we update `app.vue` with `NuxtLayout` and `NuxtPage`. ```vue [app.vue]
hello world
{prefix}-{namespace}{?-class}
#### Prefix
> Base components (a.k.a. presentational, dumb, or pure components) that apply app-specific styling and conventions should all begin with a specific prefix, such as Base, App, or V.
A short prefix for *all* your components is preferable to the above.
Using a prefix avoids conflicts with HTML tags and third-party components. It also gives you scoped IDE autocompletion and more reusable components.
Prefixing becomes especially important when working with a component library ([Vuetify](https://vuetifyjs.com/), [VueStrap](https://yuche.github.io/vue-strap/), etc) or third-party components
([algolia](https://github.com/algolia/vue-instantsearch), [google maps](https://github.com/xkjyeah/vue-google-maps), etc).
You should use something which relates to your app, for example, I use `h` as the prefix because my site is [harlanzw.com](http://harlanzw.com).
```vue
Please enter your email to subscribe
Keep up to date
Please make sure you've read our Forum Rules before replying.
{{ msg }}
...
```
Once the web server gets this request, it will need to compile the `CardPost.vue` file to javascript and send it back. Vite has many
optimisations around the Vue compiling so this takes no time.
Let's see what comes through:
```js [CardPost.vue - Transpiled]
import '/@theme/components/CardPost.vue?type=style&index=0'
import posts from '/.vitepress/posts.ts'
import { render as __render } from '/@theme/components/CardPost.vue?type=template'
const __script = {
props: {
postIndex: {
type: Number,
required: true,
}
},
computed: {
post() {
return posts[this.postIndex]
}
}
}
__script.__scopeId = 'data-v-287b4794'
__script.render = __render
__script.__hmrId = '/@theme/components/CardPost.vue'
typeof __VUE_HMR_RUNTIME__ !== 'undefined' && __VUE_HMR_RUNTIME__.createRecord(__script.__hmrId, __script)
__script.__file = '/home/harlan/sites/new.harlanzw.com/app/.vitepress/theme/components/CardPost.vue'
export default __script
```
Cool, so quite a bit going on here. The main thing to note here is how it's split up the SFC into different modules which
will need separate requests to fetch. It hasn't bundled these imports into the SFC or some other monolith file.
- Dependencies: `/.vitepress/posts.ts`
- Template: `/@theme/components/CardPost.vue?type=template`
- Stylesheet: `/@theme/components/CardPost.vue?type=style&index=0`
If you're curious, this is what the style component response looks like, some nifty for sure.
```js [CardPost.vue - CSS]
import { updateStyle } from '/vite/client'
const css = '.card-post[data-v-287b4794] {\n position: relative;\n}\n.card-post .prose[data-v-287b4794] {\n max-width: 100% !important;\n}\n.card-post__link[data-v-287b4794] {\n position: absolute;\n left: 0;\n top: 0;\n width: 100%;\n height: 100%;\n content: " ";\n z-index: 1;\n}\n.card-post__content[data-v-287b4794] {\n background-color: white;\n z-index: 1;\n}\n.card-post__effect[data-v-287b4794] {\n z-index: -1;\n content: " ";\n height: 30px;\n width: 100%;\n position: absolute;\n background-color: #059669;\n transition: 0.2s;\n opacity: 0;\n top: 30px;\n}\n.card-post:hover .card-post__effect[data-v-287b4794] {\n top: -5px;\n opacity: 1;\n transform: rotate(0.25deg);\n}'
updateStyle('287b4794-0', css)
export default css
```
You can see how the above allows the Hot Module Replacement to work efficiently. When you have a module that is changed,
say the styles within a component, instead of reloading the entire component tree, only the style module needs to be replaced.
You can also imagine with the above, where Vite slows down. Imagine hundreds of HTTP requests which rely on nested HTTP requests, recursively.
Fortunately, there are optimisation to avoid this situation after the first load. The server will return a 304
Unmodified HTTP Status code for modules which haven't changed, meaning they will use the browser's cached version of the file.
Vite scales well for any app size because it only needs to request the modules for the route you're on.
## Production Builds
Since Vite is using Rollup, pre-configured, you'd expect a similar output from Vite as webpack. Vite does boast a quicker
builder and potentially a smaller artifact size, as Rollup is a more efficient bundler than webpack.
The main gotcha is that Vite can still only support ES Modules in the production build, meaning you can't have any dependencies
which don't have ES Module exports.
Vite is also pre-configured to handle your build as a universal app. A universal app is built using a client (virtual browser)
and a server (node). Allowing it to pre-render the HTML pages, so robot crawlers can fetch your page content without executing
js and speeding up the initial load for users. That means SEO friendly static sites out of the box 🎉.
## Summary
While I haven't touched on a lot of the complexities of Vite and webpack, I've tried to show you the main difference, how
bundling and no-bundling look in action.
Hopefully you've seen why Vite is promising alternative. There is so much potential in the ecosystem at the moment, watch this space, given 12-months we could see an explosion of Vite related projects.
If you want to find out more about Vite, I'd watch Evan's talk on [Vite & VitePress](https://www.youtube.com/watch?v=xXrhg26VCSc&).
## Getting started with Vite
I'd recommend just spinning up bare-bones Vite to get a feel for it. It's really easy, takes less than a minute.
```shell [bash]
npm init vite-app
```
Once you are sold, it's worth checking out [the ecosystem](https://github.com/vitejs/awesome-vite) before you build.
### Recommendations
::tip
You shouldn't be looking to replace Vue CLI or webpack with Vite for existing projects yet, but it may be valuable to check out for new smaller scoped projects.
::
The Vite ecosystem isn't that mature yet, the two main projects I'd recommend checking out are [VitePress](https://vitepress.vuejs.org/) and [Vitesse](https://github.com/antfu/vitesse).
If you are in need of a documentation site then VitePress is awesome, you can follow the VuePress documentation to fill in any gaps. VitePress abstracts away
the Vite configuration, which will be limiting for non-documentation sites.
Otherwise, I'd choose Vitesse as it's going to give you more flexible on customising your app. Vitesse offers a pre-configured `vite.config.js`, so you can easily
strip anything out you don't need to add whatever you'd like to it.
If you like my blog (VitePress + TailwindCSS), then you're more than welcome to [clone it](https://github.com/harlan-zw/harlanzw.com).
## Thanks for reading
If you like the technical side of Vue and Laravel, I'll be posting regular articles on this site. The best
way to keep up to date is by following me [@harlan_zw](https://twitter.com/harlan_zw).
---
- **Page:** Building a Vue Auto Component Importer - A Better Dev Experience
- **Source:** https://harlanzw.com/blog/vue-automatic-component-imports
- **Description:** Components magically being imported into your app is the latest developer experience trend in Vue. Why does it exist and how does it work?
When first learning Vue, you are taught you need to import and add components to `components` in the script block.
```vue
