I'm not so used to Zoom. I'm super used to Google Meet, but not so much to Zoom. Well, I will make this a little bit bigger. This is the repository that I shared with you guys. It has some branches. In case something, technically speaking, goes wrong, etc, there are three branches, one from each scenario that we are going to tackle. But if something happens that can happen, unexpected, you have here always some commits. We have a start commit, an end commit, and end alternative commit. I will explain you exactly what is it and why it's called this way. The same for the scenario two. You have the commits start, end, and add, and the same for the third scenario. So I suggest you guys to start with live scenario one because this only has the starting files. They're exactly what you need to start working with me. By the way, if you have any questions, please interrupt me. Say something, and I will try my best to answer on the spot. Right? So everything clear here? I will assume that yes. Minimize this. So I can have a clear picture here of you guys.Okay. Let's start. What are we going to do today? There are three scenarios. As you can see, there were three branches. Each branch is for one of those scenarios. You will start with this start thing because I don't want you to see me <a href="/tags/code">code</a> something on the spot to be able to start. This is something that you already have. So the first scenario, again, this one here, lives scenario one start, will have all the files that you need, all the components, everything. You have to clone it, you have to install the dependencies. This is using bytes, or bits, I don't know how to pronounce it. So you should be good to go. But what we have here, if someone has any problem, please tell me. Okay? But what is this? In my experience working with composables, and people that work with composables, there are a lot of folks that are still using options API inside <a href="/tags/vue-3">Vue 3</a>, and they are still using mixins inside <a href="/tags/vue-3">Vue 3</a>. I prepared this scenario just to mimic that.Before that, let's go to the mixins because I don't know if you know that in the <a href="/tags/vue-3">Vue</a> <a href="/tags/documentation">documentation</a>, it's stated specifically that you shouldn't use mixins anymore because there are some known problems. For <a href="/tags/scalability">scalability</a>, they overlap and inadvertently, that's the problem, right? And you share everything, right? It's like a component. So you cannot say, hey, I just want to expose this, but I want to get or conserve this as a privacy, so to speak. This is from the <a href="/tags/vue-3">Vue</a> <a href="/tags/documentation">documentation</a>. So let's check the diagram first, and then we see the <a href="/tags/code">code</a>. Application pass a user ID, this user <a href="/tags/data">data</a> uses two mixins to get information from the API, from the <a href="/tags/database">database</a>. Some albums and some posts. So when they get, again, they pass down, using props, to each component. So user <a href="/tags/data">data</a> is a child component for application, and user albums and user posts, both are child components of user <a href="/tags/data">data</a>. So let's check the <a href="/tags/code">code</a> here.

I will try to make it, is it big enough? Did you read my <a href="/tags/code">code</a>? I hope. Okay. Again, if something is not clear, something is not working or whatever, just please interrupt me, okay? I don't know if we chat. Yeah, I will try to open this also here. Okay, I will try to put it here, so I can see your faces and also the chat. Okay.Okay, let's start. Well, super, super quick tour. As I said in the diagram, we are using options API. Let's pretend that this user ID one comes from some kind of authorization, from a token, from a cookie. Doesn't matter. But our user ID is user ID one. Then we are sending this user ID to user <a href="/tags/data">data</a> as I shared in the diagram, right? We are passing the props down. So if I open user <a href="/tags/data">data</a>, it's here, by the way. What we are doing is collecting and using two mixins. Those two mixins are here and are mostly the same. We are getting the prop, we have some reactive states, post, some transformation, some mutation. And when everything is ready, if we have a user ID in this case, because we need the user ID to get the information, to filter the collection, then launch FetchPost. And if you take a look at FetchAlbums, it's exactly the same. And the way I've used this, for instance, just take this into consideration. If I wanted to call this use or fetch... No, sorry, this is not... This one. Instead of FetchAlbums, FetchData and I do the same in the other mixins. Since we are consuming it at the same time, it will occur some overlap, right? This is one common gotcha of the mixins. We don't have this with Compostables, right? As you are going to see super soon. So we are getting the <a href="/tags/data">data</a> and we are pasting the <a href="/tags/data">data</a> down. UserAlbums and UserPosts, as I said. Get the <a href="/tags/data">data</a>, the mixin from post, mixin from albums, comes back and we pass down. Again, we are doing the same. And if we open this information, these components, again, options API. It's a super simple iteration. Because for me, the key here is not the component composition. It's the <a href="/tags/vue-composition-api">composition API</a> and the Compostables. So I think... I hope this is clear. So how are you going to tackle this? What are you going to do? Well, this is the first thing that we are going to do. We are going to change these mixins from a Compostable. But the rest at this point, it will be the same. It will be just props. And again, there is nothing wrong with props. But they are alternatives. And this is the one, this Compostable, this user <a href="/tags/data">data</a>, or we will see. We connect to the <a href="/tags/database">database</a>. And we return a state that we can remove safely from the application, from the mixin, et cetera. So this is the first thing that we are going to do. How to do this, right? Because we are using options API. And first of all, you can use a Compostable with options API. Maybe we can implement this later. But as you will see, it's not the most clear way of doing it. So let's go here. And let's create in Compostables useUserData. There's a common pattern that prefixes the name with use. Some kind of use whatever. In this <a href="/tags/workshop">workshop</a>, you will create four or five use whatever. Typed specific to each situation, right? Since we are dealing with user <a href="/tags/data">data</a> here, for posts, albums, whatever, I think that this is a good enough name. So we have it here. What does a Compostable do, right? They expose something. They expect something and they expose something. So expects and exposes. So how to tackle this, right? How to start moving everything here from options API to a thing that lives in Compostables that uses <a href="/tags/vue-composition-api">composition API</a>. Very easy. There are three steps that you can write them down if you want. If any of you didn't have never worked with Compostables, this is a super easy to understand pattern to try. Let's look to reactive state. What do I mean with reactive state? Something that uses the <a href="/tags/reactivity">reactivity</a> APIs from <a href="/tags/vue-3">Vue</a>. So for instance, non-reactive state could be something like this. I don't know. Storage key equals user, for instance. This won't change. This is a state. It's local to this component. But it's not reactive state. So we don't care because we won't <a href="/tags/react-components">react</a>. Maybe as a side effect, we can need it in any situation. But I won't focus on this in the beginning. We are looking to reactive state. So which reactive state? Well, we have the user ID, but in this case, I don't know if it's reactive or not, but maybe we will need it. Here is reactive because it's <a href="/tags/data">data</a>. It's like a reactive reference. And we have, of course, if you go to the mixins, we have reactive state albums. Reactive state, well, this is a transformation for me. And we have some mutations. So look for reactive state. We have it here. In the other mixing, it's paused. So albums and paused. And also look for any transformation. A computed property transform this piece of state in some manner. So this is user albums, transformation.

User pause is another transformation. And lastly, look for anyone trying to mutate this state. We have it here. Fetch albums, fetch the albums from API and mutate the state. So this is, I hope, super clear. And the same with pause.So in a specific order, let's try to build this composable. So expects, we will see, but let's start with export function and use user <a href="/tags/data">data</a>. So what this thing expects. I think that expects the user ID, right? When we call use user <a href="/tags/data">data</a>, we can have the user ID here, for instance. Right? So user ID, it's a number. So we expect the user ID. And what I want to Google, sorry, and get all the pilots is smart enough that say that we need to use user albums and fetch albums and user post and fetch post. So we just only need to compose this, to create this. And it's easier than you think.So let's start with user albums. Right? I don't want this kind of auto completion, now. So the albums are here. Let's create the albums thing. And those albums, you have to think if they want, you want them to live inside the composable or outside. If you place it then outside, it will be like a singleton, right? It will be common to each implementation of this composable. But there are some times, and we will see at the end, we will see some cases that you don't want that to happen. You want to keep them private to each implementation. But in this case, I think that the albums and the posts can be common to all implementations. So let's create them. Const albums. And this will be a reactive reference. So we have to pull ref. Reactive API. And I need some interfaces. So I will pick user album and also user post. So we got two. So albums. Ref of user albums. Equals. Sorry. We can do the same for the posts. So posts. Is user posts. Okay. And I think this is enough to start building the inner of the function. So let's bring this exactly. Let's start with the album. Sorry. Because this is the reactive state. We will deal with the transformation. But now we are dealing with the mutations. The actions that mutate the state. So the first is fetch albums. So we're going to put it there as it is right now. And it will be albums value <a href="/tags/data">data</a>. And as you can see, it's exactly as it was in the Options API version. So we have fetch albums. And we need fetch posts. So we go to the fetch post mixin, and we do the same. So I need a new function fetch posts. We don't have this context here. What we have, but it's not what we expect. It's post value equals <a href="/tags/data">data</a>. And we will expose that. And this is another critical difference with a mixin. In a mixin, everything is public. The props, the <a href="/tags/data">data</a>, the computer, the methods. Everything is consumable from the outside. Sometimes this is what we want. If user ID changes, yeah, it will be reactive. In our case, sorry, I spot this question now. Sorry, but in this case, if this is reactive, and this is reactive because we are using <a href="/tags/data">data</a>, right? If this changes, for instance, in this computer's property that we have in the mixin, this computer property, user albums, takes into consideration user ID. So if this user ID changes, this will be revaluated. Because the computer property. And it happens the same in the other mixins, because the user posts is being filtered, right? It's a collection of posts, but I only interest this in the user ones. So if it changes, yeah, we will revaluate it. So as I was mentioning, with a mixin, you expose everything. There's no other way around, right? But with a composable, you return what you really need to return. So in this case, it's fetch albums and fetch posts. So we have a way to mutate. But I don't want to return. Yeah, I feel your pain. We will test a little bit the composables. Yeah. To my knowledge, I never use a composable that the main function doesn't return anything. What I've been using, as you will see, is a composable that also exposes something outside the function. Something that is adjacent. Something nice to have. That is not core, or something optional. But in my experience, sorry, I never use a composable that doesn't return something. I think that's just the pattern itself, you know?

We don't need to expose this. Because those are all albums and all posts. And we only need the user albums and posts, right? So I don't need to expose this. But on the other hand, I want to put that inside the function. Because then, every time we execute this user <a href="/tags/data">data</a>, we will recreate a new version of albums and posts. And we don't want that. We want to be global but private. So we don't return them. What do we return? Yeah, the transformations, right? So we have the first one here, in user albums. So two ways of doing this. If this computed property, because in the end, it's a computed property, right? So computed. If this computed property is going to be consumed inside the composable, we should declare as a canonical computed property. But if this is going to be consumed from the outside, we can do it in line. I know this is not so legible. And you can copy it again. That's it for me. But you can return specifically a computed in line. So you don't need to add anything inside of the body, sort of speak of the function. But again, if you need this property inside, then you can reference it. So let's do it both ways. We have the user albums. Let's do the same for user posts. So const user posts is the same. Let me fix the typing because these returns, yeah, it closely resembles the type, but it's not exactly the type. So let's pass the generic type argument because this is a user post collection. And we can do the same here, right? This will be a user album collection. So we have now, everything is ready and we can return it. Yeah, user posts. So we are returning everything we need, and we are expecting everything also we need here in this user ID number. So I think that this is good enough to start trying to work with it.So again, last time, right? Or maybe no last time, but I think that this is necessary for you to stick if you're starting with this pattern. Let's look for some reactive state. This is reactive state because you want to <a href="/tags/react-components">react</a> when someone or something mutates this state. So, it comes here. Next, you look for some transformations. And when I'm thinking of transformations, I'm thinking about computer properties, most of the time. So we have one here and we have another here. So they are closely resembled here in the composer world. And lastly, let's look for some mutations, right? Some actions that mutate these reactive states of the first point. And we have the fetch albums and we have the fetch posts that are also here. And sometimes you have to look for some side effects, right? Because we can watch here and do some side effects. In this case, we don't have it. So I think that this is good enough to try the composable. So where to try the composable? I won't touch application. In this case, again, we are only going to plug it in user <a href="/tags/data">data</a>, right? So let's go to user <a href="/tags/data">data</a>. And we close this and also this and also this and also this. Let's move this to options API. So just, I know that you have the commits and the branches to see the result of everything that I'm going to do. But I will leave this as a reference here. So this is a script setup. And we want to bring, we need the components, of course. So this, we really need them. But let's bring the composable. Import and use user <a href="/tags/data">data</a> from composables and yeah, what we need to do here is get the, I told you guys that we were going to try to do this using, I don't know, do you, this is obscure thing. Do you want to consume the composable from options API? Is something valuable for you to see it in action? Because this is ugly as hell. Okay. Amazing. So you know what? Let's get rid of this altogether. So yeah. We need to listen for this, right? So const props. Thank you, copilots. I'm not a super fan of copilot, but in this case, we are saving seconds and seconds for you guys to see the nitty-gritty, right? Not me fumbling with this everyday API. Yeah. We have the props. So let's fetch this. We get the user albums that are here, the user posts that are here from use user <a href="/tags/data">data</a> that is this passing this user ID. So that's all, I think. It should work, by the way. I didn't show you the results and of course, we need to fetch, right? We are not fetching here. So it's not only the collections is also the fetching, right? And we were doing this also here in the beginning, right here in user <a href="/tags/data">data</a>. So also we are going to unmounted, yeah. That fetch albums and fetch posts. This will work. Yeah. And it works as you can see. But let's try to await this because this returns a promise, right? This is a function. So we could use promise all because those two collections are not intertwined, but just for simplicity, bear with me. Wait, await. And this will give us some other kinds of problems, right? Because this is expecting suspense that it's only... I don't know if it's ready for the options API. I don't know, but let's put this in a suspense block that will basically await everything and has also some perks because for instance, you can put here a template. It's fallback. Yeah. Thank you, Copilot. Because I didn't remember exactly the name and you can see loading. Let's make it super clear. So now here, you can await a new promise that the results for four seconds. So this, I think we need also, yeah, I think one, two, three, four. Well, maybe it's, I counted too fast, but as you can see, there has some possibilities for you to deal with the loading state of each operation. And it's not only from the most inner component, every component inside suspense that has some async operation or await something will be tackled together inside the suspense block, right? So as you can see, we remove everything from user <a href="/tags/data">data</a> and the thing is still working.

And it's not only from the most inner component, every component inside suspense that has some async operation or await something will be tackled together inside the suspense block, right? So as you can see, we remove everything from user <a href="/tags/data">data</a> and the thing is still working. For me, this is good enough. Why? Because we are not using mixins. We are using, let me open a mixing here just to make it clear. This is a mixing. And again, what happens if in the other mixing, I call a method, the same name, and we are using that method inside the same component. We have a problem, right? Only the last one of those methods, it will depend absolutely on the order of those mixing to be loaded, right? And also the explosive ability. We are exposing everything. Here, we expose what we really want. And also in that regard, there is another API that is read only. So because now, let's, for instance, let's try to, let's, just for the sake of <a href="/tags/testing">testing</a>, let's expose posts, right? We don't want it, but we are doing it. So here, we pick posts. And here, for instance, let's posts. Set timeout. And not five seconds. Yeah, five seconds. Posts. Value. Push. Ah, here it is. We are adding another thing inside posts. And this is completely unexpected. And this is obvious here. But let's think in any other point in the application, somewhere is mutating the state without us knowing, etc. Shouldn't happen, okay? But can't happen. So in this case, if I reload, you will see a new post, right? Pop in. Yeah, there it is. Right? This is not expected. But we can make read only, right? We can make the posts, read only posts. Read, no. Read only posts. So now, if I try, you will see that, hey, this is read only target. So super, super useful. We can do the same, for instance, here in this user album, read only. And now, if you check, yeah, we lose the type. Because it's a read only ref of read only, just a little bit cumbersome. And of course, this is squacking now. It should work exactly the same, of course. Let's fix this, because this is expecting one thing and we are passing another, right? So if we go to the user albums, what we need here is telling that, hey, there is a deep read only type. And this is generic. So deep read only the user album. So now <a href="/tags/typescript-libraries">TypeScript</a> is happy, I guess. Yeah, it is. And this still works exactly as before. So yeah, you can set everything in a mixin. I even see some weird shit happening on mixins with configurations that you can pass parameters to the function, so it's even obscurer, what is done. Yeah, this is a nightmare. The mixins, for me, I don't really like that. So yeah, this is working fine. We have the suspense. We have the composable that is working flawlessly. Let's try to remove this. And also, we won't expose the post anymore. Yeah. So just to make it clear, it still works. But for me, this is good enough. We remove this mixin dependency and when I see this, it's extremely clear what I'm expecting and what I'm returning, no doubt about it. With mixin, good luck. Yeah, it's from you. Where it is? Where it is? Yes. It's from you. Because read-only is an API from you. And this is, by the way, as you can see, not very well documented. You have to tweak a little bit trying to make <a href="/tags/typescript-libraries">TypeScript</a> happy. I don't really like <a href="/tags/typescript-libraries">TypeScript</a>. I'm sorry, guys. I like a heresy. But yeah, I have to use it in my work, but I don't really like working with it. You can crucifix me. Okay, so last step of this first scenario. We have this, right? And what are we going to do here? Because as I said, this for me is good enough, no doubt about it. Because you are not using mixins anymore, at least. You have a centralized place with all the state, all the transformations, all the mutations, all the possible side effects to these states in a single place. So for me, and you're using <a href="/tags/vue-composition-api">Composition API</a> and also exposing what you really need and even going further, if you really need to expose something, at least you can make it immutable. So it's a lot of benefits, to be honest. But we can go further, right? Because why keep this prop flow? Because, yeah, props are there for this, right? There's no problem whatsoever. But what happens if this user post lives in any other place? Because this is a statement, right? We are saying that this should live in the same component tree. Right? And that's what it is. Is this one changed? Amazing. But what happens if it changes? Suddenly, you have to start doing something. So just as an experiment, we are going to remove all this prop flow and we are going to make the composable this time in charge of everything, because we will mutate the composable setting the user ID. We will mutate the composable fetching and we will pick states from the composable directly from user albums and user posts. So we are not making these components any smarter than they were, because they were picking the state from a prop and now from a composable, for me it's the same, right? It's different origin, same information. But this origin is ubiquitous, can be anywhere, right? So in my humble opinion, it makes this kind of components a lot more reusable, right? In your dependency and your component tree, I mean your application. So let's do it. So since we have to set the user ID in the application, right in here, I think that we have to create a method for it. We have to stop relying on the execution of the user <a href="/tags/data">data</a>, but in a specific function. So function set user ID, and the ID is a number, and user ID, we have to create, of course, maybe here const user ID is a reference of a number, and so null, and in the beginning, this null. Why not undefined? Because if I, I thought someone said something. Okay.

If I don't put this, maybe you're thinking, no, it's a ref of null, and that's all. Yeah, user ID is number or undefined. For me, undefined is the specific return value of both operations. So it's easier, it's harder to track down the line, but if you specify null in these kinds of situations, for me it's a lot easier, because null is like some explicit thing that happens, right?So user ID value equals ID, and what happens here? User ID value. User ID ref number. Ah, of course, I have to remove it here. Yeah. We have to expose it. So, maybe in the beginning. Okay. Set user ID, the rest is the same, to be honest.So, let's go here, and let's move these two <a href="/tags/vue-composition-api">composition API</a>, adding a setup. And we don't need this. We don't need any of this anymore. So, we are pulling the composable. So, imports use user, user <a href="/tags/data">data</a>. From composables, and set a user ID. This is an opportunity. I don't know who was asking about this, but maybe this function could live outside here, and importing differently. Just the function. Maybe this is not a good candidate for this situation, because it's necessary to set in the user ID, but I'm advancing you that sometimes I just export the thing outside the function, so it's like two different kinds of situations, but let's roll with this. Const, it will be set user ID. And composables, use user <a href="/tags/data">data</a>, use user <a href="/tags/data">data</a>. What happens here? I was misspelling it. So, set user ID one, and we don't need this property anymore. So, if we go to user <a href="/tags/data">data</a>, yeah, we don't need this also. We don't need it here. And we don't need also the collections, nor the properties, because we are going to get it from the composable. So, yeah. And in user albums, and user albums are here, posts. Take into consideration, we are only getting the fetch functions to get the information. So, again, I'm going to pull this from here. And to be honest, I don't think we need any of this anymore. So, and for user posts and user albums, I'm just going to go with this. So, we are not going to need this anymore. So, yeah. And I'm going to just pass this and for user posts and user albums, we need const user albums. Equals, I use user <a href="/tags/data">data</a>. And we can alias this to not touch the templates. And I think that we can do exactly the same in user posts. We have to add the setup. And in this case, it's user posts. And it's posts. And it should work exactly the same as before. We have removed a lot of <a href="/tags/code">code</a>, to be honest. It's a lot cleaner for me. So, let's try it. Yeah, it works. So, in the end, we achieve this scenario, right? Where not only we got rid of the mixins, that this is a self is amazing for the reasons I really know. But also, we are using a composable that takes care of everything, to be honest. And it's super neat. And thanks to this composable, we could remove a lot of <a href="/tags/data">data</a>, a lot of sentences from the components. And it's super clear to me right now, right? And again, we are not making these components smarter than they were. We are not fetching the <a href="/tags/data">data</a> in the component. I always like that my components are as dumb as possible. We are only changing the origin. We are fetching this from a composable. It's true that we are coupling this to a composable. But the composable is everywhere, right? So, we are not in a strict place in the application. It has to be a child component to such and such, right? So, this is working. So, any question before going further? Because of the await, the user <a href="/tags/data">data</a> view will not know the user post view until the fetch post is done. So, I don't have to deal with the case where post is null on user post. No, I don't think so. If you go to user post, yeah, this will only work when this post thing is hydrated, right? So, no, I don't think that you should care about that. So, let's <a href="/tags/unit-testing">unit test</a> this, right? So, let's move this user <a href="/tags/data">data</a> here. And let's create a use... Sorry, in the composable, there's a use user <a href="/tags/data">data</a> <a href="/tags/data">data</a> spec.ts. And let's all the test things that we need. So, B, expect, describe, eat. And well, we will import the rest after from the tests. So, what to test, right? Well, as always, this is not different to any other <a href="/tags/unit-testing">unit test</a>, right? This is some type of script functions in the end of <a href="/tags/javascript">JavaScript</a> functions. So, this is nothing fancy. We shouldn't test implementation, of course, because we expect that the reactive APIs from <a href="/tags/vue-3">Vue</a> are perfectly well tested. But we should test the result. And in this case, for instance, we could test that we have the correct URL when we try to fetch the the posts or the albums. And if we are hydrating the albums at the post with the correct information. And also, if the transformations are returning the specific post or albums of the user and not every post, I think this is testable. But anything above that is the implementations of <a href="/tags/vue-3">Vue</a>, right? So, I don't care into that. So, I know that we sorry, we define refs globally not inside the composable. We will find refs globally not inside the composable. I don't understand the question, sorry. Refs globally inside of the composable? We define refs globally not inside the composable. Yeah, here, good question. Because take a look. Every time we are executing user <a href="/tags/data">data</a> and in this last scenario, we are using user <a href="/tags/data">data</a> here, here, here, and here. Four times we are going to execute this function. If we put this inside, as you can see, there is no syntactic error, right? But this is a stateless composable. Stateless not in the meaning that we don't have a state. We have a state. But this state won't be unique.

It will be recreated every time we execute this use user <a href="/tags/data">data</a>. And as I said, it's one here, two, three, and four times. So, four times user ID album and post will be recreated. So, that's not what we want. We want this to be unique to each implementation of the composable because it can be hydrated and mutated from N parts of the system. So, what we want to be unique by implementation is the computed. But the computed property is based on values that are outside the function, that are shared, unique. It's like a singleton pattern, right? Please tell me if I answered your questions. If this is clear enough, I mean.Okay, amazing. So, let me go back to this thing because I think I– what are we going to test, let's test. Test if the vocal fetch with the correct URL and also if we fetches, for instance, posts and well, let's look at the composable, right? Because this is the source of truth. We are filtering here, yeah, and filters them by user ID. And we could go farther, but let's just start with this. I will need some kind of mocking things for the post. Let's start with the posts. So, I will go to the API that is here by the way, this is this API. It's extremely easy to use and perfect for demos. We are talking about posts, right? So, posts have this morphology. So, let me create a const posts response, whatever, will be a collection of this thing. So, let's remove the quotes and this is a body. We don't need also this and that and that, yeah. I think this is good enough user ID one. So, let's create a const user ID equals one and and let's copy and paste this one, for instance, another time. And another time. And let's format the documents and this will be for user ID one, but this will be for user ID two, right? So, here ID three, ID two, ID one. So, this is a nice way to test if we have the correct information. Why I'm doing this? Because I want to mock or spy, sorry. I don't want to change the implementation of fetch because that's what we are using, this fetch thing. I don't want to test fetch. I want only to know if this fetch thing returns the correct payload, this response and hydrates my implementation. Not fetch implementations or reactive APIs implementations. So, let's create that, right? Let's create a const fetch spy equals v Spy on, and by the way, I'm no expert whatsoever in <a href="/tags/unit-testing">unit testing</a>, right? As you probably see, but this is global, right? So, mock resolve value and this, if I remember correctly, have to return a risk. We have to mimic this, right? So, we have to add this JSON method that we are using. So, it's like, hey, let's return a promise resolve that also has a JSON method. Yeah. That's this. But <a href="/tags/typescript-libraries">TypeScript</a> doesn't like it. And I think it's because this is a response in and of itself, right? So, maybe we can make it happy as response. No, of course not. My God. Promise resolve. Let's go little by little. Yeah. So, we need return promise resolve something. And this something is a response. So, it doesn't like it. Promise resolve and this is also. I think that this is fine. I don't know why. Let me try with another API, fetch spy, because we have this BSP on. Instead of mock resolve value, there is some mock or resolve. Sorry, guys. This is mock resolve value. This is also a promise, right? So, we can add this JSON methods. Yeah. Amazing. I don't know why this wasn't working. I don't care, to be honest. So, we have a way to mock and spy the fetch. And this is returning, right? Returning what we need. Yeah. Promise response. Yeah. I will leave it as an assertion. Assertion. I know that this is a lot more ugly. But I will leave it exactly as this. So, we have the mock response. We have the we are mocking all of this. So, what we need here to describe what we are going to test, right? So, I said in the beginning that it call fetch with the correct URL. So, sorry. I think that as you can see, we can get the composable, by the way. Yeah. Yeah. Let's get the composable. From here, import use user <a href="/tags/data">data</a> and let's get fetch post from here. Again, fetch post will call fetch. Fetch is being spied. So, and again, the URL is here. So, the first thing we're going to test is this is passing to fetch the correct URL. It's this one. So, if we test it, of course, it passes. Now, yeah. This is exactly what I was expecting. We're using fetch post and user post from use user <a href="/tags/data">data</a>. We are waiting, fetching the posts. And I don't like this. I like this one. It will be exactly this.

So, if I change this, this will be an array with those two elements. Only the user one. This won't work. Why? Because we didn't set the user ID, right? So, at this point, this is not returning anything. So, let me comment this because what we should expect here is that this is empty. Right? So, now, if I set the user ID, I don't know who asked before if this should revaluate. Let's test it. Set user ID and now the user ID again is 1 here. This should also work. Because we are pulling only the post that has user ID 1. So, let's do it. And it works. Right?So, what else can we test? I don't want to make this a <a href="/tags/testing">testing</a> <a href="/tags/workshop">workshop</a>, right? I just want to give you a nice experience of what is <a href="/tags/testing">testing</a> a composable. So, we can do exactly the same. I won't do it for the albums because it's the same as you can see. It's exactly the same. We are awaiting the response. We are doing based on the user ID, some user album. So, I think that this is pretty clear to my knowledge. I don't know if you want to we can go last step. We can because what is missing here, right? For me, I guess you need to test this when you try to mess around with your <a href="/tags/code">code</a>. Setting something to undefined or to null or to some type that is completely unexpected and see if your <a href="/tags/code">code</a> breaks. So, for instance, so, for instance, let's set the user ID. To something that we don't have. We don't have user ID 3. So, this should be equal to an empty array. And it is. And again, we could go further but it's one hour for this example. So, I think that this is good enough to see the whole travel, right? From using options API and not one but two mixins. Two, using <a href="/tags/vue-composition-api">composition API</a> and relying on a composable that offers state and mutations. This is with everything. To three, even more reliance on the composable to make all the pieces of the application completely free, sort of speak, to be places everywhere. Right? And solving all the mixins inherent problems. So, before going further to the scenario two, do you have any questions?

Should we use a computed property to test? If the computed property doesn't work properly, it will give us an error. I don't understand. Daniel, sorry. Should we use a computed property to test? Well, I'm <a href="/tags/testing">testing</a>, yeah, I'm <a href="/tags/testing">testing</a> a computed property because that's where basically all the information that we need is, Brian, test the ref directly? I don't know. Yeah, we can do it of course because, yeah, let's do it. But for me, the source of truth, I will explain you my rationale, right? And for me this is not good or wrong. What is this? It's not that you are wrong or I'm wrong and you are right, etc. It's like, okay, we can test the for instance, the to-do ref, but there is a way of <a href="/tags/testing">testing</a> the ref and directly. And for me it's <a href="/tags/testing">testing</a> the computed property because the computed property is relying on the ref. So, if the computed property is returning what we need, some kind of filter of transformed information, this also means that the ref above him or it is also working. That's my way of thinking. But again, you know that the ng-testing is like, yeah, you can do it more or less whatever you want. But we can do it, yeah, we can. I think that we can easily do it, but there is a problem. We are not even exposing the refs, as you can see. So, we should expose the ref. Just a super quick experiment, right? Posts. So, now, let's say that it's hydrates posts accordingly or something like that. So, we have some async thing going on here. Okay. So, what do we need? We need a setUserId. Yeah. How about to me using composables, but in the end I end up returning everything. Yeah. But it's not our case. It's not our case. I think that this is extremely easy, or not extremely easy. We are doing a lot of things here. It is not the most complex one. I give you that. But if solving a real problem, because I didn't want to use the typical examples, grandchild, child, parent. I wanted to be something visible, right? So, I think that this pattern is solving a lot of problems, right? But in this case, we are only exposing things that are not easily mutable, like a computer's property. If you try to push something using push to an array computer's property, it won't replicate. This won't be tracked. So, you can modify it, but it won't recreate a rendering process. So, I think that this is carefully done. But let's go with your example. Let's, yeah, I think that this is amazing. We don't need this anymore. It's not user posts, it's posts and posts should return everything, right? ToEqual is called postResponse. And we need this before. To be honest, we don't even need to set the user ID because this will work elsewhere, right? We only need the user ID when we want to filter. So, it's like, okay, we only need fetch posts and the user ID is not needed anymore. So, this should work and it works. And the three of them also works. So, yeah, I will leave it here, right? Like a student per attendee comment to experiment. So, yeah, but in this case, we don't need this post, right? We don't need it here because we want to make that completely private. If you don't expose it here or of course, put this spot, there is no way you can mess with this. Right? So, we expose only what we need for this user ID, only the toLose, sorry, the albums and the posts that is specifically for this user ID. The rest, I don't care. So, I don't expose it. But nonetheless, we have this. So, is there any other questions? Can we move forward? Thanks to you for your questions. So, I will create a comment just to say that this ends of everything. So, ends. And let's go to the second scenario. That is this. This is an even more complicated scenario, right? Because what I wanted to show you in this little <a href="/tags/workshop">workshop</a> is the common <a href="/tags/patterns">patterns</a> or the common problems that are composable fixes, right? Or solves. One of them was the mixins, right? Having a only central source of truth for everything domain related, user domain-related, mutations, side effects. Everything is there, right? And also fixing the typical problems with mixins. And there are a lot of people that are still using Options API. Not because they want it, but because they don't have the knowledge and they didn't try and they didn't dedicate some time. And I understand that, right? Because you're super-pushed in your work, you don't have time sometimes to experiment and that's the way things are, right? But this is exactly why I wanted to do this kind of exercise. In the second exercise, we assume we are using <a href="/tags/vue-composition-api">Composition API</a>, but we want to tackle a different problem. The problem with prop drilling and even throttling or frothing. I don't know, to be honest. But what do I mean by that? I will show you the <a href="/tags/code">code</a> now. We have an application. Let me drink something. So, I hope that this is interesting to you guys. We have an application that serves the user ID, just as before. And we have inside this user <a href="/tags/data">data</a>. So, user <a href="/tags/data">data</a> is a child component, of course, of application. And this also has inside as a child component user profile. And this user profile has user to do's, right? So, every component is inside of the above component. And this user profile and user to do's are pulling the <a href="/tags/database">database</a> to get the profile <a href="/tags/data">data</a> and to do's <a href="/tags/data">data</a>. So, they are using state and mutations to get this information. And what are they doing? By the way, this is prop drilling, right? From application to user <a href="/tags/data">data</a>, to user <a href="/tags/data">data</a> to user profile, to user profile to user to do's. The same property. This is super far fetched. This is specifically built for this. But in my work, I saw somewhat similar scenarios, believe it or not, right? But we are doing exactly the same with the events. Because we want to show the username being mutated and how many do's are completed in the first component, in user <a href="/tags/data">data</a>. But the fetching is happening here. So, what should we do? Then, okay, we are passing events. We are emitting props, top to bottom, the same. And we are emitting events, bottom to top, the same, over and over and over until we get this. And if you're thinking, hey, why don't you improvise and inject? Yeah, of course in this case, it will work flawlessly. But it will be somewhat strange to pass callbacks and mutation functions down the line. But it will work because provide an inject needs the same component tree.

But it will work because provide an inject needs the same component tree. And we are. But what happens if then this user profile is being moved to a sibling of application for instance? Yeah, then we are in problems, right? So, let me show you the <a href="/tags/code">code</a>. Let me close everything. Let me move to live scenario 2. Let me recompile. Just to make sure that everything is working. Let's try it. Yeah. There it is. This is the user profile. Take a look here. Because if I change the name, it's being updated. And if I change the to-dos, the to-dos number is also being updated accordingly, right?So, if I close and open, because sometimes this does funny things, we have application, user <a href="/tags/data">data</a>, user profile, user to-dos, always with the same freaking user ID. Let me show you the <a href="/tags/code">code</a>. If we open application, again, let's pretend that this comes from some kinds of authorization. Sorry, <a href="/tags/authentication">authentication</a>. And it's number 1. And we are passing it to user <a href="/tags/data">data</a>. Okay. If I open user <a href="/tags/data">data</a>, we are getting the property. And we are passing it to user profile. Okay. If I open user profile, getting it, I'm passing down to user to-dos. Okay. And finally we are getting it to do all this crazy thing here. Well, not crazy, right? It's more or less the same that we have done in the past. But we are doing it in the component, right? There is nothing wrong with this. But we can do it better, in my opinion.So, what are we doing to share the information upwards? We are emitting events. From the most bottom part, we are emitting this to-dos completed. We are listening here and emitting again. So, we have, in the end, listening to two different events. Update user name and update to-dos completed. So, when this happens, we tackle these two callbacks. And then we mutate those two reactive references. And in the end, we change and reevaluate this part of the templates. So, again, this is working. And it's working fine. But it has some problems, right? So, is this clear enough? Guys? The problem, the scenario, all the gotchas that we have here. Believe it or not, this is super far fetched, I know, but this is happening in real life. So, let me show you what we are going to do. Well, again, two steps, right? The first one is this. We are going to, surprise, surprise, use a composable to get everything. And it's, as you can see, this event throttling and this prop drilling is over. We don't need that anymore, right? We will have to set somewhere, any place, the user ID. But once it's set, it works. And we will pull the state here, the unique state to see this name, and so many are completed, etc. And we will need state and mutations for end user profile and user to this. But I think with only this, this changes a lot better, as you can see in the diagram. So, let's start. And again, we have this three-part process, right? So, let's go to the second, to the side. Let's create a <a href="/tags/react-hooks">use state</a>. And if there are two composables that are super common in <a href="/tags/vue-3">Vue</a> and even in <a href="/tags/react-components">React</a>, what is called hooks, I think, but the concept, I think, is that I've been told is the same. That is, use a state and use surprise, because it's the next part that we are going to build here in this scenario. But this state is one of them. It serves to, as I said, to collect global estate from the application. So, you have some kind of <a href="/tags/data">data</a> store pattern centralized for everything that you do. So, just states. So, again, three parts, right? Reactive states, transformations, and mutations. So, reactive state, what do we need here? What do we have to do? User ID. Okay. Let's go down the line. We will have to have this. We don't need here a piece of state. User profile. User. Completed. This will be a transformation. So, user ID and user as a state. Reactive state. Complete to those as a transformation. Fetch user post as a mutation. And I think from here we don't need anything else, right? Well, let's open the profile. To those as a reactive state, user to those as a transformation. Completed to those. We have it already. Fetch user to those as a mutation. Toggle to those status as a mutation. And I think that this is enough, right? So, this is what we should pull from the components that is scattered around. This logic. What I mean is, and this is the magic of this pattern. You don't have to learn anything new. You don't have to add anything new. You have to move all the pieces to a different place. I grant you that. But you are already using this kind of state and interactions. So, for that, it's extremely easy to start using it. So, again, let's start, right? Let's export function use states. Okay.

What do we need here? Where do we put this user ID, right? Thank you, but I don't need this. No. So, again, we want to mutate from the application. The user ID. So, we'll need a method, right? I think that this is super understandable. So, what we need here is the correct way of placing things. Let's roll with having a function that expects a user ID. So, let's create it. And we can go to application. Since we are already using <a href="/tags/vue-composition-api">composition API</a>, let's bring this. So, ref. And we have to put ref. Import ref. I will allow some kind of pause outside when we finish this scenario for you to grab something to drink, to the restroom, whatever. Right? So, it's a ref from number or null. It's null. So, this is already here. We need this user. There's a flat object. I will explain to you what I mean with that. But let me pull the flat object and not only the interfaces, but the util. In one moment I will explain because I need to finish this. So, it's a flat object. And also we need a todoist. So, we need a user todo. So, what is this flat object thing? Well, the user profile from this API comes in a multi-leveled object. So, in order to make it easy for me to render and browse the information, what I'm doing is I created a little function that transforms any multi-level object in a flat object. So, we lose the type. I could create a type specifically for this with all these properties in a single, but let's roll with this. We have a flat object that is a record of a property key that can be a string, number, and symbol, and any. We could be more restrictive and put a known and try to type check every time. But again, this is not a <a href="/tags/typescript-libraries">TypeScript</a> <a href="/tags/workshop">workshop</a>. This is a Composables one. But I think you get the point. So, in order to recreate and flat all the structure, I'm using these methods from here that is flat object and also this type, this interface. So, we have the user ID, the user, and the user todoist. And as you can see, I'm using it here. So, the <a href="/tags/data">data</a> that comes is a user profile. Yes, but what we are showing inside the user is the flatted version.So, I think we need, we should start implementing. I don't think we need to return any of this. I think this should be, again, something that is global and shared across all implementation of this Composable. What I need, or I think that we need to return is the transformed version. So, let's go. Let's go with fetch user posts. So, here we can copy and paste. And the only thing that's the, it's not the only thing, this is exactly as we need. It's not props. That's true. That is user ID value. But the thing is the same, right? So, let's start exposing thing. And again, this is not super obvious, but this again, it's a <a href="/tags/javascript">JavaScript</a> object. We can return fetch user post. And instead of returning exactly the reference to the original method, we can do whatever we want here. So, we can compute something, we can check something conditionally. So, this is super powerful. And this for me is the amazing part. The most amazing part of this Composable thing is that you are, already have the skills and already have the knowledge because this is <a href="/tags/typescript-libraries">TypeScript</a> or <a href="/tags/javascript">JavaScript</a>, right? But in our case, we need these posts. So, let's do the same for the to do's. So, copy and paste here. So, again, user to do, et cetera. And as you can see, that happened before, right? In the last example. We are not dealing with errors, really. We are showing only a <a href="/tags/cli">console</a> thing. The next part of this scenario, we are going to deal with this directly. But let's wait a little bit. Let's finish this part. So, okay. Fetch user and toggle to do a status. So, here, do do. And this is the same. So, fetch user to do, toggle to do status. Okay. So, we are expecting, we are returning, sorry, everything we need. Well, not everything because we have completed to do's and user to do's. Let's graph completed to do's, for instance. Let's put it here. And as I tend to work, so, user state is like having all fetch methods in a composable. Not all fetch met. Well, in this case, yeah, I think you are right. Because what is a state, right? In our day to day application work as a front end, when we do some kind of operation, it's an asynchronous operation most of the time. We connect to some kind of API to recover <a href="/tags/data">data</a>. In this demo, we are using fetch. You could use Axios, any implementation that you want. But you are pulling <a href="/tags/data">data</a> from somewhere. So, yes, in this user state, if the application is ginormous, here could land all the fetch operations. If you have a very big application and not using this component <a href="/tags/architecture">architecture</a> but maybe a domain or feature <a href="/tags/architecture">architecture</a>, you could have a composable for each feature, for each domain part. That would be a wise solution because otherwise, the composable could be amazingly big very quickly.

If you have a very big application and not using this component <a href="/tags/architecture">architecture</a> but maybe a domain or feature <a href="/tags/architecture">architecture</a>, you could have a composable for each feature, for each domain part. That would be a wise solution because otherwise, the composable could be amazingly big very quickly. For this demo, I think this is good enough. And I lost again the track. Ah, okay. We are doing this here, right? The way I like to work, I like to expose the, put the transformations before and then the mutations. So, in this case, we have computed to this. And computed number. This will be user to this value filter is not user to this. It's to this. Sorry, it's because this is expecting user to this, right? So, user to this. We don't even have computed at this point. So, user to this. This not props. This user ID value. Don't worry, Daniel. I enjoy a lot of your questions. I really enjoy when people are participating. I don't see, I see your faces. It's like a vacuum here. And I really, really, really want for every of you to have this little knowledge. Because, again, this is the third time in less than half an hour. You can start applying this today or tomorrow. I'm super sure that you already know <a href="/tags/vue-3">Vue</a>. Hey, this is maybe a different way of using this API, of course. But I already have the knowledge, right? So, this is like a super short feedback loop. So, computed to this. Is, yeah. Computed to this. We have it. So, first user post is ready, ready. I think we have everything, right? So, let's return. Completed to this. And user to this. And, again, the same pattern. This part, when we have all the user <a href="/tags/data">data</a>. And the user, what? We need the user, right? Yeah. This should be also returned. Also returned. Yeah. And not the to-dos. Only the user to-dos. Right? I think that this is clear enough. Right? So, I think we are ready, to be honest, guys. To try to use this live. But let's do it. Well, this is not breaking or anything, right? Because I don't want to be half an hour. Yeah, okay. So, I don't need this ref anymore. I don't need this anymore. I only need the composable. So, import <a href="/tags/react-hooks">use state</a> from composable state. And here, yeah. I think it's... Let me check this. We didn't... Fetch user post, fetching post, or user <a href="/tags/data">data</a>. Yeah, maybe I... Let me check this. This is not clear. Okay. We have this user to-dos. Fetch user post. Fetch user to-dos. Yeah. This is not fetch user post. This is fetch user profile. Yes. Super good catch. I don't know the post, where it came. I will remove it. I hope that there is no other post reference, because there is no post here. But I suspect that if I go here. Yeah, fetches a post. Fetch user profile. Yeah. Thank you so much. And let me put this as it is before. And let's make sure that this is working. Make sure that this is working. Okay. This is working. Oh, there's some... It's working. Amazing. Thank you. So, again... I think that this is more clear now. Fetch user profile. Fetch user to-dos.

Toggle to-do status. Okay. Again, I don't need this anymore. Nor this. So, let's bring import <a href="/tags/react-hooks">use state</a>. I'm sorry. <a href="/tags/react-hooks">Use state</a>. From postables, <a href="/tags/react-hooks">use state</a>. Right? Okay. And const set user ID. That we don't have, by the way. Set user ID. ID is a number. And user, a pilot. Do your thing like this. And if you go here, set user ID. So, set user ID equals <a href="/tags/react-hooks">use state</a>. So, set user ID one. And we are doing the same. Right? And we don't need to use our <a href="/tags/data">data</a> to pull this. Because we are doing it... Oh, my God. I don't know what I did. This is... Okay. I think that I used some weird B combination and this went crazy. But I just wanted to delete to... I don't know what happens. Okay. Let me close application and open it again. Maybe it's time for a little pause. Seriously, guys. I don't know what happened. And this is also break a missing comma. But, yeah, just states. Let me reload the whole thing. Now, is it ready? I hope so. Yeah. So, if we go to this user <a href="/tags/data">data</a>, since we don't need this property anymore, we are not taking care of it. We don't need this property. Let's start first with user profile and user to those. Okay? So, again, exactly as we did with application, we need the composable. So, since I don't know which parts do we need from here, I suspect very little. Let's start building this. Because from user profile, what I need? I need to fetch the user profile. And also... That's it. I think that that's it. So, const user and fetch user profile equals user state. And this will, yeah, duplicate, of course. A leap of faith. Guys, I will remove everything and see what happens. So, now we have the user, but we won't expect this anymore. Okay? Ah, and await fetch user profile to get the user. Right? That's all. Let's go to user to those and do the same. We are pulling the same composable, and we are waiting for the user to do it. And we are waiting. We are pulling the same composable, and let's do the same. Right? In this case, we will need what. What we need here. To those. User to those, right? Completed to those. And toggle to do a status. Mostly everything, I think. So, to those, I don't need it, because this is a global thing of the composable, so I won't pull it. But user to those, I need it. User to those. Completed to those. And fetch user to those. And toggle to the status. Again, let's remove everything and see what happens. So, let's move this to the bottom. And we don't need this anymore. Await fetch user to those. And user to those. We don't need completed to those. And I think that this is working. Set user ID, no. Set user ID, we did it in the top hierarchy. Right? We said that we were going to this isn't working, guys, but here. Right? So, of course, it's not working, because it's based on false assumptions. So, right now, I think that this should work. User <a href="/tags/data">data</a>. Okay. User <a href="/tags/data">data</a>, we don't need this anymore. We don't need anything. And also, we don't need this. So, what do we have instead of to dos and name? Yeah. For to dos, we have completed to dos.

Right? So, let's start with what we have. So, let's, again, bring this composable thing here. So, it's user states here. Const. Here. Const. Completed to dos. And name that we don't have. So, what do we do for name? We can serve this user object that we are serving here. I don't know why, to be honest, because I think that we didn't use it. Yeah. User. Right. It's here. Okay. So, we will get the user again, but getting the whole object only for the name, we can do an inline thing, user name. Or name. And only serve this specific property as a computer's property. So, now we have an in order to touch the template thing, we can alias this to dos. And again, it should work the same. So, guys, I think that this should work. Let's try. Faded to the whole component. Yeah, I removed the component itself. I'm stupid. Import user to dos from component user to dos. So, now this should work. And it works. And if I change the name, updates. And if I update or not update, yeah. Working again. So, I think that this is pretty clear just looking at the components that we have removed a lot. Not removed. We have put in another place in a centralized, unique source of truth place all this information. And it's working fine. So, let's see.Okay. It's almost. Yeah. Do you want five to ten minutes break, guys? Or should we tackle the next scenario here? This third one and then for this last part, do a break in between. What do you think? Break. Okay. So, if anyone says once anything else, okay. Let's do a break for yeah, ten minutes, guys, right? Ten minutes. I see you there. Here. Sorry. So, let me stop. See you in ten minutes, guys. Okay. Let's go for it.Okay. So, as you can see, I added some can you hear me right? Everything is can you see my screen and everything? Okay. Okay. I added some boilerplates just to make it quicker. This <a href="/tags/unit-testing">unit testing</a> thing. The user response. The response. Because last time I invested two minutes mocking this. So, just some <a href="/tags/tips">suggestions</a> of what to test. The user and todos are hydrated. So, only todos. I don't know if we really need to cover for this <a href="/tags/workshop">workshop</a> all those scenarios, but just top of my mind, this will be what I will start <a href="/tags/testing">testing</a>. So, again, let's import v.it.spec.describe, et cetera, from v.test. And yeah, let's what do we need here? We need to mock, right? So, let's do it here. Cons fetch spy equals be spy on window fetch. Global fetch. So, now I can yeah, I can start describing the suite. Describe, <a href="/tags/react-hooks">use state</a>. And we need the user ID, right? So, let's mock also that. It was one. And I think that's we should start, right? So, and we need to restore also. Because I think that in the last test, we didn't restore the mocking. So, let's put here after all and after each. What do we want to do after all and after each? For instance, after all, we want to what? Be clear, reset, is reset, all mocks, because we don't want to mock the spy anymore. And after each, what we want is to be reset, not clear, all mocks. So, and here is restore. Not reset, but let's start. First thing, you said and to-dos are hydrated. So, it's yeah. You shouldn't to-dos are hydrated. Well, maybe this is something that we can start more slowly, right? Because not user and to-dos. Let's focus on to-dos, okay? Because I don't want to make this a turn on for the user thing could be something very similar as you well know. So, to-dos are hydrated, okay? So, what we can do, yeah, as Copio is saying, fetching, mocking the implementation of fetch to return this to-dos structure and then pulling user state and then pulling user state that we didn't import, so import <a href="/tags/react-hooks">use state</a> from user state. So, now we have user state, right? And fed user to-dos, user state, and we mean user to-dos, right? User to-dos, because we don't have a way to test this to-dos are hydrated because we are not exposing it, but we have a way to know if user to-dos show the to-dos for this user ID. And maybe this wasn't the best test to start, but whatever. So, we are fetching and user to-dos are here. We need also to set the user ID. So, let's start. First, set user ID using the user ID that we mocked there, the top, then fetch the to-dos and then asserting that, yeah, I expect that user to-dos value should be equal to the to-dos response, and this shouldn't work.

Why? Because this is the whole collection, right? I'm not interested in the whole collection. It's only for user ID one. So, we did something extremely similar in the first place, so I want to spend a lot of time here, just to make this pass, and it works. So, to-dos are hydrated, we can, yeah. Again, I don't know who answered this before. We know that to-dos were hydrated because user to-dos is based on the to-dos. So, if to-dos weren't hydrated, we won't get user to-dos. So, it's like, yeah, it's like a consequence, right? We can say safely that user to-dos, sorry, to-dos is working fine, even if we are not specifically exporting and <a href="/tags/testing">testing</a>. So, what else? Completed to-dos shows the number of completed to-dos. Okay, so, it yeah, this is not the best name, but I want to make it quick. So, yeah, completed to-dos to be zero. I don't know why this is not working. We have the completed to-dos from user state. Let's evaluate how this works. We need only the to-dos that are from the user. So, we need to, again, specify a user ID. So, we need set user ID and fetch user to-dos. So, we are setting the user ID, we are awaiting for the to-dos, and now, these to-dos that we are returning, all are uncompleted. So, if I try to, this is a number, by the way, that returns a number. Don't forget that. So, it should be zero, right? And it is. No, it's not. It's 11. Ah, it's because we are not mocking the response. See what happens? We return it. We didn't, I think that we did a real asynchronous operation there to the real collection. No. I want the mock of response. So, yeah, here it is. Again, it's passing. But what I want to do is also set toggle also set toggle to-do status, and to-do status expects the to-do ID as a number. Let's, for instance, try to complete the first to-do that has an ID of one. So, if I say here toggle to-do status, sorry guys, for the number one, this now shouldn't work because we have one, right? So, I can safely expect that this now is one. And we can continue at Aeternum, but I think that this is pretty clear at this point that we are pretty clear at this point that we are dealing with <a href="/tags/javascript">JavaScript</a> functions or <a href="/tags/typescript-libraries">TypeScript</a> functions, but in the end it's <a href="/tags/javascript">JavaScript</a>, and we are only <a href="/tags/testing">testing</a> the logic, the internal logic of our Composer world, not the APIs that comes from the DOM or from the browser like Fetch or from <a href="/tags/vue-3">Vue</a> like Ref, Computers, et cetera. I think that this is clear. I don't know if we can test toggle to-do status, toggles, the correct URL. This is extremely easy to test and I will leave it here. So, I think that this should be the first one, but whatever. So, I think that also Opilot is going to do an amazing job, and it is. And it's true, it's fetching, set the user ID. This is not true. We don't need to set the user ID to call fetch, so we don't need this but we need this. So, this should pass and it passes and it works. And just to make it super clear, if I misspell the URL, this won't work, right? So, enough. Any doubts here? Any questions? Anyone? We're getting closer to the end, guys. So, I assume everything is clear. So, now what we can do, we have this scenario, right? We have a ComposaBullet here just to deal with these asynchronous operations that we have now, right? Because why? Because this is working fine. I don't have any problem. But yeah, dealing with the error. And again, we can check if this <a href="/tags/cli">console</a> log is working, guys. So, it <a href="/tags/cli">console</a> error when an async function fails. Right? So, we will have to spy on const spy <a href="/tags/cli">console</a> error, <a href="/tags/cli">console</a> spy. Sort of speak, it doesn't matter. And then, yeah. We are yeah, fetching it to spy. Yeah. So, now we can just try to fetch something, right? So, fetch user to this, for instance, wait fetch user to this. And we can say that, yeah, <a href="/tags/cli">console</a> spy to have been called with new error. Failed to fetch. I am not so sure that this is working. Yeah. Here it is. Failed to fetch and it's here. And we can say we are not tracking any message, right? But I think this is close enough. Right? Because we are not storing the error anywhere. Okay. I will leave it here. Let's make sure that this is working. Everything is working. And again, but this is the poor man's version, right? Of error handling. We are we could do whatever we want in this catch clause. But we have to repeat it every time. And maybe it's not the wisest solution. So, what should we do? We can create another composable, the user sync composable that will deal with every asynchronous operation in the in the application. Right? So, let's do it now. Let's create it here. Use a sync. This is another typical one. User state is one and user sync is another one. So, what should we need for this user sync operation? Well, we will expect let's type this as a generic. Type T and we will expect a function that will be a promise of T. Of T. Right? And that's all, right? Because what we want is mimic what we do here. Having this try catch clause here. So, let's let's try, right? We have a we need a result and we need an error. Right? And we need a loading state. So, I will complete this. I will create it myself. Right? So, <a href="/tags/data">data</a> is ref, here. I didn't want to do this, but, yeah, that's me.

Let me break this and remove what we don't need. Let me import and I will explain to you guys what I'm doing. So, we are trying to create a composable only for asynchronous operation to deal with this try catch thing and catch the errors, do whatever we need. So, in order to do that, I'm going to create a composable that will be consumed wherever we need an asynchronous operation. That means also inside this composable. But also could be used outside of this composable. Wherever we need some kind of asynchronous operation, we can use this. So, the API of this composable, I have a <a href="/tags/data">data</a>, I have an error, and a loading. Right? And this is from the same type of the function itself. I don't know who asked before if the difference between returning this inside the function or not. In this case, I want this composable stateless. I don't want to hold or share any state. <a href="/tags/data">Data</a>, error, and loading should be unique to each implementation. Every time I use a sink, it's a different <a href="/tags/data">data</a>, a different error, and a different loading state. If we move this on the top, again, we will share it with all the implementation. We don't want this. I hope this is clear. So, I don't want to expose a function. I will go directly with the try-catch and think. So, what's the try-catch? <a href="/tags/data">Data</a> value is a weight function. This is an async, by the way. This was async before, sorry. A weight function. Let me see. Student. Student parameter type of...... Oh, yes. Sorry. Thank you. Yeah. It's a function that returns a promise of this type. Not a promise of this type. Thank you. Yeah. I want to be quick, but yeah. Okay. So, problems. Type of weight is T is not async. Okay. I will make an assertion, and that's all. Let's pull on props from view. So, okay. Unloaded value equals true. It's loading. Loading value while true. Unloading value finally equals false. We don't need loaded. We don't have execute. Here, yeah. We have to be type safe, right? We have to make sure that error is an instance of error. If it is, we can proceed. So, I think that we have what we need. We have a try catch. When we start loading, <a href="/tags/data">data</a> value, that's the reactive reference, by the way. So, yeah. I think we have everything. So, let's try to use this here, right. So, let's pull this off. Let's pull this composable. Import. Use async from use async. And let me copy and paste this operation, because at this point I'm completely on the fly. I'm not so sure how to implement this, so I will remove everything inside, and I will start. So, const, I interest in the result, to be honest, equals await use async, and use async expects an asynchronous function, but we have a problem. The problem, not a problem, a situation. The situation is that we have two functions, so we have to be creative in this case. If we want to use this specific API and don't complicate further the composable, we have to be creative. Why? Because this will be an asynchronous operation that returns async, so it should be await fetch this thing. So, await JSON. And amazingly, it works. It's declared, but it was never used. To be honest, I'm not so sure that this is working. But let's try it, because now we have our results, user profile. So, we have to do user value equals flat object result. So, just a sync, wait. So, I don't know if this is working, but what I'm trying to do is first pull this off, and then the second await for the JSON value of this, what is here. We are awaiting this, and then getting the JSON value. So, I don't know, to be honest, yeah, it's this one, right? Yes. I don't know. Is this working or not? I'm not sure. No.

But let's try it, because now we have our results, user profile. So, we have to do user value equals flat object result. So, just a sync, wait. So, I don't know if this is working, but what I'm trying to do is first pull this off, and then the second await for the JSON value of this, what is here. We are awaiting this, and then getting the JSON value. So, I don't know, to be honest, yeah, it's this one, right? Yes. I don't know. Is this working or not? I'm not sure. No. It's just a sync. Sorry. And this is complaining because it's just a sync. Okay. Now it's a type sync, at least. It's not a syntactic error. So, it's not working. I don't know what is happening here. So, just a sync, await. I'm awaiting this result, and also this fetch operation. Let's console.log the value. Is <a href="/tags/data">data</a>, sorry. Is <a href="/tags/data">data</a>. I don't like <a href="/tags/data">data</a>. I will like result. Is maybe this? I don't know. Yeah. It is. Here it is. It's working, guys. So, user value equals flat object result, and this is not working. So, a value, flat object results, result value, right? Yeah. It's working. Yeah. It's working. So, yeah. I think this is it, right? I will remove. We are not dealing with errors here because I want to deal with all the errors globally. You will see that. So, let's do exactly the same here, right? But I want to change. It's only to do. We will test for this to fail in our <a href="/tags/testing">testing</a> here. In this case, it's to do value. It's not flat object. It's result value. And we don't need that anymore. So, again, this is working, right? I click here. Okay. So, maybe you're asking. Yeah, at least before we have a console.log, what are we going to do? Attention results. Yeah. In the end, I could fix it. Thank you. What are we going to do? And this is an answer for another question. Someone asked at the beginning, hey, can we expose something outside the function. Yeah. In this case, I will do it because there's a pattern I explained in my talk that is the options pattern. So, let's imagine that we have an interface. Export. Not export. Interface of options. And you will see this everywhere. And this interface will be, for instance, let's say that we want to log errors, for instance, it will be Boolean, right? So, what can we do with this option thing? We can go here and expect that we pass options. And empty object as a default value. And then we can simply say, hey, const log errors, we pass a nice default of true, equals options. And in case that we have more options, for instance, key, properties, string, a key, an unknown, if you want to be super safe, we can get all of the rest here. Composable options. Safely. Right? But in this case, what I want to tell is, hey, I want to log the errors. I want to log all the errors that happen in all the asynchronous operations. So, we will have the individual errors of each operation if we want it, but we can have a global array of errors. I think that this is, let's imagine that we have to log this elsewhere, right? To any, I don't know, to any application that consumes this kind of information. So, let's create these errors. Think. It's not an error, it will be a string. I won't pass the error itself, only a message. So, that's it, right? So, if here, let's start curly braces, because we will have more than one sentence. And we can ask, log errors and push the message. And of course, we can make this exportable. So, I won't put these errors inside the composable, because this is optional. You can work with this composable with this optional errors thing, but if you want it, you probably need to plug it outside of the main implementation. So, you will get this array of errors. And you probably will need some kind of clear errors, right? A way of resetting the thing. So, you are also exporting this. We could export an object, but for me, this is pretty good. So, let's try this global error thing, because this is working. And since I don't want to build a model, let me do some cheating here and go to what you have solved. This is a scenario two. This is the ends. This is an alt. And we went to user <a href="/tags/data">data</a> and did this, right? So, let me copy everything.

Or at least this. So, if I go here, it's just below here. We are building a model. Just that. So, yeah. We can get this here, and I will show you specifically what I'm doing.So, we get user state, we get clear errors and errors. Sorry. Sorry. User sync. Sorry, guys. We have errors and errors from user sync. And in this case, it's errors. We need watch also. I will explain it super quick what I'm doing here. Unref. Okay. Every time we have an error, since we have a place, sorry, user sync. Every time we have an error, and we want to log the error, I want to show it in a model. So, and if I close the model, I will clear the errors. Right? So, how do I know if I should show the model or not? I simply watch the errors because errors is a reactive reference. It's watchable. So, every time a new error pops up, I show the model. And since it's an array, I have to show it. And I have to show the model, right? So, I'm going to show the model. And I'm going to the model. And since it's an array, I have to deeply watch this. So, I think that this is should work. And this is, by the way, dialog building a model. So, no error whatsoever. But let's do some crazy things here. Let's use to go to <a href="/tags/react-hooks">use state</a>. And, for instance, change this. Change JSON for JSON. Now, and, by the way, I should also check if the user is, so, user value, then proceed and also do it here, because if to those value. Okay. Again. This is happening, right, guys? Why is this failing now? If it's result value, sorry, I don't want to proceed. Right? Well, here it is. Close the thing. And if we go to the other implementation of user sync, and I don't know, let's do some gibberish here. You will see that we have failed to fetch and JSON is not a function. So, you can safely close. When we close, we reset the errors. And at least we see something on the screen. This won't work. Again, this is a very easy implementation, very crappy one, but I think that this is enough for you to see how to work with this.Any questions? Let's super quickly test this, and I will go for the last implementation. And I don't know if we should test this, guys, to be honest, because this is not a <a href="/tags/testing">testing</a> <a href="/tags/workshop">workshop</a>. And if you want it, you have it here. So, let me copy and paste and work with you. Let's create this use a sync spec.ts. Let's fast paste it. Maybe we should change, reset errors is clear, but the same. I think that this will work right away, and it doesn't. Okay. Indeed. Okay. I can resist to try to make this work, guys. I will dedicate 50 seconds to instance of error. Fails. And it fails to deeply equal. To equal. Error's value. This is not. No, it's okay. It fails, right? Because error when a function fails. And we are recording, right? False. So, what is happening here is these errors. Error's value to equal. We are not mocking all the implementation behind this, right? So, we should clear that. So, just to make it work. After each error's value equals. I think that this way, this will work. Ah, we were calling clear errors. Then I understand. Yeah. Yeah. It's failing independently, also. Error's value to equal. But, yeah. This is okay. Because if we clear the errors, this will work. So, I think that this test is not correctly written. I think this is what we expect. Right? This is correct. Because we are not clearing the errors here. So, even if you have the original branch to test and try and do your thing, this is what I will do with the Composa. But, error and result. Doing some with promise reject.

Doing some crazy things to make sure that we are dealing with all the situations. Okay. Let's finish this second scenario. We don't have much time. I will put ends. And let's jump to the last one. Which is the last one? We are using a DOM API. We covered the mixing thing with options API. We covered the <a href="/tags/data">data</a> store pattern with probe drilling and even fraudling in the second scenario. What happens if we want to deal with a canonical DOM API? Yeah. Let's move here. Right? Before. We have a blog post and a footer. Each of those components contains a banner. I want to be notified every time this banner is visible. How? We are using the intersection of server API. A super nice API. Intersection of server API. I suggest you use it. I suggest you to try. It's almost unanimous, the support that has currently. And very easy. You can do a lot of crazy things here. In the most bare bones implementations, you can say, hey, observe this element and when it intersects with a viewport or with any other element, just tell me something. Because I want to launch a callback. I want to do something. Notify me. We don't have to spy on the scroll anymore. We don't have to do that stuff that we were doing before in order to achieve this kind of logic. We are using this intersection of server DOM API here and also here because I want a counter. Right? Let's see how this looks in reality. Let's change also to leave scenario three. So, let's go here. Here it is. You can see the app log here. As you can see, this is an app and we have this trace. Again, the footer app. Again and again and again. Every time it intersects, and you should check the API because you can see how much it intersects. Right? And control a lot of things here. But this is the most basic one. So, let me show you the <a href="/tags/code">code</a>. We have application. We don't have user ID anymore. What we have is, let me show you the footer and the blog post. The blog post is using this API, this intersection of server, and it's observing this element that has a ref here, a DOM ref. And when it mounts, because this is a DOM, it writes, hey, observe this thing. And that's exactly what we are doing here. When this is being intersected, intersects with the viewport, we are emitting an event with the name of this property and the date. And we are doing exactly the same in the blog post. So, in application, we are listening for those events, launching this handler, and showing the result here. Is this understandable? I mean, is this clear? Guys? Because I think that in half an hour, we will get to this. Okay. I will assume that, yes, it is. Maybe three hours was too much. I don't know. Okay. So, as always, let's create here. Use intersection of server.ts. And what do we want to build here? Again, what is the ‑‑ in this case, the reactive states? Yeah, how many times this thing has been viewed, right? And also, the reactive reference of the element itself, the target. So, this is not exactly, exactly, exactly the same as we are used to. But let's try to build it. So, export function, use intersection of server. And what do we need here? Right? Well, we need a target. Right? We need a target. But we need a reactive reference of a target. So, let's start. Let's go here and put target. This target will be a ref of <a href="/tags/html">HTML</a> element. Why? I have to put ref, by the way. Import type ref. Because take a look at this. In the beginning, the reactive reference is null. But when the DOM is mounted, we hydrate with the correct link to the DOM node. So, in the beginning, it's null. But at some point, it should be an <a href="/tags/html">HTML</a> element. And I will leave it. We will have options at the end. But let's go for the most basic implementation. So, what I want to share here is if it is intersection of server. So, what I want to share here is if it is intersecting or not. I want to be notified. So, let me... so, this expects a target. And this returns what? If it is visible, this target. And also, the observe methods and disconnect. Because you can disconnect the intersection of server. You can also unobserve. But let's go for the most basic implementation. So, okay.

If it's visible, I will place it as a stateless thing inside the implementation. I don't want to share the visibility of all implementations. Every time I use this use intersection of server, I have a private use is visible, I have a private observe and disconnect. Why? Because I will pass a private target. It's a different target every time. So, why does it have to be shared? This is clear.So, let's create this const is visible is a ref of false. And let's pull ref. Let's pull ref. And as you can see, we have two options here. I hope you're not as brain dead as I am. Let me try to explain this. This is important. When you talk about a composable, you assume you're using it from inside the component. But you don't have to. You don't have to. You can use a composable whenever you want. But if you want to need... if you want to use this lifecycle hooks, mounted, unmounted, before mount, et cetera, you have to consume the composable from a setup environment, from a component.So, in this case, since we are going to use this unmounted because we want to do it automatically, we want to start observing automatically. I just want you to pass a reference to an <a href="/tags/html">HTML</a> element. And when the reference is hydrated, yeah, start observing and do your thing. So, we will need to always use intersection observer from components. And in this case, it makes a lot of sense because we are using a Reactive API, Atom API that expects elements. It's a component, not the origin of this. But just to make it super clear.

It's a component, not the origin of this. But just to make it super clear. So, let me copy this. And we don't need to remit. But what we need is this visible is true. And if not, it's visible is false. So, let me pull unmounted. In fact, if you try to use this composable as it is right now, using unmounted and unmounted outside a component, you will get some warnings from using, hey, you have to use this in a setup environment. So, unmounted, unmounted. So, let's create the observe function, the target value. But the target is, yeah, the target value, right? Yeah. Because the target is a Reactive reference, so its value. So, we have the value, we observe. Okay. And function, disconnect. Observer, disconnect. So, let's return everything as we always do. We need the is visible. Let's return first, yeah, is visible, the transformations. Let's return the observe, and let's return disconnect. And this is important. This is fine enough, right? But we should observe and disconnect manually. And we are providing this in case we want to use this functionality outside of the life cycles. But since we have access to unmounted and unmounted, why not use it? Unmounted... Sorry, this is... Observe and unmounted. Disconnect. And we are not exposing this. We are only exposing that. This observe and disconnect is visible. So, when this thing is... Because what will happen is, this unmounted and unmounted will tie to the component that the composable is executed. So, in this case, if you use it in blog post, this will execute when this blog post is mounted, and this will execute when the blog post is unmounted. So, it will tie to the environment where it's executed. I hope this is clear because it's super important. So, believe it or not, I think that this is fine enough. But what it lacks is the login thing, right? So, let's try to do this. So, let's create an interface... No. Yeah. Intersection log that will have its name, is a string, and when is a string, right? And we need an element, right? Intersection log. Intersection log equals a ref of intersection log. And it's empty. So, every time... And also, we need some options, right? So, const intersection options... Or options. We're calling options all the time. So, sorry, I will put it here. We'll put it here. This extends intersection init, and what is that? If you take a look at the API, these are some properties that you can change. So, we want to take care of these kinds of options that come with the API itself, but we want also some optional things. Like, for instance, the name that is not optional, right? Because we want to use it, and the when will be created inside log, right? We can say log the thing or not. So, this will be optional, and it will be a boolean, because maybe we don't want to log the intersection observer. In fact, in reality, I will always put it in false, because maybe we are not interested in that, but we can log the thing. So, now, what I will do is use this pattern here, the options pattern for the second time. Super powerful. So, options is options. We don't need the fault here. And here, we can say const name log, I don't know why. I don't know if you can hear me. But suddenly, I don't know what happens. Okay. Can you hear me again? Can you see my screen? Because I don't know what happens. Okay. Sorry, guys. I don't know what I was talking. Yeah. The intersection log. Yeah. Name log this. We can put a nice default here. And get everything, right? So, if we are logging, if log, we can do this. We can hydrate that log with the name and when it's happening. And, of course, we should export this. So, export const intersection log, et cetera. So, now, I think that we are ready to test this thing also. All right? Good luck later <a href="/tags/testing">testing</a> this, because this time, I think that we will need to create that dummy component. So, we'll need to view test. So, yeah. Let's start with the implementation, right? For the footer. So, what I need here I hope this won't break. And let me please go here and put this nice background <a href="/tags/creativity">music</a>. Okay. So, unmounted, ref. To be honest, I don't think we need anything here besides ref. So, let's pull this composable, this import. Use intersection observer on the composables. And we are defining it here. So, use intersection observer at footer ads. And this should come in an option subject.

So, it's name footer ad. We can change the API. But believe it or not, I think we don't need any of this. Don't even need the unmounted thing. Use intersection observer. And let's do the same for the blog post. So, we'll get this here. And it's not footer ads. It's blog post. This is our reactive reference. And here we need this intersection log, right? So, let's again pull this. We only need the intersection log. We don't care about observing anything here. We care about what's being observed. In order to touch the intersection log, we can make an alias, like at log. This is enough for me. And this should work right now. But take a look at the considerations, right? This could be a direct child of the application or any other chain of components. We have a gateway to access the DOM API. Now we should test this. Let's create a composable, use intersection observer spec.ts, and import the necessary dependencies. We will need a component for <a href="/tags/testing">testing</a>. So, we import the intersection log and use intersection observer composable. We mock the observe and disconnect methods of the DOM API. And now we can test this composable.

So, in order to ‑‑ we also don't need this. We can make an alias, like, at log, to touch the ‑‑ it's not ‑‑ okay, I almost ‑‑ I forgot how to do it here. You can do it. It's not important. It will be as ‑‑ I don't ‑‑ it doesn't matter.Intersection log. This is enough for me. And this should work right now. And it does. Right? But take a look at the considerations, right? Because now we don't have to do this chain of commands here. This could or could not be a direct children of application. In this case, it's application. So, yeah. It has to be a direct children. But let's imagine that we have another chain of components. We can listen to this from anywhere. Right? And we are not calling the same API twice from the different ‑‑ the same <a href="/tags/code">code</a>, I mean, the same implementation. We have a gateway to access the DOM API. In this case, use intersection of server. And this is the composable. And it's serving things perfectly as you can see.Any doubts here? Because now we should test this ugly thing. Any doubts? No. Okay. So, let's move this to the right ‑‑ to the left. And let's go to the right. And let's create a composable. Use intersection of server.spec.ts. And let's pull the typical things, again. Import. Be, eat, expect, describe. And we will need after callbacks. But we will do it as we need. And import mount. From view test duties. Because we will need a component. Right? So, at this point, I'm frightened. So, I don't know. It's almost ‑‑ more than three ‑‑ almost three hours. We don't need these components. We will need ‑‑ what we will need? We will need the, of course, the composable. So, import. Intersection of server log. Intersection log. And use intersection of server. Composable itself. And what I will try to do is to mock. This time we have to mock the implementation of a DOM API. Of a window API. Right? Because this is using intersection of server. And we are using two of the methods of the API. Observe and disconnect. So, let's create a spy, a mock ‑‑ sorry. It's a spy. No. It's a mock. So, it will be observe. Mock equals BFN. And the same for the disconnect mock. And now, we can say intersection of server mock. Mock will be BFN. And here, we are returning observe and disconnect. Right? And also, this is important, since we are replacing ‑‑ we are not spying, replacing the implementation, it's a nice idea to have a copy. So, const original intersection of server. And we will need the before all and after all. And before all, what we want to do. It's pretty obvious, right? We want to, yeah. Window intersection of server as any ‑‑ I don't care anymore. After all, we want to replace. Again. So, we have this thing mocked, right? We had before all and after all. We need a component. We have a component. And yeah. A component. Because I don't want to bring this component where I'm using. So, const component equals this is an object, right? Where we have templates. And yeah. Bref null. I don't think we need this anymore. Right? We need a target. Ah. We need a target. Of course. So, const target elements. We have to ‑‑ this is a ref, right? Ref. We need a ref. So, import ref from view. Okay. So, target elements.

So, let's ‑‑ I don't think we need this. It's visible. Observe and disconnect. Target elements. And the rest is name test. Okay? So, we are getting the it's visible thing here. So, I think we can ‑‑ we have ‑‑ I don't know, to be honest, guys. I don't know if we have anything that we need. But let's try to check if this starts and stops observing. Right?So, describe. It starts and stops observing. So, no, it's not a thing, right? I don't know. I'm brain dead. This point. Okay. Let me check this. Proper mount components. So, we don't need to await this. Right? Okay. So, we are mounting the components. So, the observer mock has to be called one time and the disconnect mock has to be called zero times. And when we mount, remember, when we mount, we disconnect. When we mount, observe. So, when we are mounting these components, this thing, this observe has to be called one time. And the disconnect, zero time. I will leave it as it is right now. So, this should work. So, this should work. And it works. So, at least we have something. So, what can we also test? This ‑‑ I have a snippet here for a part because this is super obtuse, so I will copy it. Because the only thing that I will left as a <a href="/tags/unit-testing">unit test</a> is I don't know if you have any <a href="/tags/tips">suggestions</a>, but if it really launches the intersection of server, callback, and updates, the lock. Because any other thing here for me is <a href="/tags/testing">testing</a> the implementation itself via one of the intersection of server API or the reactive APIs from <a href="/tags/vue-3">Vue</a>. What I wanted to pass here is this thing. This observer is spy, and in this case, it's observer mocked. We are mocking the implementation once. We have mock calls every time we, since we have mocked this intersection of server that now has been put again in window, we can know how many times has been called. Right? So, we can recover that call and do the call back itself with this intersecting exactly as we are doing in the canonical API. So, I think that this will work, but who knows. Right? What we should do here is wrapper the component, and, yeah. It's visible thing. We need to really is getting this is visible. Yeah. The wrapper is visible. Why? Because, again, we are returning and exposing this is visible that in return is also coming from the composable. Not only that, but observe and disconnect. But we are not using this test to be honest. Only if it is visible. So, VM, because this is the main view instance in this component, is visible to be true. Right? And we are faking it. We are not using any as soon as this launches. We are saying, hey, this is intersecting. Right? So, let's hope that this works. And it works.So, how can we test the log? Right? Because now the intersection log that is here lengths to be one. We won't go into specifics, but we can say that this works. Right? And before mounting the component, the length should be zero. Right? It's an empty array. And it is. And it is. So, we can go from here and test more things. But for me, the bare minimum is that, yeah, starts and stops observing the whole thing. And also, intersects when this thing intersects, everything is notified. We launch the callback. We update the log. We do everything we need to do. So, any questions regarding this? I will write the comments. And again, I won't push these comments. Because you already have all these solutions. And I won't go into this. Because I don't know. Anyone here knows <a href="/tags/vue-3">Vue</a> Use Library? I don't know if you know this library. I wanted to implement this useintersectional server API from the library. Yep. You want to use this pattern in your own work, I suggest what we have down here. Build your own composable library. But and this is a big but. There is <a href="/tags/vue-3">Vue</a> Use. <a href="/tags/vue-3">Vue</a> Use is an amazing, amazing, amazing collection of composables. Plug and play. Works with <a href="/tags/vue-3">Vue</a> 2 and with <a href="/tags/vue-3">Vue 3</a>. And lo and behold, if you start looking for the composables, that is here. And we use intersection of server. We have the own implementation. So, you can for less than one kilobyte, export size, I mean, you can import this in your own projects, be a directive or the exposed direct API, I will say. The API itself is completely different as mine. But that's amazing, right? Because there's different ways of doing it. So, I will suggest to test this. It's amazing. We have a state, user sync state, elements, browser, sensors, network, <a href="/tags/animations">animation</a>, component, watch, <a href="/tags/reactivity">reactivity</a>, array, time, utilities, and so on and so forth, right? It's an amazing, seriously, do yourself a favor and check this because it's an amazing tool to your tool belt.

So, very easy to do. You have to course, install the core of the <a href="/tags/vue-3">Vue</a> Use. And this is 3-shakable, of course, only the composables that you implement will be in the final bundle. So, it's super well optimized. And the thing is that you can play, I don't know if you notice, but you can play a little bit with each composable inside the <a href="/tags/documentation">documentation</a>, right? You can be the source, the demo that is here. And the internals of each of one of those composables.So, I will leave it here because I think that we covered a lot of things. I don't know if you have any doubt, any final doubt before closing this, guys. You will have the recording. Again, you have the the repository with all the things that you need in order to start. So, you have to go to the Core branch, scenario 1, scenario 2, scenario 3. It has all the answers. So, I will leave it here. I really, really, really hope you learn something useful for your day-to-day work. And yeah, thanks to you, guys. And see you around in the <a href="/tags/vue-3">Vue</a> <a href="/tags/community">community</a>. If you have something to ask or to say, you can go to squela.vue.es and let's put in English. Some <a href="/tags/tips">tips</a>, et cetera. Maybe sometime sooner or later, we'll do another <a href="/tags/workshop">workshop</a> maybe. But we can get in touch. Okay, guys. Thank you for your attention, for being here. And have a super nice rest of the day, guys. Bye.

Vue.js Live Conference

Vue.js Live 2024

Learn To Use Composables: The Swiss Army Knife Of Vue Developers

Aprende a utilizar Composables: La navaja suiza de los desarrolladores de Vue

The Workshop introduced composables in Vue 3 as an alternative to mixins and the options API. The transition from options API to composables involves looking for reactive state, transformations, and mutations. Composables provide a centralized place for managing state, making components more reusable. The use of testing and mocking allows for thorough testing of composables and their behavior. Lastly, the workshop explored the use of the Intersection Observer API and its integration with Vue 3 composables.

Composables (composition functions) are stateful/stateless functions that can leverage Vue's reactivity API, decoupling it from components.This shift in perspective opens the possibility for tackling common scenarios in a new and creative way. In this workshop, you will learn how to solve typical problems every Vue developer faces, using composables: <ul><li>- Data store;</li><li>- Component cross-communication;</li><li>- Utility functions (DOM, API, etc);</li><li>And more.</li></ul>

Juan Andrés Núñez Charro

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.

JSNation US 2024

React Summit US

React Summit US 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

React Day Berlin

React Day Berlin 2024

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get a free remote ticket & join me there with 5k other #nodejs devs & 35 great speakers #deno #cloudflare #awscloud

Node Congress 2025

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2025

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2025

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2025

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

Learn To Use Composables: The Swiss Army Knife Of Vue Developers

Comments