DejaVue

VueUse might be a library known to many Vue and Nuxt developers - and if not, it should be quickly! With over 200 functions, composables and utilities, it provides a "standard composable kit" which Alex and Michael take a look at in this DejaVue episode. And more than that, they also share their favorite composables that they use or learnt a lot from. Definitely do not miss that out and stay for the spoilers at the end.

Enjoy the episode!

Chapters
  • (00:00) - Welcome to DejaVue
  • (00:45) - An Introduction to VueUse
  • (01:59) - How often do you use VueUse?
  • (03:50) - Using a library or better to DIY?
  • (05:38) - The Reactivity Layer
  • (06:43) - Docs, Demos and Source Code
  • (09:52) - Composable 1 - useEventListener
  • (13:10) - Composable 2 and 3 - useDebounceFn & useThrottleFn
  • (17:46) - Composable 4 - useLocalStorage
  • (24:00) - Composable 5 - useMagicKeys
  • (29:04) - Util 6 - makeDestructurable
  • (33:18) - Wrapping up around VueUse
  • (34:43) - Nuxt Tips Collection
  • (35:33) - SPOILER!!!

Links and Resources


Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Speaker 1:

Welcome to Deja View.

Speaker 2:

Your favorite Vue podcast? You just don't know it yet. Or maybe do by now. Maybe you have a little Deja View. You'll see.

Speaker 2:

And, yeah, I am here, Alex and Lichte, a WAP engineering consultant and Nuxt team member, Also doing lots of content around Nuxt, Vue, JavaScript, TypeScript on YouTube, and every now and then blogging. And I'm here with Michael Thiesen. Hey, Michael.

Speaker 1:

Hey. How's it going? So I am a full time Vue content creator and educator. So I'm, you know, out here creating all sorts of things to help you learn more about Vue and Nuxt and do all that kind of stuff. The instructor for the official course on Nuxt, Mastering Nuxt, among other things.

Speaker 1:

Today, we're gonna talk about VueUse, this wonderful library that comes with so many so many useful things and so many things, in fact, that I am constantly forgetting that it exists and implementing my own versions and then realizing, oh, wait. It already exists. Why did I spend the time to do this?

Speaker 2:

Classic 1. Yeah. Vue use, for everybody not knowing, have never heard of it, go to vueuse.org and check it out. It's basically yeah. As Michael said, the library for all kinds of composables.

Speaker 2:

Like, it's it's really crazy. So whenever you think like, hey, that could be like a cool custom functionality that's not included in in Vue itself, there is a good chance Vue use might have an abstraction for that. And that ranges from, wrapping, like, web APIs, like, oh, yeah. Use the battery of your device and check if it's low or check if you're online, to, like, as I said, very, like, low level or abstracting things, all in composables and the best. It's also usable for Vue 3 and Vue 2, thanks to the Vue demi library, which means even if you're still using Vue2 and the composition API there, you can use VueUse.

Speaker 2:

There's nothing stopping you from that.

Speaker 1:

Yeah. Yeah. So Alex, how often do you use this, library and like what, what use cases do you find for it? Where do you find yourself reaching for these these composables?

Speaker 2:

Yeah. So I think in most of my projects I will use, or I have used vu use. It's not like I installed by default nowadays. It's more like, k. If I renew the I'll install it.

Speaker 2:

But as soon as I think my applications reach at least a medium size, I'm I'm usually going for it. That's mainly because if you start interacting with things like the local storage, then it's really nice to have a composable dealing with interactivity, setting things by default. Or if if you need anything with, like, scrolling, animations, and so on, that's also a real a real nice way to go there. And, for example, for slides also. So I use slide f, another amazing tool in the Vue ecosystem, which maybe you should do another episode about.

Speaker 2:

And and I use it there, like, because you can use Vue components in that amazing Markdown may slide tool, to generate a QR code for, for example, a link to the slides or to your YouTube channel. And yeah, even even for that, you can use VueUse and it's it's pretty amazing what the whole thing can do. And the best part, once again, it's fully tree shakable. So if you just use 1 tiny thing out of these, I don't know, 200 plus functions, then you only import the 1 thing and not all the rest.

Speaker 1:

I had no idea that there was a QR code 1 in here. I might have to use that myself. And using it in inside of that's a great idea for adding. I mean, there's a whole bunch of animation utilities and things like that. So I'm sure that there's some fun stuff you could do with that.

Speaker 2:

Definitely. Yeah. And how do you use Vueze? Do you use it often? Do you use it in, lots of projects?

Speaker 1:

I think that I end up using it, Like, most of the time, I tend to forget about like, I like I mentioned, I forget that there are these things that exist. And I'm I guess I'm just so used to implementing things myself, whether that's just, like, a preference of I I don't know. I like I I can implement my own debounce function. And so, I mean, then I just end up doing that. I don't know.

Speaker 1:

Maybe maybe it's a bad habit that I should should break and just start using these libraries off the shelf and not not, constantly reimplement all these things?

Speaker 2:

Yeah. Well, I think it has merit in both. Right? I I think, especially as we are in the JavaScript ecosystem, people are are very, like, in a way, they're it's very common to say, oh, yeah. I just need library to implement that 1 tiny function.

Speaker 2:

I just just wanna mention the good old is dash even package or the is dash odd package, and 1 depends on another.

Speaker 1:

I was gonna mention that too.

Speaker 2:

Fun. Yeah. And these are, like, these are the scenarios where, like, do you really need the package for that? And and also it's a lot about owning the implementation because if you write your demounts function, then you can, well, adapt it as you want. And you are not relying on, oh, there's a major change in library.

Speaker 2:

Now, what now? Do I have to fork it? Do I have to copy the code? Do I have to not update it? But, of course, on the other hand, it also means only an implementation means you would have to test it.

Speaker 2:

You would have to make sure it works as you want. And it's a bit more, let's say, burden or effort. While, for example, views, it has it's, like, nicely tested. People use it. So it's in in a way, like, pretty battle proven.

Speaker 2:

But I think in the end, that's a trade off 1 has to decide for for each case. I mean, I don't know when I reached last time for Lodash for, like, utilities because you can do most of the things just in JavaScript.

Speaker 1:

I think 1 of the things with Vue use is that there's that additional layer of reactivity as well. So like, compared to something like lodash, where a lot of these composables aren't necessarily that complicated, like, like using local storage, for example. It's not that difficult to use, but then adding that layer reactivity then adds another complicated step. Sometimes you might have you might hook it up wrong and there's another opportunity for bugs. But then there are composables like this use QR code where I wouldn't even know where to begin with generating a QR code or like I was just noticing there's 1 here use using clipboard.

Speaker 2:

Mhmm. Yeah.

Speaker 1:

The clipboard has been, you know, it's a notorious for, being difficult to use and and all of that. So some of these are really nice to have, like, a little nice abstraction for it. You don't have to worry about how clipboard works or how QR code generation works. You just, you know, use this nice little composable and away you go.

Speaker 2:

Absolutely. And the best part is, I think, if you wanna know how it works, so first of all, the documentation is amazing. So you can have a look. They have a demo for each of these composables, so you can actually test them right away on the fly. You can see what they're there can be used for, and they're usually also interactive.

Speaker 2:

So we can, for example, for the QR code 1, really see what's happening when you change text of the URL, then the QR code will change on the fly. You have type definition there, and, of course, also very important, a link to the source. So if you're really interested in, okay, how does it work under the hood? You can jump into the GitHub code, read through it and also learn a lot.

Speaker 1:

Yeah. I have learned a lot of things from the view use source code. I don't know what it is about this project in particular, but I've noticed a bunch of other people have mentioned this as well, that they've learned some interesting techniques and stuff. I think they always link directly from the docs into the the source code. So that's maybe 1 thing.

Speaker 1:

It's also, like, really nicely self contained, all of these composables for the most part. So you don't have to, like, dig through all these dependencies and, like, figure out, oh, wait. Where did this get called and where does this get called? So it's easy to read and learn and figure out these different things. And so yeah, a couple of years ago, I wrote a series for Vue Mastery, which they later turned into, some courses on different, like, patterns that I learned just from reading through the source code and and saying, oh, this is some some interesting stuff that they've done with their their composables.

Speaker 1:

And, yeah, we we might talk a bit more about that once we, get into specific composables here.

Speaker 2:

We will for sure. Yes. And I I totally agree there. I even, think from from 2 sides, like, as in writing JavaScript code, it's super interesting sometimes, and also how to, like, write nice composables. So for everybody writing their own composables, being extracted ones, inline ones, no matter what, even there, like, there is a documentation page called best practices and or best practice.

Speaker 2:

And there, you they really document, okay, what all these composables have in common, what do they return, do they use ref or reactive for it, do they clean up side effects? Yes. They'll do. We'll also get to that a bit, and so on and so on. So, you know, you have a really nice overview of how, first of all, all these composables should work and ideally can also adapt that own composables to, for example, not forget, oh, yeah.

Speaker 2:

I have to clean up the side effect that I created there from a custom logic. Or, okay, if there's a reactive argument, then the composable should also, if the reactive argument changes, do something because that's why you give an interactive argument. And in a way, I really value the consistency across the library even for all these different use cases, and also the abstractors as they share with the community. So their own composables from the users using library and then using them maybe in other composables will also be better.

Speaker 1:

Yeah. Yeah. It that is really it is really nice to have that. So let's talk about some composables from the library. So we have this 1 use event listener.

Speaker 1:

I'm just going to pull it up so I have it,

Speaker 2:

Yeah, sure. Go for it. Maybe in the meantime, I can tell a little bit about it. So, I mean, most of us have registered event listeners in their time being either with, like, vanilla Java script or through the, like, at click, at mouse over and so on in Vue. And, usually, if you don't do it through Vue, but manually, like vanilla style, then commonly people forget to deregister them or to unregister them.

Speaker 2:

So to clean up the side effects, what we just learned about. And commonly, it might not be a big deal, but if you have a component that registers an event listener, it doesn't clean it up, and it's called, like, 100 or 1, 000 or whatever times,

Speaker 1:

that can lead

Speaker 2:

to a memory leak on the client side to a sluggish application, especially for, like, these internal big SPAs that are opened once and then closed maybe at the end of the shift or the day. So that's really not a good practice. And the best part is we don't have to worry about implementing that on our own because the use event listener, composable will do this for us. You can just define your event listener, how it should look like, and the cleanup, which is usually done in, on before unmount or, on unmounted, and that would just be done for you. So that's the beauty of it.

Speaker 2:

No more boilerplate. And, of course, you could also write it on your own, but there, it works. It catches all the edge cases, and we're good.

Speaker 1:

Yeah. And I mean, I've I've made that mistake so many times before where I mean, it's so easy to forget to, clean up your your event listeners and all of that. And so it's nice to have that all packaged up in a in a little thing here. And 1 interesting thing that you can do then is because you've got this composable with reactivity, you can actually make these arguments reactive themselves. So if you use a template ref on, in your template and you pass that in, when that element changes, then use event listener will automatically switch things around for you.

Speaker 1:

It'll unregister that previous event listener, then attach a new event listener to this new element. And so you don't even have to worry about managing all that logic. It's just gonna keep things working for you.

Speaker 2:

Yeah. That's once again a a great example of, like, okay. If you have a reactive argument here like a ref, then if the changes, the composable should react to that and do the cleanup and register the new event listener when, the ref changes. So, yeah, I think really good example and especially if you didn't do much vanilla JavaScript, like, I mean, in our times when we started with JavaScript, we still had to do, like, a little bit of Jake Verhey in there, probably, a few, like, vanilla things. But people maybe never, I don't know, wrote a simple to do list in vanilla JavaScript.

Speaker 2:

They might not be aware that you should unregister event listeners at all because sometimes the the examples also just like, hey. This this is how you add it, and that it works. And that's it. And that's the end because it works. So in in a way, it also, yeah, either, well, avoids to to go into exactly that trap and either forgetting it or not even being aware of it.

Speaker 2:

Yeah. Yeah. Alright. Then we have 1 more composable. Actually, let's let's just do 2 straight away because they fit so nicely together.

Speaker 2:

Use debounce and and use throttle. Maybe before we get into these composables, Michael, can you explain the difference between a a debounce and a throttle? Because at least to me, it's always something you you check, you look up. Do you want the 1 thing, or do you want another thing? Yeah.

Speaker 2:

Do you do you have a a good, explanation for that?

Speaker 1:

Yeah. So I'm gonna do my best. I this is something that I find I am always looking up because I always get these messed up and mixed up in my head, and I'm like, which 1 is which? So, debounce and throttle. So throttle is you've got a bunch of events coming through and you for example, if you're doing, like a search component, right, you're typing into a search bar and you don't want to have a request hit your server every single keystroke because that's a lot.

Speaker 1:

Maybe it takes a couple seconds for that result to come back. So you want to slow these requests down. So throttle will slow those down and only it sort of, like, spaces them out, if I'm if I'm getting this correct. Whereas debounce will sort of it'll only take the most recent event. Is that a good way of ex explaining that?

Speaker 2:

Yeah. I think so. Like, I I always imagine you have, like, for throttle, you have, like, a gate, and you say, like, okay, throttle it to 500 milliseconds, then the gate opens after 500 milliseconds and the first request that comes through, okay, done, gate is closed. After 500 milliseconds, like every 500 milliseconds opens again, let's run through. And with debounce exactly the 500 millisecond, they would just reset every time you trigger the function request, whatever again.

Speaker 2:

So it wouldn't, I don't know if you have like 2 seconds, it wouldn't let, through 4 requests. But if you, like, type something again, again, just the last request, then after the 500 millisecond period is over, will be properly executed, which is, I think, a really nice for a search bar, because as long as the user is typing, typing, typing, that's a pretty good experience. While throttle can also work there, like, both both would work.

Speaker 1:

Yeah. And the the there is some subtlety in how they affected the user experience. And, we're gonna link to an article here in the show notes that you can use to to check it out. It's it's 1 of these things that's hard to explain just by talking. And so, yeah, you can check out some visual examples if you wanna get a better grasp of those differences.

Speaker 1:

But we do have some composables that allow us to do this. So we've got use debounce function and use throttle function. And so they're sort of like 2 sides of the same coin here where you can pass in any function that you want and get a debounce function back or a throttled function back.

Speaker 2:

And that's it. That's the easiest part. Like, you can just straight away go for it, wrap it around your function, and it it will just work. And interestingly, I think, for example, for use throttle function, there are some related parts of you use where this is, for example, used to implement it. So, for example, you can also have a throttled ref to only update the ref, for example, every 5, 5 milliseconds instead of all the time.

Speaker 2:

I also can have a debounced ref. So both are, things you can also find in view use as, like, rep implementations with exactly these features. And I've also used it recently. You can also have a watch, which is debounced, for example. So same idea, have a watch function that's not triggered every time things change, but a debounced 1.

Speaker 2:

And Right. I think they all use, like, use throttle function or use debuff function under the hood, or at least they share common utilities on the lower level and can make things really easy, especially when you work with, like, scrolling animations. Things that happen very, very often.

Speaker 1:

Yeah. There's a there's a lot of cases like that where we want to we've got a bunch of events that are happening, a bunch of user input, something like that, but we don't actually want to do anything, like, multiple times. Like, we don't wanna we don't wanna react to it that fast, and so we gotta slow things down. And, yeah, these functions are really useful for that. Rate limiting Exactly.

Speaker 1:

On watchers and stuff. Yeah.

Speaker 2:

We don't we don't wanna fire all the requests to the back end. Especially if they won't be relevant for users anyway, especially if they're, like, typing, typing, typing for each letter, you don't really wanna see the results. You can't reprocess it anyway as a person. Mhmm.

Speaker 1:

Okay. So the next 1 we're gonna talk about is use local storage. So we've got a couple related composables here around browser storage. So we can use them through the use storage, composable. However, 1 thing to note is that if you're using Nuxt, Nuxt has a use storage composable.

Speaker 1:

And so there's a little bit of a conflict there. And so when I'm using this composable, I'm usually using the use local storage or use session storage, which does use storage composable sort of kinda it like it's like an alias for for those, and you can switch between based on an option in there in here.

Speaker 2:

Exactly. And that's important to note. So if you use the Swift Nuxt, which, well, I can only do, you too, Michael, then you have a module you can just add, and all the views things will be also auto imported, of course, only when used. And exactly then, use storage is not auto imported, same for use fetch because Nuxt has own implementations for that, which also same idea. I commonly use use local storage.

Speaker 2:

That's a bit more explicit. I only need the local storage most of the time. And then in there, as the the name says, you can use values from a certain key of a local storage. But as it's a ref that will be returned, amongst other things, it is also a 2 way binding. So you can use the ref, you get a value, you can set a default in the options.

Speaker 2:

If the user, for example, has no information in the local storage under that key, then you get the default and it will be automatically set in your local storage. And also if you change the ref to say, okay, I want to update like a JWT token, some settings, then you just update the ref and it will be written. So once again, it's a very nice wrapper around local storage to make things pretty easy and very idiomatic in the Vue reactive way. So less boilerplate code is once again a big win. And also, it's it's way more clear.

Speaker 1:

And 1 thing that we forgot to mention about these composables is that not only do they add that layer of reactivity, but they also add those types for us.

Speaker 2:

Yes.

Speaker 1:

And so with with local storage and session storage, it's stored as a string. And so otherwise you just get a string back, and that's not as useful if you are using TypeScript. So what use storage will do is, let's say, underneath what it's doing is serializing that data for you. So we can go into a string and then back out so that you can save objects or numbers or other data types. You can write your own custom serializer if you've got different data types that you wanna convert to a string.

Speaker 1:

In a special way, you've got this extra layer of things. So yeah. In a in a way, local storage is straightforward to users. I you know, couple of methods to get and retrieve the values. But these composables add that extra layer of type safety and reactivity and

Speaker 2:

Convenience. Serialization. Yeah. Exactly. Exactly.

Speaker 2:

Especially if you use classes, which is not super common in the Vue ecosystem, but it can happen as well. And you want to, for example, create a class from something from local storage then like a serial like a serialization process, like custom serializer, that's ideal. Also the other way around, if you want to save it, then, it would be nice to tell, okay, how can I save that as, like, a JSON object? And of course, for for all the primitive types and objects in arrays, then the serializer, they will just kick in and see, oh, yeah. It's an object structure that will be an object, not just a string.

Speaker 2:

You have to then, parse yourself with JSON parse or stringify. So, yeah, big, big, big win, and once again, a layer of type safety convenience, and a joy to work with. So whenever you have to do something with the local storage and very important, then you also, get and set an item. So you you like to use that reactivity, then it's a good case. I commonly also just use the normal local storage API if I release it like, yeah.

Speaker 2:

For example, I have that on my website. I have a little notification, If your browser language is happy German, then I tell, like, hey. I also speak German. And for that, I don't use that composable mainly because I don't need the reactivity. I just check once the person enters the page, the user's there.

Speaker 2:

I just check, in on mounted, like, hey. Okay. Is that sad or not? And did the person click the notification away? That's where the local storage comes in.

Speaker 2:

And if that's the case, I will not show it. And if the person didn't click it away, I will show it. So there's no reactivity needed, which is why you don't always need to use a composable. And it always applies to to Vue in general. Like, you have to figure out where you need it for activity and where it's not really needed.

Speaker 1:

Yeah. That's a good point. It it's it adds an overhead, but I think most of the time that doesn't really matter, like the performance aspect of it, but it does having unnecessary reactivity, I think the biggest thing is that it makes it unclear of what's going on. If you have a ref that never actually updates reactively, then it can be a little bit confusing for someone else coming in or, you know, when you've come back to your code 3 months later and you're like, wait, why isn't this updating?

Speaker 2:

Yeah. It's happening here.

Speaker 1:

It's good to keep in mind that yeah. You don't, you know, you don't always need to have things be reactive. You don't always need composables. You can just use vanilla JavaScript from time to time.

Speaker 2:

Absolutely. The performance part I just had most of the time is minimal, though I've also seen projects where you have components, like tiny, tiny components. And they even said, like, oh, I use a computed property, though it's not needed. And if these components are called, like, 10000 times on a page or, like, even 1000 times, then that can make a big difference. Especially, like, data visualization can sometimes touch a topic.

Speaker 2:

Like, charts is always a big thing, and, like, data grids where you need, like, to show thousands of entries. There, it's it's really a a good way to optimize. But I also agree, like, optimizing just for performance should always be done when it's necessary, not, like, prematurely because that's not a good idea as we all know. Alright. Then let's jump to the next composable, and it's called use magic keys.

Speaker 2:

Michael, what what can it tell us about use magic keys?

Speaker 1:

So this 1 is really interesting. It's a useful composable, but I think the thing for me is that it's also very interesting in how it's implemented. So use magic keys. Basically, what you can do is you can go to the the composable and you destructure what keys you want. So it'll help you instead of using an event listener and saying, okay, listen to the space bar and the enter key, and then run this function when those are hit.

Speaker 1:

You can just use destructure and name the variables with the key names, if that makes sense. So you're not passing in any arguments to this composable. So how does it know that you're specifically looking for the space bar and the enter key and that it should update those reactively when you're, when those keys are hit. And it's it's not listening to every possible combination of every possible key. It's doing something interesting with proxies.

Speaker 1:

So I'm not sure if you can do key combinations at the same time, although you can use a computer to check for key combos. But what the proxy does is it intercepts when you do that get, which you do when you destructure it. You're basically, accessing that property from the composable. So when you access the space property, for example, this proxy will read that and sort of intercept that and say, oh, you're looking for this space property. And it will then create a computed property internally, and then it knows to watch for that.

Speaker 1:

And so it will then start to keep track of of that value for you. And then if you keep going, then you can add on whatever keys you want and it will keep track of that for you. And it will just dynamically create these listeners based on the properties that you're accessing from this object instead of you passing in arguments. So a very interesting interface to make this composable work.

Speaker 2:

Okay. That's I mean, that's pretty cool as also in terms of performance that you don't have to listen for everything, but just for the keys you actually want to get. And with keys, of course, it's meant, like, pressing keys on the keyboard and then, like, reacting, for example. Oh, if you press this key combination, like, a little shortcut should be used. But I think 1 important or 2 important notes here.

Speaker 2:

Like Mhmm. First, view use, we said it's usable for view 2 and view 3. This also applies to, use magic keys, but it's very important that IE11 is not supported because proxies are not supporting IE11. So if you use vue2, if you need to support IE11, well, our condolences, it's not that easy, then then you can't use that composable. Unfortunately, unless you drop IE or select, hey.

Speaker 2:

This function is only for non IE users and modern browsers, which is probably not possible for you. The the other thing, I think, now that that you're talking about it, so you basically use a proxy to register based on the name of the property, like, sysadspace. But then key combinations would also be possible if you don't destructure it, but say, like, you do you have, like, I don't know, const keys equals use magic keys, and then you say my computed property, like, const combination is keys. And then in square brackets, you have, like, control plus shift plus a or something like that. And then it should also be possible to listen to that through use magic key, keys, if if I remember correctly.

Speaker 1:

Yeah. Yeah. That's 1 way. I'm also looking through the docs here and you can when you're destructuring, if you use an underscore to connect the different keys. So if you wanted

Speaker 2:

Okay.

Speaker 1:

For example, if you wanted like a shift a, you would have your variable named shift_a, and then it looks at that will split based on that underscore that it knows to look for the shift and the a key. And when both are pressed together, it'll trigger that for you.

Speaker 2:

Sweet. So, yeah, I also remember in Vue 2, there was this, like, Vue global keys, package, I think, from from from ancient times, it sounds like. And that Vue use composable sounds like a really amazing replacement, especially also with performance kept in mind. So really lovely to see that. And, if if you ever, like, dear listeners, if you ever used, 1 of the views composables, if you prefer 1 with, like, hey, this is really something you should check out, then please write it in the comments, write it to us on Twitter, X, YouTube, wherever you want to master them as well.

Speaker 2:

Hit us up. Write us an email. We're really curious about your stories here here, dear devs.

Speaker 1:

So we've got 1 last 1 here that I'd like to mention in terms of how like, it has an interesting implementation. So we'll we'll do this 1 as the last 1. And it's called make destructurable. So this one's not technically a composable, but a utility function. And what it does is it takes an object and or a series of values.

Speaker 1:

It allows you to return a value that's both an object and an array. So it's kind of confusing. So if you want to destructure it as an object and have named properties, you can do that. But if you also want to destructure it as an array and just define your values, like, based on the position in the array, you can do that as well. I'm not a 100% sure on what exact use cases you would need this for, but it is, like, an interesting thing that it does.

Speaker 1:

And so how it actually works internally is that it uses object dot assign. And, basically, you take an array and you assign extra properties to that array so that when you try to access those properties on that array, it works. So if we remember that an array is like actually an object in JavaScript.

Speaker 2:

Mhmm.

Speaker 1:

And the properties are just numbers most of the time. And we also have a length property on this on this array object. We can also add in arbitrary properties using object dot assign or other things. And so then when you are, using that object, when you destructure from it, even though it's technically an array, these extra properties do still exist on it. So you can destructure off of that.

Speaker 2:

Got it. So this this sounds a lot like black magic in a way.

Speaker 1:

It does.

Speaker 2:

Yeah. But that also means, like, you can technically make everything destructible as either an area of the square brackets or as an object with the curly brackets, no matter what it actually is.

Speaker 1:

Mhmm.

Speaker 2:

That's very interesting. I I also think Anthony, who who probably was, the the creator of the composable, right, wrote, like, a long blog post about why you wanna do this, why it could be interesting also the TypeScript support, which is pretty similar because you like, pretty simple because you can just add a, an ampersand to say, like, hey. Okay. It's the object way and the airway way. So also for that link in the show notes to to see how how the creational process is.

Speaker 2:

But I never had a scenario where I thought, hey. That would be cool. But probably as an internal utile to, like, say, okay. You can take an array, but also an object, and then we transform it somehow. It doesn't have to check, for for performance reasons what is what.

Speaker 2:

Could be interesting. I definitely have to check out where where it's ever used. I'm I'm really curious.

Speaker 1:

Yeah. It's definitely 1, it's hard it's hard to explain. I I hope I did an okay job of it, but we'll link link to it. You can also just find it on the VueUse docs if you look for make destructurable. And it's literally like 26 lines that includes the, like, TypeScript types and all that stuff.

Speaker 1:

So it's pretty small implementation for this utility, and it's it's interesting though. So I I highly encourage you to to look through that and and, learn a few things even though they may not be all that useful.

Speaker 2:

Apparently I just checked. Apparently, it is used in another function from VueUse in a component function called create reusable template, where you enable to reuse part of the template, in, like, a vf v l's construct to not have to render it all again. So Okay. That's that's that's very interesting to do, and to see. But definitely also give that a a look because, wow, there's an actual use case for that.

Speaker 2:

I'm even more amazed. Sweet. And, of course, they are they're way more composable than than the ones we just mentioned. Like, for example, useRef history is another interesting 1 where you basically have the history of a ref, nice for, like, undo and redo and checking and so on and so on. There is a big list and also lots of integrations as the QR code integration as before with other packages, with RxJS, even if you want to structure data and so on and so on.

Speaker 2:

So definitely, give the whole thing a look, and read through docs. Of course, we also have all the links in the description to the composables that we've mentioned.

Speaker 1:

Yeah, definitely go check out the docs and just read through. I don't even know how many there are in here. There's, there's got to be like a 100 of them.

Speaker 2:

There's even 200 plus or so. So it's crazy.

Speaker 1:

There's even ones on doing math. So doing logic and average, all sorts of stuff, projections, whatever you need to do, there's probably something in here for you.

Speaker 2:

Super interesting and nice to see. Yeah. I also like the like, this whenever, for example, some of the, like, ref logic. So that's really interesting. Like, whenever that certain ref is true, if that certain computer is true, then do something.

Speaker 2:

Like, there are really some really nice logical abstractions. But, yeah, once again, look for it and, let us know which are your favorite composables, utilities, and so on you use from your use.

Speaker 1:

So before we wrap up this episode, I do want to mention that I am working on something special. I'm working on the Nuxt Tips collection, which is a book. It's going to have over a 100 tips on all sorts of ways of using Nuxt. And it'll be sort of like a like a sequel to the Vue tips collection books that I've put out previously. So I hope to have this done and released end of summer.

Speaker 1:

Don't know exactly when that'll be, but I will be sure to let you know when that is.

Speaker 2:

Sweet. And, of course, also, we have a link, so in case the pre order page is up already and still discount code, we all have that in the show notes, definitely check out the link there for next tips collection with a little sweet discount for the beloved deja vu listeners. And before we say goodbye, there is 1 more thing to say because this is the last episode before we have a very, very special guest on board. So definitely stay tuned for next week's episode where we have someone you definitely all know. I'm more than sure you do know that person, on here.

Speaker 2:

So, yeah, stay tuned. Check out all the other older episodes, for example, last week's episode, where we talked with Danny Roe about the road to Nux 4 and all the other ones before from service that rendering over Nitro to Vue in general. We we have lots of things covered, and there is more coming. So, yeah, if if this was your first episode, thanks for joining. If this was your 14th episode, then, thanks so much for watching every single 1.

Speaker 2:

If there's anything in between, you know what to do. Catch up, and talk to you next week.

Speaker 1:

Yeah. Make sure to subscribe on whatever platform you're on. That really helps us out a lot.

Speaker 2:

Exactly. And

Speaker 1:

we hope to see you in the next 1.

Speaker 2:

And don't forget the 5 star review. See you, folks.