The Swiss Army Knife of Every Vue Developer

Welcome to this lightning talk, the Swiss Army knife of every Vue.js developer. My name is Juan Andres Nunez, I'm a frontend engineer and also a content creator in my spare time at my platform, squalavue.es.

Let's go straight to the point. What is the Swiss Army knife of every Vue.js developer? This is a bold affirmation, right? Well, in my opinion, composables are. Why? For many reasons that we will explore in this presentation, but there are two why's first. The first one is why you should learn this pattern, right? Or why you should give me your attention during the seven, eight or nine minutes. And this is a fair point, I understand. So let's make a deal. This is the promise. If you give me your attention, your full attention, I promise you that this pattern will help you build more extensible, adaptable, controllable and trustful Vue.js applications.

But let's go to the what first, right? Because maybe you are not involved in this composable thing. You're not aware of what it is. Well, a composable is a JavaScript function that uses composition API. By the way, this is the official Vue.js documentation to encapsulate and reuse stateful logic. Three key points here, super important. Composition API. You have to use composition API. There is no other way around it. Stateful logic, you have to have some kind of piece of state that will be mutated, right? And you want to be notified. You want to react to that. If you don't have a state, you probably don't need composition API and you probably are not working with a composable. Maybe it's a typical utility function, but not a composable, in my opinion, of course. So this is the most bare bones implementation of a composable that I can think of. We are importing the reactivity APIs from Vue. We are exporting a function, in this case, useAlert. We are doing our thing inside. We will come later to this stateless, stateful composable and we return something. We have full power to return what we really want to return. But let's go forward. Three last key points about the what.

The convention is to start with use, useAlert, use whatever. They are not the same as mixins. They overlap. That is true, but they overcome, they replace completely mixins. So if you are super used to mixins and start using the composable, you won't miss the mixins, believe me.

Let's be honest. You don't even need Vue 3 to start using this composable thing. From Vue 2.7, you can use composable, so there is no excuse.

So when? When should you start using this pattern? When I think on composables, I think of bridges, but this is not the typical bridge, right? This is a reactive one. What it means is that you can decouple reactivity from the components and start using elsewhere. And this is if you're super used to Vue 2 and options API, this is a mental shift that is easy to do. But in the beginning, this is somewhat strange. So if you need to connect different parts of the system, well, I can use a composable.

Some use cases, state stores. Of course, you want to share some kind of common state between different components or different parts of the system and have centralized, of course. Controllers that are more or less the same as a state store. But when I think of a controller, it is maybe the gateway to a feature. We do some polling to backend, we transform the data, maybe we serve some computer properties. This for me is a controller and it's a perfect candidate for a composable. And also reactive UI utilities. The key here is reactive. If you don't have reactivity, you don't have a composable. And of course, any other creative use of this pattern. The last slide, we will mention Vue use. That for me is the most creative usage of this composable pattern. But this is four examples. Where? Well, everywhere. This is a video from one of our main projects and we started slow, but then something clicked. And we started using it when they fit. Of course, you cannot throw a composable at whatever situation.

But they are super versatile. So everywhere. Because, okay, Vue, it's a UI concept. Right? So this composable is a UI concept. Well, it doesn't have to be that way. Because it can be in the domain layer. It can be in the UI. Of course, what I mean is they are omnipresent. It breaks that boundary. Right? So it can be local to a feature, global to a system, or anything in between, really. So that's where.

And why? Let me recover the promise. This decomposable pattern will help you build four things. Extensible, adaptable, controllable, and trustful. So let me keep my word. Right? Extensible. Why? Because you want or you can start small and grow with the project. And it can be stateless or stateful. When I say stateless I don't mean that this composable doesn't have a state. It won't be a composable. But the state in this case is inside the exposed function. So every time we create a new implementation of this composable, we will recreate this state. It will be private to that implementation. But simply moving this state outside the function, this is common for all implementations. This is extremely easy to understand, but super powerful. And Options pattern. This is not a composable concept. This is a JavaScript concept. But if you want to stop abusing this argument pattern, you can create an object. You can have some nice defaults.

And this is a common, super common practice in the composable world. Again, super easy to understand. Composition. It's the same as a view component. When it's too big, you want to start extracting to different sub-components or other components. The same with composables.

It's a common practice to use another composable inside your composable doing that composition. In this case, local storage, et cetera. So this is extensible. That's the first part of the promise.

Second one. Adaptability. They are adaptable because they fit in every app layer and work in every environment that you throw in. That word doesn't mean that this is the correct option, but they work. They're super versatile. For instance, domain business logic, check. Native APIs, check. Data modeling, check. And I can continue forever, to be honest, but super adaptable.

Controllable. The third point. Decide what to expose. We saw this in the beginning because you can return whatever you need then. So you can keep private, quote, some part of the composable and expose only what you need to consume outside. But you can do more. If you have to expose that piece of state or whatever, a computer property, a reactive object, doesn't matter, you can make this nice re-auth only API from Vue. And easier aliasing. Of course, this is JavaScript, right? So you can change the name alias when you are using or importing or when you are exposing. Super easy, but super powerful at the same time.

And the last part, the fourth part of the promise, they are trustful because they are easy to test and easier to maintain.

Why? Because you don't have to mount that Vue component or stuff or mock some dependencies. Of course, you don't use it inside your composable, but if you keep them as trust as possible, it's a lot easier to test because you can test only the composable, not the environment where the composable lives. And this is, again, super powerful.

I hope that at this point, you are solved on this concept. And if you never used this composable thing, this is the best way or the best moment also to start using them.

Some last considerations. Check Vue use, please, because a super amazing library of composables, hundreds of them, the super nice documentation, you can play with them. And the categorization is state, browser, network, animation. Please do yourself a favor and check Vue use. But of course, if you want to play, I understand this pattern, the best thing to do is build your collection for your own projects.

So again, thank you for your attention, and I'll see you in the workshop where we will put this composable thing into practice. I'll see you there.