Vue.js Live Conference

Vue.js London Live 2021

Vuetify 3: Titan

Hi, my name is John Leader. I'm the creator and author of Viewtify. And today I wanted to take a little bit of time to talk about Viewtify 3, the next version that will be releasing February of next year, and some of the different items and aspects the team has been working on as we've been moving through alpha. Some of the biggest updates that we have are in the form of the baseline creation of all of the basic components for the framework are in. We have lots of new design concepts normalized in their terminology so that they're more semantic and easier to work with. We have additional interfaces that allow you to interact with the components in more intuitive ways that allow you to have more consistent results. And we've also been working a lot on the actual usability of the various parts of the framework from making it easier to manipulate and work with custom styling, as well as how that gets implemented into your project. And some of the new browser features that we get to take advantage of as we move away from the Internet Explorer 11 platform. So some of the changes and improvements that we have coming from components. Stated at the beginning, the basic components for the framework are all complete. These are components that form the foundation for larger implementations, things like alerts and banners, ratings, as well as around 42 other basic components that from buttons to chips, avatars that we use to create and build some of the more complex composition components. We've added a lot of new interfaces for how you can work with these different components, things that simplify the way that you are able to interact and make different design choices and changes within those components. We've also added some additional utility classes to help you, in addition to modifying components based upon their normal prop structures, but also being able to make additional changes through the help of utility classes for text and color and different transforms and whatnot. One of the things that we've recently got in the framework that the team has been working on is the form elements in our validation systems. We have a new validation system that is now expanded as an available inline provider, as we call them, that allows you to not only implement any type of component or element as a validatable item to an extent, but we've also added new functionality for how you can perform validation, including asynchronous calls in addition to the already existing version 2 functionality that's available today. This validation system is built in to the new form components in addition to being available inline, as displayed here on the right, where we can now take something that was previously kind of hard-coded into inputs and now is something that is flexible and can be used in multiple places. We've also worked a lot on improving the style diversity of input components with a new concept that is in material design called density. I'll talk a little bit more about that later. In addition to a lot of these new features and functionalities, we still have ported over all of the existing version 2 styling that's in addition to the new available options for density that we've created. One of the cool things that we've recently implemented were an animation positioning system for how our menus and our dialogues are what we typically call detachable components, how those operate. And one of the new things that we have that is applied to the way that menus and dialogues animate whenever their activator is clicked is a transform that is based upon the activator's location. So as you can see in the animation here, whenever we open up the dialogue as opposed to it being an element that just animates from the center of the screen, we're actually now transforming these detachable elements from their original activator location to really improve the visual feel of the actual functionality, but also to improve the performance and how smooth it is whenever you're working with these components so that there is crisp animation, there's no jitteriness, and this is one of my more favorite parts of the new version with all of the way that menus as well work and how they position on the screen. We have a lot more functionality that allows the user to make some really nice aesthetic designs and decisions within their application and just giving the user more options overall. We have some normalized concepts that I like to call semantic customization options that we have began to kind of normalize or pull together multiple different design aspects within PewDefy and try to put them under a particular category or similar options between multiple components so that when you're working across the framework, you'll have different components that you're working with, but they'll still be based upon the same kind of interface that you're working with with multiple different components. And kind of what I mean by that is we have a new concept called variance. And what this is, it's a way for us to take some of our mutually designed exclusive properties and functionality within version 2 and kind of put it behind a naming convention so that we can reuse this throughout and actually expand the functionality that is used or available, excuse me, for multiple different components, an example being the file available that exists primarily in the card-based components are contained, contained text, text, outline, and plane. And these different design styles are represented in version 2, but they're not represented behind any specific naming convention. So what we've kind of done is to homogenize this functionality, we've made it so that it is reusable throughout any card-esque component, alerts, sheets, banners, list items, that give you some additional control over not only the visual aspect of the component, but kind of I stated before, homogenizing, making this similar throughout multiple different implementations so that we can have similar and same functionality for multiple components that didn't even have the ability to implement these styles in version 2. One of the other things that we have implemented conceptually is the density from material design, and what density is, is a declaration of how high or vertically how much a component takes up space-wise, whereas size is it modifies components padding, modifies font size, and in general takes up potentially a larger space on x-axis, whereas density, we're just kind of reducing the height. So what we've done here is we've added the ability to combine multiple different aspects of sizing that's available in the framework. Version 2, right now, we have regular sizing for extra small, small, default, large, extra large. With the introduction of density for version 3, we've taken some components that you may have worked with that had a dense property. It's now been kind of split into two, which those are now compact and comfortable. And these are essentially iterations of a certain pixels, four pixels to be exact, that reduces in scales so that a button or an input will maintain the same visual look, however, it will take up physically less vertical space. And then for components that support both size and density, these actually work together. So you can do things such as having an extra large compact button, if you so choose. And what this does is it gives a lot more options for the user to be able to build their application so that you don't have to have such a blocky design or something that takes up a lot of space on the page. You have the ability now where you can globally change in the framework all components that support density to a more compact style. And these are some of the interesting ways that you can interact with these components like button and inputs list item. We've worked a lot on the interfaces for working with components to give users the ability to solve their problems in different ways. So right now in version 2, most of the components that have what I'd like to call textual interface properties, things as you can see on the slide for properties defining, title, subtitle, text, this exists on some components, but it was never synced in a way that was similar across the framework. So now you're going to have the ability to customize components in three ways for in most situations. We'll have the default approach, which are elements. This is pretty much what Vue Define 2 is now. In some cases, very verbose to get to a specific styling, which is required by the structure. For example, if you want to have the card text styling in a card, you have to have a vCardText component. So what we've done is we've kept that as a baseline, but then we went ahead and said, okay, we're going to add some props. We're going to say, you know, you can specify any one of these particular textual interface properties, title, text, subtitle, the ability to set avatars or icons, commonly used and requested features that usually the user kind of has to manually apply themselves. Instead, giving a baseline that is not super flexible in some ways, but is flexible in others. So if you want to just apply some text to a card with title, you can do that with a prop, or you could do it with a slot, where it gives you the same markup that you would write normally by default with elements, but also you can make additional changes inside of it. So just kind of giving you some flexibility for how you can approach your problems, and you can actually mix and match these together and come up with a unique design implementation of your own. So we have some usability improvements, quality of life changes, things that improve not only either the developer experience, but how we interact, how we and other users interact with the framework as a whole from that perspective. Version 2, we still use SAS, but we use the import approach towards implementation. We've converted our SAS for Vuetify into what are called modules. This is to coincide with new updates to the Vuetify loader and our new Vite plugin, which is available now. And what the purpose of this was is to create a more easy-to-use interface for SAS, but to also resolve issues that we were having with prepinned data and polluting the global variables within SAS. It's also given us the ability to do some pretty cool things, like with the new Vite plugin, you can expose the ability to modify any and all styles, just as you would with version 2. But anything that's not modified and such actually has a pre-compiled CSS file specifically for either that component or functionality that will be used instead of recompiling, which gives drastically faster compilation times. And not only is it considerably faster to work with a Vuetify implementation where you are customizing the variables and you're customizing SAS that's compiled during dev time, now not only is that faster, because for components that aren't being used for variables, we already have that pre-compiled, but also we're hooking into Vite, which has kind of been a lot of the team's focus as of late for development process. We've been able to take advantage of some evergreen features from browsers, such as focus within and CSS variables. Working with a button, for example, now provides different visual cues based upon how your interaction occurs with that element. So if you're clicking on a button, chances are you're aware of the location of that button, and we don't need it to provide an outline whenever we click on it. However, if you are tabbing through your application, it's not as obvious whenever a button slightly dims in its opacity. So now we have some new functionality with the advanced browser support to be able to have a distinct visual display based upon how an element is interacted with. In regards to the CSS variables, these existed in version 2. They're now first-class citizens of version 3. They're used heavily throughout the framework and are now kind of the baseline for allowing our customization options within the framework to expand that out and make it not only easier to modify, but giving you more options to change during those modifications. And so right now, the team is heavily working on the alpha. We have been making really great progress. And as of right now, we are set to deliver Vue to 5.3 in February of next year. We really are excited about a lot of the new features that are coming to the framework, and we're really excited for you to get to check it out and take a look. You can check out the alpha right now if you go to next.vue5js.com. And you can also follow our releases on the GitHub releases board or even communicate and reach out to the dev team on Discord at community.vue5js.com. My name is John Leader, and this has been kind of an update on Vue to 5.3. Thank you. ♪♪♪


John Leider

Options API vs Composition API: Choosing the Right Approach for Your Team

Ben Hong

Modern State Management with Vue 3

Hi, now we are going to talk about modern state management with VUE 3. Hi, I'm Vanessa, you can find me online as Wanzel. I'm responsible for the frontend at SEVI. I'm co-host of two different podcasts, Expect Exception, where we talk about frontend testing and Working Draft, a German podcast about web development. And roughly a year ago, in September 2020, I can remember as I sat there watching Avenue on the VUE.js conference, finally saying, hey, VUE 3 is out there. And now I want you to go with me on the journey, how I installed VUE 3 and used alternative concepts to use VUE 3 completely without Options API and also without VUEx. I do not suggest that you should use VUE 3 without Options API or replace VUEx. I want to tell you that the Composition API is so powerful that we actually can use VUE without both of those tools. And it made sense for me in a state where I had a really small application, which I started with VUE 3 from scratch and did not have to migrate from a VUE 2 application. In the code examples I will show in the next couple of minutes, I will use the setup function. And I prefer to use ref over reactive. But everything I will show now, you of course can use the script setup syntactic sugar instead. And you can choose to use reactive instead of ref if you prefer to. And as my components of my very small VUE 3 application roughly a year ago started to grow because I had some more complex problems which needed some more complex solutions, I and therefore also this talk were mainly inspired by those three articles. Group extract share pattern, state management with Composition API, and should you use Composition API as a replacement for VUEx. Let's focus on three of the VUE's APIs for now. The options API, reactivity API, and composition API. The options API, we can think of this object structure that we know from VUE 2 single file applications, single file components, where we have our data, computed methods, watch mounted and many more. And the reactivity API is not that different of that. We have ref reactive for reactive data computed, watch, watch effect, unmounted, and many more. But the clue is that I can now import those functions directly from VUE. I don't have to use a VUE single file component or a mixin to use those tools. I can import them in any JavaScript or TypeScript file. And then the composition API is providing us with a setup function where I can bring all the magic together and use all of those powerful tools of the reactivity API in my VUE component. So let's have a recap of how to write a component in VUE 2 or in VUE 3 using the options. Here I have a template with a paragraph with greeting and full name. If I scroll down to my script block, I can see here that I have a data function, which is returning an object with greeting and hello. I have properties for first name and last name. And I have a computed property for the full name, which is returning me a first name with a space and the last name. So this is one component with just one purpose, which is doing its job quite well. Kind of a funny side note is that I initialized this greeting here as a reactive data attribute, although I actually don't ever change this and won't need this observers on it anyway. But I was never sure where to put this constants using the options API. The problem I now want to focus on is that logical units, if the component is growing and growing, are spread over the whole script block. So what do I mean with this? I've prepared this code sandbox here. And here we can see as well, we have our greeting and full name to say hello to the user. But then we also display the user's items where we loop over and also provide a delete item function to delete something. If I scroll down to the script block, I now want you to focus on the order of how things are happening. I have the data function, which is running an object with the greeting and items. The properties having stuff from the greeting, a computed property with the full name of the greeting, then a method with the function delete item of the items. So the categories bind to the way that the view skeleton, the view object here is structured. So everything in data is in data. Every computed property is in computed property. Every function is in the methods block. So now we have a point where we have now greeting items, greeting, greeting, greeting. So they are shattered over the whole file. And this is kind of grows and grows and grows looking like this. Of course, it can be a solution to split the component, but let's focus on it doesn't work anymore. We can't split any further and we still have this lines of code not really bind together. And what the composition API is providing us with is the possibility to group logical units together again so that everything is related to the greeting. We can imagine being in this light blue box on the top and everything related to the items, we can imagine to be bind together in this darkish blue, almost black box here. So the composition API enables developers to encapsulate logical units in one single file or in shared with others. What I mean with that, as I learned about the composition API a year ago, it always was sold to me as this is the go-to thing instead of mixing. Use the composition API to share functionality. It's really powerful. But then I started with Vue 3. I thought, but do I really need to share logic to use the composition API? Because I really like how it works, the composition API. And I actually like to use it also without sharing functionality. And this is exactly what we will do now. So I have created some Hello World files on this Vue single file component playground. And the first one is a reimplementation of just the greeting stuff we saw beforehand in Vue 3 composition API. So here we have our template with the greeting and full name. And we import computed from Vue. If I scroll down to the properties, I see the first name and the last name. And here below, I have the setup function, which is giving me a const greeting with hello and a full name as a computed property. And then I return everything to give it over to my template. What is kind of cool is that it's just JavaScript, right? It feels good to me. Actually, it felt a bit sweat the first time I saw it. So here we have the const greeting as just a pure const without wrapping it in a data object, not using a created lifecycle hook to initialize constance, just a const. And when we have a full name as computed property. But of course, also here, the functionality can grow a bit. We are switching to our Hello World 2 component, where I have also my items, which I also can delete. I loop over them in the template. And I have my method to delete them. I import computed and ref now from you. And if I now scroll down to the setup block, what we can see is the same implementation for greeting with a greeting and full name, and then a logical unit of the items and a method to delete the items. And as I started with U3, all of the time, my muscle memory was like, oh, yeah, I have to put everything data related in the beginning and then all of the computed properties and then all of the methods and then all of the lifecycle hooks until I remembered, no, no, I don't have to use this anymore. I can now bind the logical units. I can display them together. But then, of course, my component was growing a bit. And I was like, yeah, how do I actually say that these things belong together? Do we have a comment like start items block and items block? How do I achieve this? So I started to refactor this component a bit. The same template we saw before, but now on top, we have two different functions, the use greeting and the use items, which encapsulate all of the functionality in those function where I have everything related here and return the necessary properties to the outside. And if I scroll down to the setup block, I can now see that it's getting a bit more cleaner if it was getting a bit nasty. And I can outsource all of this logic to somewhere else. And here, I can clearly see, OK, I have the greeting and full name items and delete items coming from those two composables. But now the next step is, hey, it would be super amazing if I can use the use items also somewhere else because I really need this functionality also at another component, which leads us to Hello World 4, which is also refactoring a bit further. I only import computed now again from Vue and not ref anymore. But now I also import use items from use items. Switching to this file, I can see import ref from Vue on top in a plain JavaScript file. And the same function with the use items we saw just before is now an exported function in this file, bringing us all of the functionality as a composable in our Vue single file component. If I scroll down to the setup block, I can see here again I have my use greeting and the use item. I want to give you a small hint what I'm doing here. So what you can see here is that I first thought it is super cool to use ECMAScript destructuring to get everything related to the use items directly into the template. This is just one line of code. This looks super cool. But then a problem that occurred to me is that I don't have any IDE support here on this playground. So if I try to look for the delete item, I'm lost. I don't know where it's coming from. And therefore, what I tend to do is really to go the explicit way, to not use magic provided by a language by me, but really saying explicitly, OK, I import those things from there. And now I can see, OK, the delete item is coming from the use items, and the use items is coming from this file. So we already wrote our first composables. If you are looking for a bit more inspiration, check out this Vue Use Git repository where you can find already a lot of in TypeScript pre-written composables that you can use, Axios functions, and so on and so forth. I think it's also already Hektoberfest time. So also if you want to get engaged in open source, this could be a start point for you. OK, but now let's focus on state management. So how did I thought state was working when I started with Vue 2 in 2017 or something like that? First, I did the anti-pattern of props drilling. So I used props emit event handling to get something from a root component to its really like grand, grand, grand, grand, grand, grand, grand children to just emit, emit, emit, emit everything up again. This was not really maintainable. Then I thought I'm smart and I used the global root, the dollar root, to attach variables to this global root thing until I realized this is not working. This is not really reactive. I think I should really not use this. It was also not really discussed. It was just really hidden in the API documentation that there is something like a global root. And then I sat down and thought, OK, state management sounds important, sounds difficult, store sounds difficult, observables, VueX, I'm not sure, but I will install VueX now. And it was really just mind-blowing how simple this made it for me to create state management by only creating this index.js file. And already I had some state. It was a really powerful tool because it was so simple to use to then focus on the complex parts of writing code or finding solutions for bigger problems. But when I was starting with Vue 3, I thought, hey, give me a second. I think I can do achieve state management actually with composable. And it was really like, it was not because VueX wasn't ready for Vue 3 yet. They were pretty quick and there was a migration guide. But I was interested in what is everything I can actually achieve with composables. I want to get a step further here. And here I have another code sandbox, which will probably load soon. But I think I also have it preloaded here. Yes, I do. So here I want to focus first on the cart items, which we see here. And now I have a bit more of a realistic example. So if I reload this, you can see that there will actually be like three seconds of a loading time because usually I fetch the items from a server. So I have three seconds of loading. And then I see the items. And here I have a first item. So what I have to buy next are the eggs. And then I have my list of items. And here I really use now a state with if loading where I can set a loading state if it's still loading. And in the script part, I additionally use now the unmounted hook where I can fetch the data. So going to the setup function, we can now see the state with the items and the loading. And then I have the important function here are the load items where I set the if loading to true. Since I don't actually have a real endpoint that I can talk to, I use a use sleep function for three seconds. And then I set some dummy items, my eggs and my milk. And if everything works out, I can set if loading to false again. I also have my method to delete the item. And I have a computed property for the first item. And I use the unmounted lifecycle hook to load the items as soon as my component has mounted. OK, so far so good. We have something looking like a state, but it doesn't really feel like state management right away. So now I want to go to the app root component and switch to a different alternative of this application and use now two different components which are both providing us our items. So if I save this and reload, in the meanwhile, I will go to the cart items alternative, which is looking pretty similar to the favorites. So they are both just showing our items. So on the cart items alternative, I scroll down. And instead of the whole logic we saw beforehand, I can now see that I import the use items composable. And I get all of the necessary data from the state, load items, first item, delete item. And unmounted, I call the load items function. Now I can see here my three seconds loading. And I can see two times my list for my items. And here I want you to focus on the local state management. If I open the file, which I thought I had opened before, but I do it again for this composable, I can now see that the state here is outside of the component of this export function. And the rest of the implementation is the same one as before. It's just copied over with one important difference. So here I import additionally the read only keyword by view to have this store like of feeling of this composable, to have the single source of truth what we expect how a store should behave like. And now I want to put the state inside of this exported function. And if I'm doing this and wait for it to reload here, come on. And they are loading for three seconds. And I have my X, which I can delete in those local state. And here below, I can delete the fresh milk on those local state management as both the card items alternative and the favorites are both using this use items, which has the state initialized inside of this function. But if you think, hey, this is kind of weird, this is not what I expect from state management. I expect it to be global. This is achieved by just moving the state on top of the export. And I will reload this again. And then you can see that, therefore, I just created the state now once. It's no global. It doesn't change. We don't initialize it a couple of times. We just export this function a couple of times. So after I installed all of those dependencies, you will see that I can now delete the X and they will be deleted twice. So they are loading. And global state management. And the next point, if you think, hey, this is not looking like I would expect like a store really to look like, you can also use an alternative to this alternative. You can use the provide and checked pattern, which was already given to us at view two. And this is this code sandbox where I start with the app.vue root component. And you can see here that I import a store and I import a hello world. And I register the component hello world and I provide the store. What is the store? Let's have a look at the store at the index.js file here. So in here I have computed ref and read only where I have my state, a first item, a computed property, which is looking like a getter. And then I have functions that looks like a setter. And just out of fun, I called them set items in this uppercase syntax. And then I export for the state, which is read only my getters and my setters. So this should feel more like the view X way, the store way of doing things. And if I check out my components, I can go to hello world where I actually don't have any knowledge of the store at all, but I registered the child one. And in the child one, I import and checked from view, scroll down here and I in check the store and I can use the store in this child component using provide and check pattern and delete my data and my items here because I finally bought them. And this is also a global state management. So if I would inject the store in some other component, it would still work. So that's everything about the state management in view free using composables. Thank you very much. See you later.


Vanessa Otto

JSNation Live

JSNation Live 2020

Composition API: a Quick overVue

Hi everyone! Today we are going to speak about one important feature Vue 3 will bring, which is a composition API. But before we start speaking about it, I want to give you an important warning. When we first introduced this new API, we made a huge mistake. We were speaking about deprecating some options from the old API, and people understood it slightly differently than we want. You can see some quotes from Reddit saying like, do I need to rewrite all my components to the new syntax? And I want to say no, please don't be like this. The new composition API is purely additive. You won't need to rewrite all your good components written with options API to this new syntax. And after this warning, now I'm safe and I can introduce myself. My name is Natalia and I'm Vue.js core team member. I care mostly about Vue documentation. I work as a staff frontend engineer at GitLab, and I'm also a Google Developer Expert in web technologies. So why do we need this new API? Is there anything we were really lacking in the Vue version 2? Let's take a look at this small application, please meet cat explorer, an app to search and sort cat breeds. As you can see, we have two features here. First is searching, second is sorting, but different parameters. In the application code, this will look like this. So this code belongs to search. We have some part of the reactive state responsible for searching, and we have a method to run this search. And of course, we have something for sorting. Again, we have some reactive data and we have some computed properties to calculate these sorted results. If we take a look at the component code, we will see how these two features are divided in it. So here is a code that belongs to search, and here is a code for sorting. And as you can see, the logic is pretty much fragmented here. Imagine I'm a developer who needs to fix the search, and I need to follow this logic, and I will be jumping from data to method and vice versa. So do we have a way to compose these reusable features and abstract them somehow? So the first option in the current API are mixins. Mixin is an object that can contain any set of component properties like data, methods, computed lifecycle hooks. And when mixin is included into the component, these properties are mixed in with component properties. Sometimes, component can override mixin properties if there is a name collision. Sometimes, they are merged together like in the case of lifecycle hooks. But basically, you need to understand this is just mixin in properties from mixin to the component. So here is a mixin for the search, and here is a sort in mixin that includes the data. This includes only properties we need for sorting. And if we take a look at this, this is way less fragmented, right? And we just include this mixin to the component at the bottom. But there are some problems about mixins. First of all, they're not really reusable. If you did pay attention to the search mixin, you saw this access call. So we are not able to customize our search. We will always use the same endpoint because this is defined in the mixin. We cannot pass even the endpoint there. Not speaking about replacing axios with some kind of graphql calls. Conflict prone. As I mentioned, mixin properties could be overridden by component ones. In this case, we can't be sure that everything we exposed from the mixin safely landed in the component. And unclear source. If you ever used mixins, you know how hard it is to track which method comes from which mixin, especially if you have multiple ones in the component. We have another option, which is scope slots. I won't go into deep details, but basically in Vue, component can have slots. And we can place anything in this slot, like text, HTML, other components, and all this content will belong to parent scope. When we speak about scoped slots, we mean that child component, in this case, it's generic search, can expose a part of its scope, like data, methods, whatever we want, to the content in the slot. So you can think about component with a scoped slot, like a component that contains some logic, not a template in this case, like a wrapper that performs some operations and exposes data and methods to its content. Looks much better, because as you can see, we can pass run breed search there, so we're not setting it up to static access call, but this is not flexible. Most of all, data and methods that are exposed to the scoped slot are exposed only to the scoped slot. We cannot reuse any kind of exposed data in other places in the template or in the options API or whatever else outside of the slot. And this is less performant, because in this case, generic search is still a Vue component. This is a Vue instance, and you need to mount this Vue instance to make it work. So do we have any other options? In Vue 3, yes. This is a new composition API, and I want to show you how does it work and how we can abstract these two features into the composition API. That's why we're switching to live demo. Wish me some luck. So here is a code for the search and sorting, and let's start with abstracting search to its own composable. Let's go to composables folder and create a new file named search.js, and we want to export a function from here. Let's name it useSearch. And let's take a look what do we have for search. First of all, we have two of these reactive properties, which are query and results, and we want to abstract them completely from this component. So let's create our first reactive property called searchQuery, and this will be a ref of an empty string. Empty string is an initial value of this search query here, and what ref does under the hood? In fact, we are creating a search query, which will be equal to an object with value of an empty string, and this object is reactive thanks to ref. So any changes to search query value will be reactive. We need also to create a searchResults query, which is a ref of an empty array. And of course, we need some method. Let's call it runBreedSearch, and this is a function. And what do we want to do here? So we want to pass something to run because we don't want to make this access call static, we want to abstract the logic. So this code will accept some function, let's say getResults, and it will call getResults, and we want to have our query as a parameter here. But remember, this is a ref, so when we are referring to the ref inside of the composition function, we need to remember about value. And then we have some response, and we want to set searchResults value to this response. What else do we have for search? We abstracted runBreedSearch, oh, we have mounted. So we want to run breedSearch in mounted hook. This can be also abstracted here, and we want to run runBreedSearch. That's basically it. Now we need to return whatever we want to use in the component from the composition function. So we are returning searchQuery and searchResults in this case, and of course, we need to return runBreedSearch. Now we can start using this in the component. First, obviously, we need to import our useSearch from the composables. And now we're introducing a new option in the component, which is setup. In terms of lifecycle hooks, setup will be involved before created hook, and we can access the things returned from the setup in both templates and options API, so here. But we can't refer to data properties or compute it in the setup, because when setup is running, we don't have data or compute it. So let's use our useSearch method here. I want to have searchQuery, searchResults, and runBreedSearch here. And I need to pass a method here, like a callback. So this callback will accept a query parameter. We're passing it here from searchQuery value. And we need to recalculate endpoint. We cannot refer to this compute, because setup is running before compute.exist. So I will simply calculate it based on query. And then I want to run my access call. Here I will simply use an endpoint I've just defined. Here we should use our best query from searchQuery value. And in the response, I just want to filter data, because saving logic will go to the composable. Now I can get rid of breedSearch, breedEndpoint, and the whole methods and mounted section. And I need to fix my template slightly. So this should be fine. And we also have these breedSearch results. This will be replaced with the search results. Important moment, you can see I'm not using searchResults value here, as well as I'm not using searchQuery value here. Because when you use anything returned from the setup in the template or Options API, ref will be automatically unwrapped for you. You don't need to care about value in the template. So let's take a look at our application. And this all happened because I simply forgot to return everything from the setup. And trust me, I do this every single time. And I believe this is one of the cons of the new API, because you need to explicitly return everything from the setup option. Here we go. And now, as you can see, we have our cats. Let's try to see if search works. It does. We didn't break sorting. No, we didn't. So great, search is abstracted. Now let's try to work on sorting. I will create one more file. In fact, you can store all your composables in one file, but I just want to make it more visible. And I want to export function, use sorting here. So what do we need for sorting? Let's try to take a look. First of all, we have options, and I don't want to hard-code them to sorting. I just want to pass them there. We have a reactive property for selected option, and this makes sense to be abstracted, because this is an internal logic of sorting. And we have results. Obviously, results should be in sorting as well. But as you can see, we are sorting some items, and I don't want these items to be hard-coded. Again, I just want to pass them to sorting. So we want to have our options and items. And we need to create selected option index, which is a reactive property with a default value of zero. And we need our sorted results. As you can see, sorted results are computed property, which means they will be recalculated if their reactive dependency change. We can use computed in a composition API as well. We just need to import them from the view. And in this case, computed will accept a callback. I will copy-paste the logic from here and fix it slightly. We don't have result sorting, we just have options. We have our selected option index value. Don't forget this is a ref. And here we will use our items. Here is a trick. I know I will pass a computed property as items here, and computed is a ref internally. So here I will need to use items value. And I need to return everything I want from date sorting. So selected option index and sorted result. Oh, got sorted results. Now let's go back and try to change our component as well. First of all, I want to abstract options to a small constant. Let's call it sorting options. And I need to return these options from the setup as well, because I will use them in the template. Now let's import our use sorting from our composables. And let's create more constants here. So we will have selected option index and sorted results from use search. And I will just move a constant declaration a bit higher, because I will need it in my use sorting. So first parameter is sorting options. And second, as I already mentioned, is computed, because I need to track any changes in my search results. And when they change, I want to recalculate this computed. In this case, I will return search results value. Remember, search results is a ref itself. And I want to return selected option index as well as sorted results from my setup option. I can remove data now as well as computed. And I need to change my template as well. So here I will have sorting. Oh, God. Sorry, I'm really bad when I'm typing something when do live coding. And here we will have selected option index. So let's take a look at the application again. Oh, of course, order by is not defined, because I forgot to move this part of the logic from the template to the composable. And right now we fixed it. Sorting works. Search works. Great. Just a few mistakes during the live coding, and we are here. So basically, we just learned we can use Composition API independently. I've written the whole component or in the combination with the old good options API as well. If you want to learn a bit more about the Composition API, please follow this link or just Google for Composition API RFC. There is the most full source of information about the Composition API so far. And I also created this small repository you can play with. Please target view three branches. There is a branch with a starting code and with a finished code as well. And thank you. Hey, Natalia. Thanks for joining us and for this really clear talk. First comment. I actually got a message while you were speaking from a colleague of mine. Hey, Dean, how are you doing? That he was thought it's such a relaxed voice and that really helped him follow along. So he was in the moment with you. So this is a given. So I don't know if you can thank you for it. But yeah, he liked it. So so did I, by the way. I want to remind everyone that if I don't have time to answer your question or ask questions to Natalia, Natalia will go to a Zoom room where you can continue the discussion about the composition API or anything else future related with Natalia. And the link is below the player on the website. In the timeline, you can just click on her Zoom room. Let's go to the first question. And it's an easy one. It's from Amir. It could by the way, which font are you using? It looks so nice to me. It's Dan Kmola font used together with night all theme for VS code. Ah, nice. Dan Kmola. That's from the guy from Formidable, right? It's a free font. Yeah, nice. No, this is not. Unfortunately, it's not. Oh, well, maybe you have to sometimes pay money to use nice stuff. That's weird. Next question is from Jan. When do you recommend not to use composition? No, as a part of the team that developed composition API, it's very tempting to say just use it everywhere. But in fact, if you first of all, do not have features to abstract and reuse. And second, if you have a team that already get used to the option API, there is no reason to jump immediately and rewrite everything to composition API. You can evaluate features that need to be reused. And then you can iteratively add them with a composition API. So there's no like a law when to do it. You can always, but it depends on the project, basically. Yeah. Okay. Next question is from Ibrahim Bekliyev. Which problems does new composition API solve exactly? If I got it right, it helps to combine logical one thing and place it in one place like what React the React team did when they introduced the React hooks and give opportunity to create custom hooks, use search, use sort, et cetera. Yes, you basically get it right. Unfortunately, in Vue 2, we lacked a tool to reuse logic, not components. As I mentioned, we could have mixins or scope slot, but still it was very synthetic thing. And also composition API is very helpful in the case of writing Vue plugins for Vue 3. Because currently, if you're author of the library, you would need to work with a Vue instance and extend the Vue prototype. With composition API, it's much easier to do so because you can just simply export functions you created in the plugin and use provide inject within the Vue instance. So basically it's feature reuse and plugin development. Okay. Well, I hope that gives Ibrahim the complete answer he's looking for. Else he can find you in the Zoom room. Next question is from O. Beresford. Is there a guess on when the Vue 3 will be out of beta status? I use Vue 2 and I've been pulling out extra slash non-Vue code via traditional means via SRP for SRP. As you probably understand, I have no allowance to say a certain date, even though we have it in mind. But release candidate is coming very soon. Like really very soon. You will be surprised how soon it is. So can I set an alarm now? Will it make the weekend? Give us a glimpse, Natalia. No way. No way. Oh, damn it. Okay. Well, good that you're tough on us. Next question is from Poltermouse30. What advantages does the composition I, sorry, what advantages does the composition API offer against React hooks? Honestly, it's a bit complex to answer because the question is like what advantages Vue offers over React basically because they solve similar tasks but different frameworks. So basically if you work with React for simplicity, you can consider composition API being kind of hooks for Vue. But the only thing is like someone mentioned custom hooks, like all composition APIs are custom. We don't have built in composition APIs. Yeah, okay. So it's apples and oranges. Kind of. Then closer to each other even. Okay. Another question from Andrew Green H. How do you decide which arguments for your custom composition functions are supposed to be refs and which should be plain values? Basically if you need reactive value, this should be always ref. You probably noticed that I'm passing options that is static because I didn't plan to change these options in my application. This is just a constant. And this shouldn't be a ref or reactive. If you plan to react on the change of this parameter, this should be always a ref or computed like I did passing a parameter to the sorting option. If we speak about comparison with Vue 2, you can think that non-reactive values, if you pass them as non-reactive, this is something like dollar sign options. If you want something reactive like from data or computed, this should always be ref or computed. Okay. I think that's all the time we have for the live Q&A. But I'll just mention once again, if you want to know more about the composition API, please go to the Zoom room. It's in the link. The link is in the timetable below us in the player. There's a timeline below. So there's a new question coming in right now. And we're not going to answer it. So Sui will have to go to the Zoom room, unfortunately. And we're going to go to the next speaker. Natalia, thanks a lot for joining us all the way from Ukraine here in Amsterdam, kind of. Thank you. Thanks a lot for being here.


Natalia Tepluhina

#vue composition api