🍍The Pinia Colada Song with Eduardo San Martin Morote🍍

[INTRO]

[00:00:00] ANNOUNCER: Did you know that nine out of 10 podcasts can't read your mind? It's true. We're one of them. We don't know what you're thinking. When you have a problem at work, we don't know. We just don't know. We can't read your mind. What you could tell us, so it'd be like telepathy if you fill out a survey, that's in the show notes. Then you could tell us what you want more of, what kind of problems you're facing at work, what kind of stuff you want to hear about, and other things, then, who you want to hear more about, things like that. That way, it'll be like sort of, like we're reading your mind, right? Because we'll know. We'll know. We will understand you. We will understand your problems, and we'll be able to help you with those, if you want that. We care about you. Let us help.

[00:00:52] CF: I'm Chris Fritz, and I endorse this message.

[EPISODE]

[00:01:20] AR: Hey, everybody. Welcome to Enjoy the Vue. I'm Alex. Today on our panel, we have Ari.

[00:01:27] AC: Hello.

[00:01:28] AR: And Tessa.

[00:01:29] T: Bonjour.

[00:01:31] AC: Fancy.

[00:01:32] AR: Yeah. Fancy. For our special guest for this episode, is Eduardo, who is a member of the Vue core team. Introduce yourself, Eduardo.

[00:01:43] EM: Hi, everyone. Apart from being a core team member, I'm a freelance. I live in Paris. I’m from Spain. I love languages, cultures and programming and the router. Plans in routing, not the network ones.

[00:01:57] T: Routing is your passion.

[00:01:59] EM: I guess so. Became.

[00:02:02] AR: Routing design is his passion. Awesome. Well, all right. We're going to start off with a round table question here. Tessa, Ari, Eduardo, have any of you ever used a global store, or some global data storage method for Vue at all? Has anybody here –

[00:02:25] T: Like an event bus?

[00:02:26] AR: No, no. Not like an event bus. Something more less bad.

[00:02:33] EM: A local storage works very well.

[00:02:34] AR: Yeah, local storage, but not necessarily persistent. Maybe –

[00:02:39] T: Oh, Redux.

[00:02:40] AR: Yeah, Redux. Redux, but for Vue. Has anybody ever done anything like that?

[00:02:45] AC: I think, I sometimes use this thing called Vuex. I don't know.

[00:02:49] AR: Oh, yeah. I think I've heard of that before. It seems like a thing. How about you, Tessa? Have you used anything?

[00:02:56] T: I did use it a while ago. I haven't used it recently.

[00:03:00] AR: I definitely have played a lot with Vuex. There's a lot of great things about it. Sometimes, I want to be able to just break it up into smaller pieces. How about you?

[00:03:09] AC: Modules. Sorry.

[00:03:13] AR: Yeah. With modules. How about you, Eduardo? Have you ever worked with any state store mechanism type thing, or anything like that?

[00:03:21] EM: Yeah. My clients and in my applications, they really have Vuex for the good and for the bad. That means, they use it when they shouldn't. Also, they use it when they need it. They put too many things in it, usually. It gets quite out of hand very often. I haven't seen people successfully use it with TypeScript either. Or it's a mess, a typing mess. However, we have a lot of manual typing going on. Since the end of 2019, I started working on these prototype called Pinia.

[00:03:59] AR: Interesting. Is Pinia – it's a store type mechanism like Vuex, but it's different?

[00:04:06] EM: Yeah. It’s a state management solution. Very, very simple. Very low level. It is scaled down, as I like to say and try to scale up as well. We try to stay as close as the actions state and getters model. It's not flux anymore. It's like Vuex, maybe flux. I’m not sure. But flux is over-complicated, and we realize it now. I mean, just in years. I think, it's something that work with touchscreen. I really want to experiment with this idea. I've been experimenting since the composition API, which did open a few new gates for the developers, for us to pass data around and simplify things quite a bit, while still having the TypeScript, automatic incurring a TypeScript everywhere, pretty much, which wasn't the case with APIs, like the one with Vuex 4 and 3.

I mean, 3, because you have these magic strings and you inject everywhere. You have a dollar store, but your application is not aware of the type of the store, unless you explicitly put it somewhere. We have a composition API that's no longer a problem, because you have functions that return something, so everything is pretty much impaired all the time. The idea is to leverage that and make sure that the user can enjoy not only a TypeScript score, but also articulation with the least amount of effort from themselves.

[00:05:36] AR: Okay, cool. Pinia is like a composition API style thing. Does it work with Vue 2? Or is it only Vue 3?

[00:05:45] EM: It works with both Vue 2 and Vue. It has the same API, except for the installation, which is different in Vue 3, because you had to do an app that use and in Vue 2, you do vue.use, and you also have to inject the Pinia. That will be the root store for Vuex. You have to inject it at the root of the application, the same you do with the router and the store, which by the way, it's pretty much the same API. You use a plugin and you inject the instance and the route, and is the same change from Vue 2 and Vue 3. Thanks to the completion API library, it works for Vue 2.

Unfortunately, I have to maintain two code bases, because I have few differences that I am afraid I will – There are a few differences, I cannot get working, because I don't – the same features do not exist on Vue 2. For example, on Vue 3 on the watchers, you have a debugger event. You get only in dev mode, you get a lot of information about what changed, and how. You can use the information in the dev tools, and provide a lot of information about what was the past state and the new state, or the partial past state and partial new state that annotations is having, is changing.

[00:07:00] T: It sounds like it's use specific, like I couldn't use this in Angular, or Svelt, or something.

[00:07:05] EM: It's really tailored for Vue. I never thought about using it somewhere else, because I don't really care about the other frameworks.

[00:07:14] AR: On this show, that's okay.

[00:07:17] EM: At the same time, I, of course, if I'm working on Vue, I'm not going to worry too much for the other things. I think, the principles could be adapted to other frameworks. They're really not complicated. Remaps to a component, a Vue component, though, like methods, data and computed as pretty much Pinia store.

[00:07:37] AR: Okay, cool. Now, you were saying, so with Pinia, you still have to inject it at the top level, you were saying. Is there any benefit to using outside of the obvious TypeScript hinting definitions and all of these fantastic things, is there anything that makes it better, or different from using Vuex? What about it is going to be the thing that goes, “Oh, okay. This is why I should use Pinia, instead of Vuex.”

[00:08:11] EM: One of my ideas, also with Pinia is to bring some of the good practices I've accumulated, or seen a first project, or brought through other projects. I designed the API to make you work out of the box, so to say. For example, everybody divide – I mean, not everybody, but most applications, divider their stores and modules, because it helps to keep them organized.

Nesting modules is something that is often, I've seen in more complicated than actually useful in code bases. Module is something that most code bases that were successfully explaining their logic and using a store, having actually enjoying using the store were doing. In Pinia, you have the modules. Everything is a module, basically. Also, something that people were doing was dynamically registering the modules of the store. You had to do a lot of extra code to make that work. It didn't make sense, because the same way you lazy load a page, you want to lazy load the store with it.

In Pinia, the way it’s designed is that, by its usage, the way it's used is going to be lazy load automatically, so you don't have to do absolutely anything. All those stores are like modules. They are separated. They are different from each other. You can also use them into each other, so to say. The only exception being cross-usage between two modules in which scenarios you probably have to create another store that references both of them. That's the most advanced use case, I think, for this scenario. Apart from that, it also brings all the pain points that you had in Vuex. Everybody was complaining. Not everybody, again, but most of the –

 [00:09:53] AR: I think all of us are complaining about some things in Vuex. Yes.

[00:09:57] EM: Yeah.

[00:09:59] T: Yes. Even my hamster is complaining about in Vuex every night.

[00:10:03] EM: VS code complains a lot about the type errors also. No, but the mutations was a topic that people – I've seen so many discussions that didn't make sense. The whole thing at the beginning was because of the dev tools. It's also, because it comes from flux, the implementation. You won't have a centralized solution that is patching with the modifications to the state. That’s the mutation.

Why do you need that? What is that code utility of things? One of them was the dev tools, being able to track every change and being able to have some timeline, or being able to apply the changes in one after the other. We don't really need to do that with the proxies. Because the proxies, we can detect whenever you change something, or you write it somewhere. Vue, its code already does that. I don't even need to do anything specific in Pinia’s code. 

I mean, a few trades there, happen there. Everything is mostly just Vue 3. So limitations, people were sometimes even creating actions to call mutations. I've seen projects with people forcing themselves to never use mutations, nor state. They were never directly accessing the state. They were always creating getters, and actions to call just a mutation. Not only mutations are by design, extremely or both. Because very often, you're just saying state.user equals the payload user that you pass as an argument.

Sometimes you're doing a push. Sometimes if you're lucky, you're doing a find, and then you're removing something. Oh, yeah, three lines of code that you mutation. Now, it's actually useful. Most of the time, you do the setting things and removing things from the state. Having to pay an action for that, and then call the action increases the verbosity and more. Then the getters, if you're not doing anything to a state, it's the same. That's twice the amount of verbosity for nothing at all, because it doesn't bring anything to the dev tools. It's just a convention that you can choose to follow, and that we never even encouraged in the recommendation.

[00:12:18] AC: I like to create entirely new object structures within my state by using Vue.set a lot, just to make things confusing for everyone. It makes it a whole lot easier to look things up. Just saying.

[00:12:32] EM: I mean, still a good use case. I mean, there are a lot of cases, like cache with entries. You need to use Vue.set in Vue 2 to make it work. In Vue 3, you don't need to. Yeah, you don't have to. It's pretty normal. I would say, 3.

[00:12:47] AC: Okay, good. Because here, I thought I was abusing it. But I’m like, “But it works.”

[00:12:52] EM: Abusing Vue.set. I mean, you can actually abuse Vue set, because it does have a performance currents, that sometimes you don't have another weight. I guess, it's completely fine.

[00:13:05] AR: Yeah. Yeah, there are definitely times that I've done some things where I've gone back and looked at it and gone, “Oh, Alex. Why did you do this? Why?”

[00:13:14] AC: I mean, we've all been there. Event bus.

[00:13:20] EM: Event bus on me. Yeah.

[00:13:23] T: Not me. No regrets.

[00:13:24] AC: Here, I thought I was making a mistake. What mistakes do you see people make with Vuex pretty commonly? What anti-patterns do you see a lot?

[00:13:35] EM: I’ve seen people not use Vue.set when they needed to. Breaking the review chain very often, and not realizing it’s broken. I've seen people putting state that should be in a component, the store. Something that is – I mean, probably overwhelmed and they want, but at some point.

[00:13:56] AR: You go, “This is going to be used everywhere,” and then it never is.

[00:14:03] EM: Exactly. The space where for every still very mature. You cannot mess up too many things, because there are not that many places where you can mess it up.

[00:14:14] AC: Follow-up question. Does Pinia in any way discourage some of those bad practices?

[00:14:21] EM: Nope. I don't think those ones are discouraged by any storage solution. Because I think, any store solution, you can still put things that you don't need.

[00:14:30] AC: You have to give them some room.

[00:14:33] EM: Yeah. You can make the lemon that easy. You have to give people something to mess up and then be happy about fixing the bugs.

[00:14:41] AR: It doesn't matter how much structure you give someone. Someone's going to figure out a way to do a bad job at it.

[00:14:47] EM: Oh, always.

[00:14:48] T: We can make a VS code extension, like clippy for Pinia that every – like Pippy. Every time somebody goes to put something in Pinia, it's like, “Are you sure this belongs in Pinia and not in your component?” Every single time. I'm sure it won't get old.

[00:15:03] AC: I mean, I feel that might be good training wheels to be totally honest, just to make sure people are considering things. Eventually, they could probably disable it, because it's in their head anyway, every time.

[00:15:16] T: Yeah. Before we get too deep into Pinia, one thing that I was curious about, because I feel some of the changes we're talking about are things that I had heard might go into Vuex 4 originally. We talked about why Pinia, but I want to know why Pinia, as opposed to there was some discussion with people thinking they could use the composition API, instead of Vuex, just completely switch, or why not make these changes as a fork of Vuex?

[00:15:45] EM: It cannot be a fork of Vuex, because the whole structure is completely different. The whole architecture is completely different. It will be a waste of time to refactor that code. It will make more sense to complete your writing and decide that the code base for Vuex is now that the – does have many lines of code.

Comparing the store like Vuex, or Pinia to the composition API, the difference is mainly about, I will say, server-side rendering and dev tools. Those are the two main things that you will not get if you use the just raw composition API. Because that's pretty much what Pinia is doing is telling the server-side rendering for you this organization, and the dev tools then to help you deadlock. The composition API used should still get most of the typing out of the box. You can create functions. You can create a state with a ref, or a react even, then just put things and work with that. That won't work for server-side rendering. You have to create something to make it work. You have one state, one request. For each request, you have a new state generated.

There is another problem. Right now in Vue 3, the place where a ref, or reactive is created, is problematic. It’s going to tie the lifespan, or the reactivity, or just to say, make the thing work to the component where it's called – if it's called inside a component. Right now, you call ref, for example, to create a data inside of the setup of a component. Once the component is destroyed, so imagine you navigate from one page to another, the whole Vue is steered down. The object that you had, that you created inside of the setup, if you somehow save the reference somewhere else, which will be the case for a store, because it has to be global, so you want to keep that state across different pages, that's they won't be reactive anymore.

You got broke tier down by the component, because it was tied to a component. There are a few exceptions, because I'm not completely sure, but I think that Vue is smart enough to move some of the references that you create. If you put them in another context that is global, they're going to make the ref global, so they're not going to be tied to the component. I'm not completely sure about that. I don't want to create any assumption on that one.

That's another problem you find, is that if you want to create your stores on the fly, as you need them, instead of creating everything from the very beginning, which you can have a cost, you cannot really do it, unless you have to get into very dirty hacks to be able to create the state of a store dynamically, based on some page being visited, which means creating a component. You will have to create a state outside of the component somehow before visiting the page, if you have the router. If you don't have the router, then good luck with that.

Then you have also the computer, which they are created for the getters. Anything else, you attach the store, if you attach, reference these inside of a component. You can lose it. Yeah, that's also something that can fail.

[00:19:07] AR: Trying to do it just from composition API standpoint, and provide injecting it, you'd still have to define everything at the top level of your application and have it trickle down. You wouldn't be able to effectively, like if you're wanting to be sibling components, then whichever sibling component creates it would potentially be the one, if that sibling component gets destroyed, it would screw up your data for everything else, basically, is what you're saying.

[00:19:36] EM: Yeah. Especially for the computed properties. If you create a computed property, instead of a set of function, which can happen indirectly, then that computed property will no longer be reactive if the component history. In Pinia, what I do is I recreate store. I recreate a computed. Every time you code Vue store, which is a bit expensive, but I don't have a way yet. I mean, I use a small optimization where I provide the store, if I can, so it can be used by others, but it's not perfect. The idea is to have these API call effects scope, which is in the RFC, and Vuex is waiting for that RFC to be published. Pinia will adapt. I mean, we use the API once it's out also.

[00:20:22] AR: Cool. Yeah, this is really –

[00:20:25] EM: Dev tools, you may need to see them for yourself to actually –

[00:20:29] AR: Wait. Now, do I have to go install separate extension for the dev tools for this thing? Are you saying that it's included, works with the Vue dev tools?

[00:20:38] EM: It works with the Vue dev tools. The funny thing is Pinia initially, I hacked into the – I mean, hacked. Didn’t hack anything. I just read the source code of the dev tools in Vuex and I hijacked, that’s the word. I hijacked the different hooks that were being called by Vuex and the dev tool, so it basically replaces Vuex dev tools on the old dev tools. It works even within with the replace state and everything. That's funny.

The cool thing is with the new beta that Iyom has been working on for so long, because you have an API that is exposed, you have another package called dev tools API. Any library can use that. They can add anything to the dev tools. It's pretty cool. You can add state to components when you inspect them. You can add your own inspectors, for example, for the router, you can see a book of all the routes, and you can try to match them. You can see which one is active, if there is any, and you can search them. You can test parameters and stuff.

You also get to add custom tags on the tree Vue of components. You can add custom actions now as well. That's pretty cool. For example, on the Pinia dev tools, download the state of the JSON, or upload. Upload. We don’t really upload, but you give to the dev tools that JSON file, and it loads the state. All these was created by Iyom, and then I think that we're getting some feedback as we're using the API. I was so excited when he came up with the idea, and with the first version that I use for the router and being able to just have the control from the package about what is happening in the dev tools no longer having to do a pull request in the dev tools, wait for the dev tools to emerge, release a new version of the dev tools, which I know it's a pain point for Iyom, especially on, I think Firefox is a pain for it.

They are behind in that new version, because it takes so long. Probably depends. Usually, it goes fast. Oh no, no. With Firefox, you can download it. It's even worse, because is he still waiting to be able to publish on the marketplace, marketplace, or whatever it's called, the plugin store.

[00:22:58] AR: Interesting.

[00:22:59] EM: There is another feature, which is a timeline, which is really nice. It looks really cool, too. You have a few dots that you can see in a timeline. Basically, dev tools by themselves, over you have component events. Now he just added performance. You can see, it's pretty much a flame chart, but for your components. You have component events, keyboard events, and you can add your own timelines. You can add events them and add state to them. You can add actions to the state, because it’s the same kind of state that you add to a component. You have a lot of APIs that just look the same. You can even group actions, and you can have multiple layers of actions running at the same time, so that's pretty cool. This is very abstract, just saying the words. One needs to see a screenshot of it to make sense.

[00:23:44] AR: Yeah. I feel like, I need to go get the beta of the dev tools and play with it and really can –

[00:23:51] EM: Yeah. It works for Vue 2 also.

[00:23:53] AR: Oh, that works for Vue 2 now. Okay.

[00:23:55] EM: I think, it's a bit slow. I tried it with a few applications and may have some performance issues, but I think demonstrating, figuring that out. For Vue 3, it works very well. It's pretty powerful.

[00:24:10] T: I heard a lot of the major browser vendors are working on establishing some global API for browser extensions, so that theoretically, you could write one, and it will work across all of them. Hopefully, that would make things easier and not harder, in the future.

[00:24:28] EM: I think, it was a – I mean, I'm not an expert on the extension topic. Iyom would. I remember that it was Microsoft four or three years, three years now. Yeah, two or three years ago. They told me that they started something like that, an initiative to make all the browsers have the same extension API. To a certain point, they do have things in common, or you would have some of the APIs that are the same. As a matter of fact, the dev tools API, like Iyom developed, where it’s – I think, it’s the same codebase for Firefox and then Safari, I don't know. Safari is very special.

[00:25:08] AR: Yeah. I think, Safari has some extra swift stuff that you have to wrap around it, or something.

[00:25:14] T: What was that? It's faster? Is that what you said?

[00:25:20] AR: Server-side rendering and routing. Is it like, it's easier to subscribe, or add a store per route or something, or it handles that better?

[00:25:33] EM: It's transparent, I would say. You don't get to think about it. You just import the functions. You just import the stores whenever you want to use them. They are functions, so they will handle the server side rendering automatically. Because you call the store wherever you need it, and then you lazy load at that route level, the code splitting would just come out of the box for free, so you don’t have to do anything. You don't even have to think about it. The dynamic registration, registering stores is also automatic. You don't have to think about it.

[00:26:05] AR: I don't. I don't have to do any Pinia.load module name –

[00:26:12] EM: You actually almost never use Pinia. You create Pinia and you do that to the root app and that's it pretty much.

[00:26:19] AR: That’s it. You set it and forget it and then never use it.

[00:26:23] EM: Yeah. You can use it for to manually use that store outside of any setup function and everything, because that's how you would recognize this. Because you create one Pinia instance for every application that you run, for every request on server-side rendering. You create one application and server-side render for every request. You create a Pinia instance as well. That's what is used to gather all the states of all the different stores together and to make sure that you use the same state for one application. You can still use the same Pinia for two applications if you want and share the state. You can share the same state on two different applications running on the same web page, for example, if you have two applications running on more portions of the page, and still having one single SPA.

[00:27:10] AR: I have an entire demo solitaire application that uses Vuex in that manner, that have four – it’s four or five different Vue instances on the page, and they all share a Vuex store. It'd be interesting to switch it over to Pinia and get more modularized. It's not even the entire – each application uses the entire thing. It only uses the pieces that it needs to.

[00:27:33] EM: Oh, yeah.

[00:27:34] T: This is making me want to have like, how there's awesome Vue, for example, to show you different ways that people are using Vue. Different ways that people are using Pinia and different interesting architectures that they set up, and you could call it like Pinterest or something.

[00:27:48] AC: Oh, my God.

[00:27:50] EM: That would be fun. I will look to that.

[00:27:51] AC: How would you spell it?

[00:27:55] EM: How will you spell what? Piniasome?

[00:27:58] AC: Pinterest. Because it would literally be Piniaterest.

[00:28:03] EM: I do try to keep an eye on – I tried to do some searches on Discord, I search every day for Pinia, just to see if people are asking questions and see what they’re doing. Because I wouldn’t have a channel, like the router where I can keep an eye of problems that people are raising and see what improvements I can come up with in the API. It does take more time than – it's not the return on investment. Will we say that in English? It's very low, I’d say. Still interesting, I think. We still work to get that. I guess, the 20% for the 80 – Just trying to get to the last percent of –

 [00:28:42] T: Yeah. Are you using Pinia in production?

[00:28:46] EM: I don't have any application in production myself. I work for clients, and I know people who are using it, but I don't have my applications. I know the problems well, because I work with different clients. I've seen different applications. I've seen different ways of doing things. I face the different problems. I face different teams, different application architectures. That's what I use. I use that knowledge to build the APIs that could work in all these scenarios. 

Then, I try to share with the world. Pinia did take — people really enjoy Pinia, because I think people were suffering from, they were both the applications, who are dealing with the mutations and having to write all these functions and having to use the caps lock so often, because people like to use the patience in caps lock. You don’t need to, by the way. You can just call adaptation, set something and you can call an action, the same name as a mutation as well. They will never act like, because that's –

[00:29:47] AC: But they'll collide in my brain.

[00:29:49] T: Oh. I like to try to make it make some sense on how they share the same name. I'm like, “Yeah, one is the action version anyway.”

[00:29:57] AC: Yeah. If they're the same casing, nope. Done for.

[00:30:01] T: Oh, man. Imagine if you had – if the only distinction was the case, one is lower case, one is upper case, you just got to remember which is which.

[00:30:09] AR: Well, you see with these, we camel case these. With these –

[00:30:14] T: Screaming snake case.

[00:30:15] AC: Screaming snake case.

[00:30:16] AR: We underscore, snake case them. Yeah. That's the difference. They're both lowercase, but outside of that, it's –

[00:30:24] T: I was curious if you could talk more about like, how do you make that transition from some experiment I'm just trying out on my own, to this is something that people can use at their company? Because I feel like you've done that with Vue router, and you work on Vue. How do you know something is ready for production, if that makes sense?

[00:30:43] EM: Is it a gut feel? Is how that many would say?

[00:30:45] T: Yeah, gut feeling.

[00:30:47] EM: Intuition will be the other, I think. You can actually measure some of these things, but you don't need to, because it depends on the surface API that users are going to use. For example, with Vue 3, or Vue, people are going to use it in very, very different ways. They are always going to find different parts, like edge cases that were not thought about. When Vue come out, Vue 3 came out, there were a lot of bad reports in the beginning, and there are still some bad reports. Most of them were edge cases.

With time, we're seeing more edge cases, analyze critical bugs are the same. With things like the router, the router is also special, because it's even complicated, but the smaller the API is, and the more specific your library is to a specific part, section of your application. To say, so for the for example, the state management is one section of the application. The routing is one section, but instead of the routing, you can use it out of the other things of the application, like some classes too, some styling. The state management can also go. You can also interact with it inside of the navigations.

There is more room for bugs in that aspect. For Vue, you also have the compiler. You have so many things. The code base for Vue is very complex. It has a lot of things. The code base for Vue router is so far from that complexity. Pinia is even less. The code is a bit complicated, because of the TypeScript things, and the generics, but that’s TypeScript life.

When I was working on Vue router, and I was checking the download, see if people download the new version. Then I was checking all the bug reports by people. See, people were finding bugs. I was trying myself. The way I think, I really think about all the edge cases in my mind, just because I like seeing all these possibilities in my brain. I think, I found all the edge cases by just thinking and just spending time, just time passes by and I'm doing something. I think about, oh, I could do a return of rhetoric here. At the same time, I will click here, and it will do something else and maybe it breaks and I check it and maybe it breaks and then face it.

I think, I had a lot of bugs like that. Then I was seeing that people were reporting very few bugs. I consider that, that make your router stable. I also spend more than a year working on the router, on the rewrite. That gave me a lot of time to think about the cases. For Pinia, it’s more complicated, though, because it doesn't have that use base. Router has a lot of downloads. It’s the de facto solution for routing Vue. Of course, people are going to use it.

Pinia is not. It's not a de facto solution. It’s just an experiment at the beginning. You only get a few users that are adventurers. Usually, they're also more experienced. You can base yourself only on that metric, right? Because these people usually know [inaudible 00:34:12] could write well, or do not make beginner mistakes anymore, know how to debug problems. At the beginning, it's a bit hard, because you only get users like that. Then, you get a few users that are more beginners and you can see the library from another perspective, you were not used to, because also, as you're developing something, you know by heart, this application library doesn't matter. If you don't see the problems with the implementation you have or the APIs.

I was checking the downloads, and I was seeing that a few people were using it. The beginning, not a lot of people were using it. I was just using it in my own projects, my own pet projects. It's just because I like to think about the different possibilities, the different ways to use an application. I spent time designing the applications as well and thinking about all the different versions of usage I can find.

For Pinia, it was basically just research. I was just doing the research until I felt happy with the final API that resulted from that. That's when I tried to do some more publicity, like talking more about it, so people could use it, if they like it. I was getting an eye everyday to the issues, to make sure that I could resolve any bugs, so we wouldn't block anybody. If I see a bug report, I can merge it right away and redo the patch right away, then they can keep training the library. I will keep them from dropping and just giving up on the library, so they will test longer. I think, I did the same for Pinia for router, but less people.

I was seeing that there were now bug reports, people were asking us questions, and the condition was getting, covering more things. It got to the point where people can actually use it. I think, sometimes you also need to push the thing a little bit, because if you want to get more users, you need to announce things. You need to talk about the thing, and you need to say, “Hey, yes. You can use it.” If you keep your thing as your library as something that is not ready for production too long, while other people are just going to pass by and not use it. Not even for the pet projects, because most people don't have that project document.

[00:36:28] T: Even though my hamster keeps screaming about Vuex, as we all know.

[00:36:34] AC: I see what you did there. Pet project.

[00:36:38] T: Yeah. I think, I first heard about Pinia when you tweeted about Kelly Mahoney designing the logo. Speaking of the docs, I don't know if this is the edge case you mentioned earlier, but one thing that I found a bit confusing was in the composing store section of the cookbook, where it's talking about two or more stores using each other, versus one store using another store. Is that store A is using store B and store B is using store A? Or store A is using stores B and C? I'm not sure if I'm asking my question clearly. I'm just confused about the difference between two or more stores using each other, versus store using another store.

[00:37:17] EM: What I call composing stores. I’m having stores that use each other and there is one route to follow. Yeah. Have to read my job sense. If we have one store that uses another store, and that store doesn't use the first store, you can just – it's like nesting, basically. You can call, use my other store inside of my first store, inside of actions and getters. I was thinking of adding stores option, like Vuex 5 maybe, allows you to have access to the stores. I think that will also allow the cross-usage between two stores, those two stores using each other without having to create a third store.

I'm not even sure about the rule. I know that at some point, it wasn't necessary, because there was something that wouldn't work otherwise. I'm not completely sure if it's still the case. The idea is if you have for example, a user store and a card store, you might need to use both. The cards are inside of user store and the user inside card store. The idea is to define a third store that does all the actions and everything that requires to have both stores. I need to stress test these a little bit more. It's more of a safer approach, I would say.

[00:38:32] T: Because there's not quite a circular dependency. It's more a circular, or a Mobius –

[00:38:36] EM: It’s circular. Yeah, that’s the word.

[00:38:40] AR: Yeah. Yeah, you don't know if your circular dependency is going to be is good. If I have a getter that's using a getter from another thing, then that getter is using something, that same getter from the first one, then –

[00:38:51] EM: It could create a MP.

[00:38:53] T: I mean, speaking of dependencies, how do you balance all of these different open source projects, and then your client work, and then also your life?

[00:39:03] EM: I'm getting to a good point now. I wish I could learn more from other people. At this point, I'm taking maximum three days of bed work, assigned work per month. Sometimes I take 10 days, and then I don't work for with four clients for two months, or three months. I try to rely on my collect – on my meetup sponsors as much as I can. Then I have some affiliate program, so that's great. I started this year. No, last year. Like the ads, and then having some links, some documentation. Other companies, like useful Vue mastery, who use Vue router, they need some of the money back. That's great.

I wish big companies are – that company is using Vue and building components on top of Vue, and they are just giving back very, very little. Even though they are selling libraries of components using Vue. They have a sponsor maybe, or something like that, just to not shame against. I don’t know. I try to be quite strict with my social life. I mean, the rest, my non-work, like after work, I try to stop at 6, 6:30. I try to not work on weekends. I don't have these addiction to the GitHub notifications, I think. I could check them. I check the application very often.

I take holidays, I try to disconnect. I don't take very often holidays, but I try not to look at application, or not open the issues. Still, if I have a blank, like it’s the same when you go to totally, then you're looking at Instagram or something. Well, I look at GitHub applications instead.

[00:40:48] T: More like – hub. Sorry.

[00:40:51] EM: Yeah. That goes issues from the throne. As you say what? Sorry?

[00:40:56] T: I said, more like – hub.

[00:41:02] AR: This is why we can't have nice things.

[00:41:06] EM: I do try to get to work the most on open source as much as I can. I think, it's important. I think, it will keep working for a client from time to time, because he helps me to dial again in application, see how people are using the things at Vue and see the problems that they are facing by myself, because I will face the problem they're seeing. I think, that's very helpful. It's interesting, because it's a frustration. I get the frustration of working there. Also, they are expecting a lot from Vue, because we are the core team. You should know everything about Vue.

[00:41:39] T: That’s the law.

[00:41:42] EM: That’s the law. It’s true, I do know a lot of things, and something I like, all the problem-solving front-end applications. I've been working with Vue for a long time. Of course, there is a lot of things that I've seen. That experience is very useful. It's frustrating. You have all the bugs and everything. You're working on a codebase that you don't know. You work for just a few days, and you try to figure out the problems that they have had for months on a codebase that you don’t know.

It's quite tiring, I would say. That's why it's important to also have the life balance. I think, other developers like Evan Yu and Iyom probably do these very well, too. I don't know how well. I'm pretty sure that Evan Yu handles these very well. That I remember he talked about it. He said a few years ago, already he was handling these very well.

[00:42:37] AC: We all know, Ben is not though.

[00:42:40] EM: I’m dealing with this all the time. He's always there.

[00:42:47] AC: I literally booked time with him just to make him take a break.

[00:42:52] EM: It’s not bad. Very nice of you. Depends on the people. Different people like different things. The interactions you have in open source are not always nice. It can also be tiring that way. You don't know how people are trying to communicate with you. Also, the body languages of older people and how people communicate. I've grown from that a lot. 

Sometimes I was taking things very – not personally, but I was getting offended by things, because it was hard. Even if you know the other person doesn't speak the language, sometimes it's not clear.  If there are short sentences, they can be very rough. Having that in the morning is the worst, because you don't want that energy, very beginning of the morning, of the day.

[00:43:38] T: Which might be the end of the day for them.

[00:43:41] EM: I think at the end of the day, is also bad, because you don't even –

[00:43:43] T: Just any time of the day.

[00:43:44] EM: - deal with it. You're like –

[00:43:45] AR: Yeah. You're thinking about it all night. Then you wake up in the morning, you're still thinking about it. You're like, “Ah.” You’re having your coffee and you're like [inaudible 00:43:52].

[00:43:54] EM: Being able to disconnect from that and doing other things is nice, too. There is a nice feeling of letting go. Not feeling the need, or responsibility to immediately answer an issue. I think, I haven't been able to completely let go of that thing. I feel like, Evan did a long time ago.

[00:44:14] AC: I think, that's probably a fair assessment.

[00:44:18] EM: It's like the notifications on Twitter, or Instagram. For example, Twitter, I completely let that go a long time ago. I don't care at all about the follower count, or the notification, or the retweets, or the likes. I really don't care. I don't do anything to really engage too much. I only engage in things that I find interesting and I want to discuss, and mostly about computer science, I mean, programming and web development. GitHub notifications, that’s a whole different story. It really hits spot for me, I guess.

[00:44:50] T: Wow. I don’t look at one at all.

[00:44:51] AC: I know.

[00:44:52] AR: If we need to get your attention, we should file an issue somewhere, just being like, “Hey, do you want to hang out?”

[00:45:01] EM: It would work.

[00:45:05] AR: Cool. All right, so with that, Eduardo, where can people find you on the internet?

[00:45:11] AC: The answer is GitHub.

[00:45:15] AR: Yeah, but where specifically on GitHub?

[00:45:18] EM: Yeah. Now on Twitter, my handle is Posva. I do check the Twitter, or even though I – I check it every day. Also, on Discord. I’m there very often. I check Discord everyday as well for questions on Vue router.

[00:45:32] T: The Vue land Discord, right?

[00:45:34] EM: Yeah, Vue land. I’m sorry. It's chat.vuejs.org. That's the link to join. On GitHub as well. One my favorite place.

[00:45:43] T: Wait, before we continue, I want to know, because I realized, I've always had this question I've just never asked. Why Posva?

[00:45:49] EM: Oh, it's a very old thing. When I started having a nickname on the Internet, hopefully 11 or 12. It's something in Spanish from a small TV show that was fun. That was called [inaudible 00:46:01]. The name doesn't really matter. It was just a show that was funny. There were two guys that were in body rolls and do sketches. They don't do it anymore, but it was on for a long time. In one of the sketches, one of the other guys was an old lady. I was always answering, "Posva Serkino", which is just, it's not going to happen. No. It's just going to say like, no.

I use that altogether. It's also misspelled in Spanish. It's just a version, like the correct way will be posva serkino. That version is a little bit contracted, like the same way you said y'all for you all. See much of that, right? It's posva serkino, which is pos, instead of poise. It was too long. One day, one guy called me Posva and I was like, “I like this. This is short.” I started using that one everywhere. I’ve seen people named Posva with the last name, but I'm still friends with [inaudible 00:47:05]. I'm sorry. I’m sorry, even Posva. I think, because it’s a real name of family, too. I mean, [inaudible 00:47:15].

[00:47:17] AR: Nice. All right, so it is now time to move on to this week's pick. Ari, do you want to go first?

[00:47:26] AC: Sure. I can go first. By the time this is released, this will have been long in the past, but there's always next year. The Eurovision Song Contest. I watched it for the first time this year. It was so much fun. Most of the songs are so campy and I love campy stuff, so much. Some of them were legit really good. I actually downloaded them and listened to them in my car. Just the production value is so good. It is so over the top. There's what? 20 something countries make it to the semi-finals and each country has to do a three-minute song. Then in the finals, people vote, as well as I don't totally understand this, but each country has a jury and they assign points as well.

It's a very complex system, but it also makes it that much more exciting when you're watching the results come in. I didn't think it was going to be that interesting watching the results, but oh, my God, it was. Yeah. I'm sure you can find videos from past ones as well. There was also that movie on Netflix based on the Eurovision Song Contest that I think I used as a pick last year. If you ever get a chance to watch it, highly recommend. So much fun.

[00:48:41] T: I think I used it. Yeah. I heard that this year, they got the Yeah, yeah, Ding Dong guy from the movie.

[00:48:47] AC: Yes. No. That part was so amazing.

[00:48:52] AR: All right. Apparently, I need to go watch this movie now. Talking about.

[00:48:57] T: The music is very catchy. Just warning you in advance.

[00:49:00] AR: Good to know. All right. Tessa, do you want to go next?

[00:49:03] T: Yes. I'm ambivalent about both my picks today. Lately, I've been playing this game, Overland. I believe it's a rogue-like, a rogue-like-esque. If it's not rogue-like, it has to be a rogue-like. It's a post-apocalyptic game where you're traveling across the US. I guess, you're just trying to get to the other side. I don't know. There's not a good story –

[00:49:25] AC: Is this Oregon Trail 2? No. Sorry.

[00:49:28] T: It's slower. It's like a puzzle game. Also, I heard the Oregon Trail release on the Apple Arcade is really good. Because they consulted with indigenous people. Yeah, basically, you're traveling with comrades, or not, your choice. It's like Traffic Jam, or any of those games, where you're in a tight spot, and you're trying to get from one side of the map to the other side of the map. I can't really say that it's fun, but I keep playing it. There's my endorsement for that. The design is nice and there's dogs. If you like dogs, well, there you go.

[00:50:00] AR: Can you pet the dog? That's the question.

[00:50:03] T: You can't. You can't. Oh, wait. Yes, yes, you can. You can pet the dog.

[00:50:06] AR: Yes. All right. I’m in.

[00:50:07] T: Clearly, I have not yet pet the dog, but you can. Then the other recommendation is Hori has released a line of Nintendo Switch accessories. Right now, I'm trying out this Switch Pad Pro with the Pikachu Eevee edition, which I think the colors are super cute. I also think, maybe it's better for bigger hands, or if you tend to hold the controllers in a different place. Because the shoulder buttons and stuff are a bit high. It is more comfortable for my palms to hold it in the default controllers. Yeah, they have two different ones for that. They also have special joy cons too, but only for the left side, which is weird. Yeah, those are my picks.

[00:50:50] AR: Cool. Eduardo, do you want to go next?

[00:50:53] EM: I don't have many picks. I only have one. This is a game called [inaudible 00:50:57], which is completely absurd. Really cute. All flat colors. It’s on the Switch. Apparently, it’s on other platforms. Again, it was in Steam. I don't know what [inaudible 00:51:07] is.

[00:51:09] AC: I don't know what GOG is either, but I just put it there.

[00:51:13] EM: It's a small game with a funny story. Completely absurd, very short, all public and have a few memes inside as well. With some physics, very round shapes, all around. Very colorful as well. It’s a very happy game overall. If you want to have a break. Really nice.

[00:51:34] T: Yeah. I'm going to try that.

[00:51:35] EM: Not too hard, either. It's not very expensive either, which is fun.

[00:51:40] AR: Awesome. Well, that leaves me and my pick this week is a book. I actually got all the way through a book, which is super surprising and amazing. You know it's good, maybe. I had the Audible edition of this. The book is Shadow and Bone by, I'm going to butcher this name, Leigh Bardugo. It's fantasy. A little bit steampunk, because there's rifles and stuff. It's not high fantasy where it's goblins and elves. It's all humans, but there's magic. There's treachery and it's great.

It's great. It's good fun. They recently released it as a show on Netflix. I have not watched the show. However, my wife has been very excited about the show and has read all the books. I was like, I will get through this book. It was good. It was quite enjoyable. I'm on the second book of the series Siege and Storm, and maybe that will be a pick in a future episode once I finish it. Yeah, that is my pick this week.

That's all for this week's episode. If you aren't following us on Twitter, head on over and find us @enjoythevuecast. Be sure to subscribe to the show in your pod catcher of choice. If you have time, leave a review. It helps us out a lot. Finally, the first rule of Vue club is tell at least five or six of your colleagues about Vue club. 

Thanks for listening, and until next time, Enjoy the Vue.

[OUTRO]

[00:53:31] BH: You haven't heard from me for a while. I started a thing a while ago, where people were sending all sorts of feedback and sometimes stuff not even related to the show. To @GloomyLumi, you need to stop. If you have feedback, we have a link in the show notes. Send your feedback there. We want to hear from you. You can make the show better. Tell us what you want to hear more of and who you want to hear from. Okay, that's it. Thank you.

[END]