Brief intro to the new features of Vue 3 and Vite, then focus on how those features / mindset affect the way we think of tooling and DX. Which leads to my Vitesse project and several unplugins that enhance the Vue developer experience even further (will do some short demos in between). Finally, introduce the ways to use those new features in the existing Vue 2 apps today and make the migrations easier.
New Ways to Vue
Transcription
Hello everyone, glad to be here at vue London. Today my topic is new ways to vue, how the new tools and techniques affect the way we view and build applications. My name is Anthony Fu, and I'm a vue and vite co-working member. I'm also a creator of SlideDev, Vueuse, VDesk, and other open source projects. I'm a finance open sourcer, currently working at Nuxt Labs. My GitHub handle is antfu, you can also find me on Twitter. Before I start, I want to thank all my sponsors for supporting my work. If you find my work useful, you can also sponsor me at GitHub. It would mean a lot to me. So let's talk about today's topic, new ways to vue. So let's talk about the vue two-way first. Under that, we have vue single file components. In this component, we have template tag and a script tab. In script tab, we will need to import the things we want. For example, import vue from vue, and then export the default, the components objects using vue.extend, and then we'll need to register our components, mix things, and then declare data and method. The problem here is that we are having too much Scala folding code for each components, and also the mixings are kind of limited for the extensibilities to reuse our code, and also having some problem of typescript support. To solve this, in vue three, we introduced a new set of api called a composition api. Let's do a quick comparison here. Under that, we have the options api, and on the right, we have the new composition api. As you can see, in options api, we used to have multiple properties for the object. For example, they have method, create, and so on. But in composition api, we have only single function called a setup. Lifecycle functions are now providing as hooks, so you can use it inside of our setup functions. So we have everything inside of the single context. This way, we can have a better typescript support. But other than that, most importantly, we can have a better composability. For example, we have a component with the setup functions. If we want to reuse this logic, we can simply copy over it and have it inside of new files and wrapping with the functions. In this case, we call it useDark. So then we can refactor our components to import the useDark functions and reuse it. The components will behave exactly the same as before, but we can now reuse our functions inside of other components and have better organizations of our logic. So let's talk about the script setup syntax. As you can see, even with the new composition api, we are having many scaffolding codes in our components. For example, in this case, the highlight lines are the things we actually care about, but we will need to write the rest in order to have vue understand this. In the new script setup syntax, we can have them all declare at top level. And variables, functions, components inside of the script setup are directly available inside of the components. This is initially introduced in vue 3.1 as an experimental feature and now it's stable in vue 3.2. The other new feature is the V-bind syntax inside the style tag. In the past, if we want to have dynamic styling components, we will need to first declare some reactivity data inside of the data and then we kind of bind the data inside of the template. But now with V-bind, we can have the binding inside of our style tag so we can have better organized of the templates and the style. So finally, let's talk about the new default tooling, vite. So what is vite? I bet many of you have already heard about that, but in case you don't, let's have a quick introduction. So first, we used to have bundlers like webpack and Roa. The problem of them are they are usually designed for production build first and need to bundle the entire projects in order to start the dev server. It also involves complex configurations and hard module replacements get slower as the project grows. So now we have dev servers, for example, Snowpack and vite. So in dev servers, we are designed specifically for web development. We leverage the browser's native ESM support and we don't need to bundle the code anymore. The server started immediately and we only transpiled the modules on demand. In this way, we also have instance hard module replacements and much more possibilities. So what do vue 3 and vite bring to us? Not only the better performance and the better developer experience, but also the new ways to vue. So let's have a look at how we use vue components. So first, we need to import and name it and then register the components so that we can use it in the template. So the problem here is that it makes our code quite verbose and the name of each component are repeated at least four times. Not only this slows down our development, but also renaming components becomes quite frustrating. So with the new script setup syntax, we no longer need to register the components anymore, but the thing is that the name is still repeated three times. So what if we can make it better? Introduce components auto-importing through vite plugin components. Since we already know the name of each component, we can actually directly map them to use it in the template. So how we did that? We used compile-time components resolving for components on the source slash components directory. The usage looks like the global registrations, but the difference from them is that with the auto-importing, we can provide better code splitting and we no longer need to do the manual registration. Even more, we can skip the runtime resolving to make the performance even better. Introducing components auto-importing through vite plugin components. Since we already know the file names of each component, we can actually make the binding and that's usable directly inside the templates. As you can see, that's all we need. So how does this work? So first we use compile-time components resolving for the components on the source slash components directory. The usage looks like the global components, but the difference from them is that with the auto-importing, we have better code splitting support and also there is no manual registration needed. Even more, with this approach, we can skip the runtime resolving and make the performance even better. So let's break down to see how the compilation works. If you copy over this code into our online playgrounds, sfc.vuejs.org, you can see it being compiled by the sfc compiler into the following code. Our three component usage is being compiled into this three statement. The resolve components function is an internal helper for vue to resolve the components from the current component instance. So what we can do in vite to make the auto-importing working? So we can write a very simple vite plugin here. So first we use enforce ports to ensure the plugin runs after vue's compilation. And then we use the transform hook to modify the code. In the transform hook, we filter out the files that are not vue. And finally, we replace all the resolve component usage to the real component import. If you are interested in it, you can refer to the vite documentation for more. And as a result, we remove the usage of resolve components and make them directly import. And with that, the auto-importing is working. The other thing worth mentioning is that since vite is a dev service, we can have more imagination here. So with the vite plugin in spec, you can now inspect the relationship between modules and how the module is being transformed for each plugins. This could be really useful for debugging plugins or understand how vite works internally. So one thing worth mentioning is that since vite is a dev server, we can have more imagination here. With the vite plugin in spec, you can now have a UI to inspect the intermediate state of each transformation for each modules and also the relationship between modules. This could be really useful for plugin authors to debug their plugins and also beginners to understand better of how vite works internally. So get back to auto-importing. Similar to the components auto-importing, we can even make the api auto-importing possible. By scanning the usage of each functions, we can now inject import rate from view when there is not presented. In this way, we can have our components even more clear. Let's do a quick summary of the vite ecosystem. First we have vite plugin components for components auto-importing, vite plugin auto-import for api auto-importing, vite plugin icons for on-demand icon solutions, vite plugin inspect to inspect the intermediate state of vite, vite plugin pages for Nuxt or next.js like file-based routing, vite plugin Windows css which is more like an on-demand tailwind but with much faster compilation and HMR, vite plugin Node which brings vite HMR for backend node.js app, vite plugin style imports for on-demand components style importing and much more. You can find more on the official awesome vite list. So vite has inspired many plugins and better ways to improve our developer experience. But that's not limited to vite. Let's bring them to your existing projects today. Introducing Unplugin which is one of the projects that I'm working on in Nuxt Labs. Unplugin is a universal plugin interface for webpack, vite, Rollup and more. So that you can write once for your plugins and it runs on many major tools and frameworks. So let's take a look at how Unplugin works. So on the left we have our traditional vite plugins. To make it as an Unplugin we can simply wrap in with it with create Unplugin function and then we can assess the vite plugins through Unplugin.vite, Rollup plugin with Unplugin.rollup and webpack plugin through Unplugin.webpack. So with that we can actually move many vite plugins to Unplugins. So we move vite plugin components to Unplugin view components. vite components auto import to Unplugin auto import. And during this refactoring we also made it possible for vue, react, svelte, Verlina or any framework you like. And also vite plugin icons is now Unplugin icons. With that you can take any combination of the following list to whatever you want. So what about vue 2? I guess some of you are still stuck on vue 2 due to the IE support or the code migration process. But don't worry we have got you covered. For vue 2 we provide polyfills for the code functionality. For composition api we provide at vue slash composition api package to bring the composition api back to your vue app. For square setup in the refsugar we provide Unplugin vue 2 square setup package. Note this is also an Unplugin which means it will work on vue CLI, Nuxt2 or your custom webpack setup. For vite support we have vite plugin vue 2 and Nuxt vite which bring the vite experience to your Nuxt2 apps while having the great ecosystem of Nuxt. And for developer enhancement the previous mentioned plugins are also support vue 2 out of box. To sum up this is what you could get today no matter if you are on vue 2 or 3, Nuxt2, vue CLI or vite. You can get rid of the components registrations, you can use the latest square setup syntax and also the vue composition api. We also provide some starter templates for you to grab them quickly. vite is one of the most popular vite starter templates that provide you the best vue experience. vite Nuxt that bring the vite experience on Nuxt2. We also have vite for web extensions. To try it out you can run the following command in your machine. Finally a little spoiler that Nuxt3 will have many of these features mentioned today built in directly that you can use out of box. So that's all for today. Slides can be found on my site antfu.me. Thank you.