Documentation and Migration: From Vue 2 to Vue 3 (with Natalia Tepluhina)

Hey, everybody. Welcome back to a new episode of DejaVue. It's your favorite Vue podcast, you just don't know it yet or maybe you do because that's already one of our famous episodes. We do quite some, maybe we've seen some of Daniel Roe, Evan You, lots of other amazing guests, and today it's it's a different setting, right? You don't see Michael here, unfortunately, we can't fly him over from, Canada real quick, but maybe another time, like, a live episode, we'll see.

Thank you, Alex. I'm doing good. How about you?

Fine. Yeah. Can't complain. Had a little bit of, work to do in the mornings, had everything up here, maybe get some behind the scenes footage on some social media, we'll see. But, yeah, happy that, everyone found out that you're here, as we only live, like, 20:30 minutes,

by the way. Yeah. Just so you know, we don't measure distance in Amsterdam in kilometers. It's not practical. We measure in minutes by bike.

Yep. That's very important. So, yeah, it's great. And, for everybody who might not know you, probably not that many people, but so you're a principal engineer at GitLab by day,

yes, that's correct.

So, we'll all talk a little bit about that as well and, as someone who MC ed for you at at Vue.js Amsterdam sadly forgot to announce last time you're also a Vue.js core team member for for how long by now?

Since 2018.

2018. Wow. It's awesome.

Like, 6 years.

Quite some time.

Yes. It was a couple years before that. It was, in early 2016. I think Vue two was in beta at this point.

Wow. Okay.

Was released, again, if I'm not mistaken, in September 2016. So we started using it first for I started using it for pet pet projects, then brought it to my workplace at the time Mhmm. Just when it was released because management was pretty critical about having something in beta. But it worked super nice for us. Before that, it was mostly Angular JS.

Oh. Like Angular 1?

Yeah. Uh-huh. Yeah. Not not the cool Angular. And Vue was really, like, a fresh air there. So, yeah, after the after this, I think I only used Vue at my workplaces. Yeah. Vue and then a bit of Angular again.

Interesting. Okay. So how does it came at you? Like, said, okay. Let's introduce Vue 2. Let's bring a bit of fresh air in there when you were using AngularJS.

So that was a small company doing project work. It wasn't one big thing. It wasn't a product that you work on. You didn't need to do a migration. We just had a new project coming on, and we just decided to give it a try with Vue.

It still is.

I didn't write it back in time, so don't take it as a compliment. It was Chris Fritz mostly working on the docs. Everything was quite intuitive. And, again, coming from AngularJS, it's quite easy to have the same directives. Right? It was ng-if to v-if and so on and so on. But much better work on the script part, and it just came very simple. The project was done super fast, and we decided to just go with it because it allowed us the speed of development.

Yeah. Makes sense. I also, like, I heard some people, like, using Angular than going to just, like, a bit of, like, baby Angular. It's like it's more lightweight. It's a bit easier to grasp.

Maybe also for bigger teams back in time, it was a good idea again because it's very straightforward. You cannot do step left or right. But if we look into the learning curve and, again, small company, many new engineers, we were just curious about things. The learning curve for Vue 2 back in time was super, super smooth.

Yep. That's true. Like, if you know HTML, JavaScript, and CSS, and even if you don't have, like, experience in in the framework before, like Angular, it's, it was it goes pretty well. And Yep. I think today, it's, still the case, even though there there are, like, some hiccups in there in the the learning path, let's say, but, I think we'll we'll come to that, also when we talk about documentation.

It was one of the things why I joined GitLab was because of Vue and, particularly thanks to Vue conferences because at one of the conferences, what is beauty as London, I think? I met a few people from GateLab. I talked with them. One of them was Filipa. She was also a Vue speaker. I probably remember her

I remember. Yes. Yes.

From Vue, Amsterdam. And then

2019 or something. Yeah.

17, 18, 19, maybe. I think she was in 18 19. And we talked a little. We they were solving a few problems. Again, it was fresh for GitLab as well, to start with you. I gave a few suggestions, and she said, why why why don't you join the company? It looked like a good fit. I looked at their 5 interviews pro like, 5 stage interview.

Yeah.

Like, I'm not going to pass. You know? That's that's a bit too much.

I mean, 5 step 5 steps are a lot. Right? So

It's like the Google level of interviews, and she convinced me to try, and, apparently, it was done in 7 days. Like, all the 5 interviews.

That's fast. Yeah.

Still the fastest hire.

Congrats to that. Thank you. So, VGS core team member, principal engineer, and fastest hire at GitLab. Yeah. Pretty amazing. And, yeah, you're still at GitLab. You, didn't, change companies for for quite a while.

No. No. Part of the reasons, again, we are using Vue and we are open source. I think part. Yeah. That's one of the biggest companies using Vue in the as an open source. We know that many other big players do use it, but we don't see the code.

Yeah.

Right? Everyone can

Probably for better.

Everyone can see how bad our code is. Maybe you are not. But and overall, the company culture is pretty cool, so not planning to change this anytime soon.

Perfect. Yeah. I I also heard, like, lots of good things from, newly joined GitLab hires as well. We had Vanessa on also

And now, yeah, we're still in people from Vue community. Like, we have Marina. And if you watch few master recourses, you probably know who she is. Vanessa, like, picking people from the Vue community.

That makes sense. I mean, you as you said, you're using Vue for for all your projects, or, like, for all the product as well. So it's important to have people with some expertise and never hurts to have, like, well educated, employees.

Especially for migration, but I think we're also going to talk about GitLab.

100 Percent. Yeah.

A bit later.

That will be that will be a big part. So, yeah, GitLab using Vue and, like, you said you found out about GitLab at conferences. How how did you come to public speaking?

Oh, that's that's a fun part because, I never planned to be a speaker. It was nice to see speakers on stage when you come to the conference, but you feel like they are a bit on a different level. Right? When you're on the stage, you're figuratively on the stage, you're a bit above Mhmm. The audience. And, back in times, you remember there was an organization called Vue Vixens.

Yes.

They were, like, if you don't know it, that's normal because I think they are not active anymore. They were giving free workshops in view for women, and they were coming with these workshops to the conferences. The first workshop was in Barcelona in 2018, and the second was in Paris.

Okay.

They were both quite small conferences. They were organized by the same team that organizes through Amsterdam. But this maybe a 100, 150 people.

I think, like, the was it, like, Vue.js road trip, something like that?

Yeah. It's called road trip, but it's, like it feels like a big meetup, and the whole vibe is a bit different from Amsterdam. It's just really a meetup with the companies, with, like, a bit of drinks, a bit of food, lots of, enthusiastic people. So workshops were held at these conferences. And after the first one, I was coming to Paris and organizers were, like, wanna give a talk? We have one slot. We don't have speakers for this conference. And, okay. Why not?

Yeah. Just do it.

I have no idea what I'm going to speak about, but let's just breathe something and try to speak. It was the worst talk ever.

What did you talk about?

I talked about, RxJS and Vue. Vue RX.

Oh, interesting.

That was a library by Evan. And it's interesting to use it for a few things, especially if you build, super heavy things in terms of user interaction, like lots of drag and drop and, some simultaneous, things on top of that.

Yeah.

And I think that that's still true to this day. Like, first, I think, why why why are you doing this? That's so stressful. That's so scary. But then you see people come in with the questions and been being interested in their talks, and that's pretty cool.

Oh, yeah. In Austin. But we also went together. Yeah.

Yes. We also bear that

4 years ago. It was, like, shortly before COVID. Yeah.

Yes. Yes. That's correct. It was in 2020. And, I gave my talk on the 1st day of the conference. Now the second day, I want to grab some coffee. I need to walk for a few kilometers away from the conference venue because finding decent coffee in Austin was a challenge. By European measures, maybe. Find a nice coffee place, grabbing my coffee, and heading to the exit. And there is a man sitting at his laptop, like, oh, can I say something to you?

That's super cool.

That's the best moment you can have as a speaker. Like, literally. Someone listened to you, do your rambles from the stage, put it to test, and it's working for them, and they're happy. Yeah.

What else do you want?

What else do you want? Exactly.

I 100% agree. Like, I also just like all the the questions, the conversation with people, like, as you said, people showing interest, that's that's always the best if you're, like, getting in touch with the people. And, luckily, like, now with content creation, like, a little bit of YouTube also streams, because I always like like the interaction. And even if it's, like, a super unrelated question, you get, like, sidetracked and jam it to something else, like, still, sometimes it's, just super helpful. And I think usually for maybe the one person asking a question, there will be, like, tens or 100, even 1,000 maybe having a similar question.

Just maybe afraid to ask, maybe waiting for someone else to ask. And in your case, it's more public. It's not 1 on 1. You're interacting on public platforms on YouTube, on Reddit. I saw you on Reddit by now.

Yeah. Yeah.

And interacted, just in case. And, yes, in this case, people just can read you answers. Okay. Now now I know.

And I I think, like, that's also, like, sharing in public, beats conference when talks are also recorded, like, in the comments on the YouTube. That's sometimes hard to catch because, like, different accounts, so on, but still, but, yeah, also the people just come in there, it's, like, hey, or even just saying, hey, good talk. Hey, you liked it. It's it's amazing.

Or even when they come with a constructive criticism

Even better.

Those are the best. If you see the talk, you disagree. You have some additional information that speaker forgot to tell, or you have con like, completely opposite view on the same topic. Like, don't hesitate to come and tell us. Yep. It's great. It means you listened, internalized the information. And when you give the feedback, we can incorporate it because sometimes we do speak on the same topics several times. It's pretty okay talks evolve. Right?

Yeah. And, I mean, you also maybe learn a thing or 2. Like, even if you say, okay. We have that specific use case, and we do it differently. Even if it's like, oh, don't do it like that. There might be good reasons for people doing it at

the way. Yeah.

So, yeah, I also like also constructive criticism in terms of, hey. That was great, but I don't know. It would be nice if you have the font size a bit bigger. Just, like, shout it while it's like, hey. Like, make it bigger or whatever. It's it's super helpful. Yes. Because, like, you are on stage. You don't have to see if the person in the last row can see that. And I don't know.

I didn't start this tradition. I think the first, it was Chris Fritz who offered to give the feedback about the talk. And it's really nice to offer. Like, if you don't want to hear anything, it's okay.

But if you want to

But if you want to, I can listen to your talk from constructive criticism point of view and then provide it to you as a pause point. And that was super, super helpful. Because you never know how it's taken to how audience takes you talk. Right? You're on the stage. You're on the opposite side of things. And, like, hearing things about font size or your presentation skills or, even slide theme

Yep. Structure as well.

Yeah. The flow of the conversation I remember the best advice from Chris was make it a story. Like, very, very simple. It sounds super simple, but try to make a story about unit testing. Testing.

Yeah. I mean, that's that's always, like, I I also like the very simple, like, you need something catchy in the beginning or, like, okay, get some attention, then show the problem the solution. It's, like, usually my flow as well. Like, okay. Because I don't have to show a solution when people don't know, okay.

For docs too, by the way.

For docs too. That's good. And so so we met in Vue.js Amsterdam in 2019, I think.

Yes.

So I think you were also at, Vue.js London in 2018. So we probably also briefly went there, though my memories are a bit bit vague. Back then, it was it's quite some time ago, but still, like and that was, yeah, 6 or, like, 5 years ago if you take me to Amsterdam.

In Amsterdam. No.

No. Now that's the case, but what made you move here?

Well, I really like the city even on the first visit. I just walked around and, you know, sometimes it just clicks with you. It's like looking for apartments, sometimes looking for the city. It just, like, feels so nice being here. And, yes, visiting and living is diff different story.

Yeah.

And apparently, it was a good move because I moved from Ukraine way before the war, but still. And there are no regrets. Honestly, it's such a grace great place to live. Amsterdam in general, the in the Netherlands too. So

Yeah. I I also think so.

What about you? What made you move to?

What made you so the the person behind that camera right now made me made me move.

On Deutsche Bahn.

Yeah. Exactly. They, by the way, also use Vue here and there, at a couple of the engineers' conferences. And, yeah, now, I'm living here for a year and a couple months, and it's pretty great.

Totally.

So, yeah, we're we're both here, and maybe let's come to the part of the Vue. Js core team. So you you said you joined in 2018, and you you're still on the core team, obviously. So for people who maybe have seen you on the list of people on the core team or maybe a talk of yours, how would you describe your role in the core team, maybe also your duties?

They are very simple. Most people in the core team are responsible for a certain part of the Vue ecosystem besides Evan. Like, Evan is everywhere, and he kind of takes part in maybe maybe besides Nuxt, but Nuxt is not a part of the Vue Core. Right?

That's

true. So for example, Eduardo Posva, he's responsible for the router and pinia, Right? And there are people who work on the view itself. I know source then comes to mind first And so on and so on. Like, my part is documentation. I do work the most to on the docs. I have a few pull requests that were merged to core, but they are mostly coming from the documentation. Because you try to document something, and you just turn and twist it. And it's, like, it's not right.

Like some new features to document

Yes. And sometimes not document. That is quite frequent request on Vue docs. Where the hell is, getCurrentInstance?

Oh, like internal methods. Mhmm.

This is internal methods. Like, but we use that's your problem. Yeah.

If it breaks, up to you. Yeah.

That was a conscious decision from the team not to document internal things because we did document them in the past, and then library authors did use them. Even so, there was a huge warning on the page. Nobody reads warnings.

Nobody it's even worse. People might not even read the docs. They're like, okay. Yeah. This Stack Overflow. So it was like, getCurrentInstance the way using it.

That's what's happening right now. And they they come from Stack Overflow, like at least. Unfortunately, they did cause issues with migration, which we will talk about after.

Mhmm.

So, yeah, right now we decide not to document things we don't want people to use. Like, getCurrentInstance used frequently in the libraries, but library authors are usually very conscious about using it. Like, we know why we need it. We know why we use it, and it's not exposed to the users. If you just have a product, don't. Like, do not touch getCurrentInstance, please.

I mean, why would you? Like, what's what's usually the case where people would Oh,

people have lots of imagination.

Fair. Yeah. That's that's true. But sometimes also it feels like, okay, I need some kind of workaround. Well, usually there should be, like, a built in or a better way. Often there is, or what you're trying to do might not really work. Like, you might have to shift your mental model around.

That's a really good point because we had this in Vue 2 back in times where we had, for example, dollar sign parent or dollar sign children exposed. Yeah. And while you should honestly have communicated with props in the midst people who can't, I will just trigger the parent method. So I know what is the good way. On one thing, it's a good, a baby idea to add kind of a guide to the cookbook because we had cookbook in the past.

Yeah. Somehow, it's also the same with, like like, okay, they do something wrong even though in the docs it's exactly listed how it works. I think also nowadays with AI, it got a bit worse. Like, I see very often, oh, why does that code doesn't work? And then, like, ok. Why did

Why did you write it in the first place?

And, like, what like, okay. Yeah. What's your goal? Describe your goal. Like, the code doesn't do any of these. Not even close. Like, yeah, but chat GPT sent that to Yeah.

Okay. Yeah. That's good for chat GPT.

Yeah. So I I also think, like, the reliance on AI to be, like Always right, Quote in quote. It's, especially for people learning, it's really tricky.

I have an anecdotal story for that. Like, before you start coding with ChatGPT, try to ask it a question about, like, I have a boat, a man, and a goat. Only this. Only this. Because there is a common story about boat, goat, cabbage cabbage, wolf, and and the man. Right? And probably you all know it because it's simplest algorithmic task. Like, how do you cross the river if you cannot combine certain things in the boat. But ask it about only man, goat, and boat. And look at the answers.

Yeah. That's true. Different try it out also. I've I've seen that, I think also on Twitter, someone was like, wow. That that was really mind blowing in a way. But, yeah, I really think especially the the more bleeding edge the tools become, like, I don't know, lots of things popping up, in Nuxt every month, like new features. And it doesn't really work with Copilot, ChatGPT and so on because they just hallucinate. It's like, use this method. It doesn't exist at all. Like, it's not there.

Yeah. There is not enough data for them to actually generate the correct answer because we forget that chat GPT cannot think, analyze, write logical code. It works with a big, like, big amount of data. And sometimes it's just not enough data to generate your answer. Yeah.

Or it's not recent enough. And so on. But coming back to docs, so you're responsible for the for the Vue docs mainly, usually. Probably, like, more contributors to them. Like, do you have more regular contributors as well?

There are at least a few. Some of them from the core team, some of them outside. Some of them became Vue core team members. You remember we had a contributor with a nickname Skirtle. Oh, yeah. We don't know his real name, by the way. He was always going by Skirtle, and he insisted. So I think it's he it's he. I'm sorry, Skirtle, if you identify as anything else. But in general, he came.

Oh, mhmm.

And he decided he still contributes to the core and sometimes to the docs, just not as a core team member. And, yes, there are multiple irregular contributors that just come and want to fix something. And huge thanks for to everyone who actually contributed to the docs.

100%. Even if it's, quote in quote, just a typo fix, it's still, like, it's valuable contribution.

Even if you put something as a capitalization Yeah. That is more consistent now or fix one minor example somewhere in the guide, that's that's already amazing.

It's valuable contribution. I mean, that's the quality of the docs. And that's also, like, I feel doc contributions is, like, in a way, it's not really grateful, like, job or, like, duty because if it's great, amazing, people are like, yeah. Cool. That's, like, they they expect it in a way. But if it's shitty, then people will complain. So it's either people complain or they select, okay, that's how

they do it. Yeah. That's default, but and also there is one additional note. People think sometimes it's just docs. It's not real work on the framework. It's just docs. To write the code, you need to how to you need to know how to write the code. To write the docs, you need to understand the code and how to document it. So, yeah, this this is very wrong part, honestly. If people think that the docs are easy, good luck. Write the docs for your own product and look how it goes.

And I mean, that there's also a reason why lots of codebases don't have own documentation because, yeah, it is need to have, like, vast knowledge about what you're talking there. And that's and it's not enough. Like, we can't read the code and understand that it's just like, okay, edge cases covered. Why is it even there? Why was it introduced? Some goals, some what you should not do. Like, so

How do you use it? When do you use it? I remember I was super proud when in the new docs, in view 3 docs, we put a few diagrams about scoped slots.

Mhmm.

Because in the old docs, we found it's pretty complicated topic for the newcomers. Like, slots in general are easy. Scoped slots, slots with passing slot props. For you, it's easy. Yeah. I can see, like, what's what's wrong about this.

Yeah. But I also learned it at some point, and I remember it was a topic that I like, it had a hard time learning in the beginning because it doesn't come natural back then at least.

It's kind of like inversion in the normal flow of passing props. It feels like it's inverted, you know? It's like it passes props in a different direction. It's it's getting out. So we drove drew a few diagrams, Maybe not the most beautiful diagrams, but I have no talent for drawing.

Yeah.

Sometimes it's with a code. Sometimes it's with a diagram. Sometimes it's with text and code, and it's really hard to find the balance.

Yeah. It's also, like, from the the size, like, the the length of documentation. It's also tricky. Like, you don't wanna keep it too short because then you lack information, but too long, nobody could read it. And Yep.

It's very tricky. And you want also to read documentation sometime as a book. So you are super careful about not to put some knowledge in the earlier chapters because people will be like, the more you add the more cross links you add in the docs, the harder it is to read.

Yeah.

You want people to come to some chapter knowing exactly what was the previous one. Sometimes they just need the API reference. Right? That's also completely fine. Like, I forgot what is the signature for this particular method. I just want to jump to API reference. But in the main guide, like, writing it as a story from the simplest to the most complicated, it's quite a challenge. And I remember also talking about this with, Dan Abramov

Mhmm.

About new React docs. And it's not only the challenge for Vue. For React, I think it's even more challenging, for advanced concepts for their hooks. Like use use state is maybe simple, but when you go from this, it gets harder. So it's quite a common problem in terms of writing documentation for for the tool for the development tool.

Yeah. I think, like, every framework struggles with this. And I think for for Nuxt, I can also add knowledge comes from that space, of course, a lot. It's even worse talking about, okay, you have a framework on top of a framework, then you have Nitro and there's other packages and it's really difficult to figure out, okay, first, what method you use might be from underlying packages, either like exposed again or auto imported And where do I have to search? In worst case, I have to search for 4 documentation pages to find something and maybe also for repositories and issues and so on.

The level of the knowledge you assume. Like, for Vue documentation, we assume that people are familiar with at least HTML and JavaScript. For Nuxt, do you need to assume they are familiar with Vue? Mhmm. And then to what extent?

Yes. And also, like, depending on what what feature you use

Feature you're

using. Yeah. So we also, like, we have common reasons, like, hey, can we search through the Nitro docs together? Because some feature on the server are speaking Nitro, so and on the other hand, I was also talking with a few people, for example, also with Rachel, Neighbors, and it's like combining, might not make the most sense because then it's also confusing jumping to another doc set and so there, like, yeah, there's a lot of work in docs and probably there was also a lot of work when Vue 3 was on the horizon. You said major releases

Oh, yes.

Are a big thing. So, how how was that, like, writing docs for for Vue three and keeping the balance and basically getting having a good journey for new users, for Vue 2 users, for everyone.

Complicated. There were so many decisions that were made and then overridden. Like, we were writing first with options API in mind and adding composition as more advanced. But when the framework progressed, the documentation was changed into having 2 styles simultaneously. You can switch right now.

Good point. They're also good contributions. Yeah.

Because we don't want just variable names. We want to have more real life examples. Right? So this was huge project. We had the whole planning board, and everything was like, okay.

Now we know.

Right. Now we know. But that's also the evolution of the framework, causes the evolution of docs. Yeah. You see how your user base is working with a framework. What do they prefer? Framework evolves, like, we and we write different recommendations as well.

And, like, best best practices, patterns you see in

TypeScript too. Like, we had pretty minor TypeScript guide at the beginning of Vue 3 at the release moment. And I think it grew maybe 5 times in size, which means people use a lot of TypeScript with Vue 3, which is logical. It wasn't this easy with Vue 2. So now, like, everyone who loves TypeScript is happy to start with it.

Clean up again.

And weeds will be growing all the time.

Yeah. And if you have too many plants, those are not gonna look nice.

Nope. And you need to always think about it and work on it, but that's never stopping.

Fair. Yeah. It's like a code as well. It's never never ending process. And it's also interesting, like, for example, the reference reactive part. I mean, I guess we all set it on ref nowadays.

Oh, I I still can see reactive in some cases where it makes sense, which is fine. That's part of the API. But, yes, we did set on it, and the docs also changed accordingly. You can see that examples are with refs now. And you also need to track kinda measure the temperature of what what is going there and come back to docs.

Yeah.

Of the users. They come, like, it doesn't make sense.

Absolutely. And I I think it's also, like, it's especially if, like, 2 ways of doing something with reactivity, each might having their own purpose. Like, I don't know if you have, for example, form state and reactive can be pretty nice.

That was a good example. Yes. Reactivity forms.

I I, like, I always use the performance. They just, like, okay. I have it all together. It's good. But then, like, exactly, like, educating the users about that, seeing, like, okay.

So I still think that it might be a good idea to separate it not with a toggle, but with separate subdomains maybe or even completely separate documentation where you choose and go this way. Because we honestly, nobody wants people to combine two API styles of the same component. That's the worst outcome you can have unless it's migration. And even for migration, I would recommend, okay, you want to use certain API in this you rewrite it all.

Yeah.

Don't do part options, part composition because that's the best way to get lost in this component forever and for viewers too. So maybe separating and maybe I remember the discussion about eventually deprecating one of the things, but the point is there are many people around who like options API.

Yeah.

And, well, you remember this huge thread on Reddit Oh, yeah. All that?

The also the the video, the proposal of Justin, like, everywhere, people, had very strong opinions about other things. And in a way, like, options API is some part of use identity. Like, it started with it. It's like it is easy if you just use it as, like, maybe not a fully proficient front end. You just need tiny pieces of front end. Why not going for that?

And it's also easy on the huge teams. Like, when you have a bigger team, 100, few 100 engineer, it's a good idea to to use options because you can look at the component and you have no idea who wrote it. But all the things are at the same places. It might sound as a really stupid argument, But trust me, when you have multiple merge requests to review every single day, you want to find things in the same places. So just quickly understand what's going on in someone else's code.

I also made a video about that saying, like, hey, folks. If you use composition API,

maybe It's not the way, but

Yeah.

Like, it works for them. And if you want them to use something better, you need to propose the alternative convention because no convention is the worst. People will be looking at each other's code and, like, what is happening here? Yeah. So I think maybe the best way forward, maybe I'm just a bit too optimistic, is to actually offer this kind of convention very well explained.

Vapor mode coming up, also only for composition API.

Makes me a bit sad in terms because I will be behind. We still use Vue 2, and we will talk about that. But and, yes, that will be additional headache for me as principal engineer to invent the convention and agree this convention with everyone because we have developer democracy, and this this will be problematic. We'll fight for 6 months probably over the convention only. But this is I think that it was the main point in regular discussions too.

Yeah. I mean, like, if you have a really big component in options API, it's super tough to read. You might know where you find, like, your your variables and, like, your computers, your methods.

And that's a problem of architecture too. Right? You will need to split this component with composition API or at least move logic to composables. It's easier.

Exactly.

But, again, that's I think that we will need to answer this question in the documentation outside of it for the people who love options API for its predictability and rigid structure? Like, how what can we offer them instead? How can they use the composition API and still keep the convention in place so they feel more comfortable with the code of the bigger team. So, yeah, that's the problem to solve.

I mean, technically, as you said, you can structure, like, the options API eventually. Like If

you don't want to, you lose the flexibility again.

Exactly. But I also think if you like the composition API, like, there are certain concepts that people were not aware of. Like, what I what I was also showing in the video about inline composables. Like, Evan did it in his first draft of, like, moving the the Vue CLI thing over, but I still I have seen lots of projects in my day job and I have seen no one using inline composables that way. Now consulting is not you don't see the most glamorous projects usually, of course.

And it's weird to me because how many times did you write a method?

Yeah.

A method that is used in this component multiple times, not only for the side effects. Sometimes it's a method that does some calculation. Right?

Okay.

You pass a parameter. You do some data mapping. You return the value that you want. And that's exactly what composable can be doing too if you work on more advanced level with reactive state.

Yep.

Just put it there and use it. It you don't need to create an additional file, put it there, and import it to your component and just

I think that the problem is a bit that, like, with the composition API, everybody praised, okay, you can now, like, share logic. And sharing is common, like, okay, I put in the file. I can use it everywhere. It's really cool. But it's a bit like overcorrecting. Right? And I I did the same, like, in the beginning of the conversation. I was like, okay. Cool. I can, like, add a composables folder, put my composable in there, and then I use it in one component.

But it all also takes the evolution of the framework. That's the point. You cannot try them from the start because it's really just your opinion.

Yeah. I don't know if people like it or use it, if it makes sense in the project. You need a feedback, of course.

It comes naturally. The more people use vue 3, the more they come up with the same problem and some solutions.

Yes.

The more it's natural to then put it in the documentation or guideline of the book because now we know. Like, people used it, tried this way, tried that way. Now we know what is better, and we can bring it back to the documentation.

Yeah. Yeah. I also like this, like, symbiosis, like, hey. It's always a feedback loop. Right? You you do something. People use it. People complain about certain things. They, hey. We can improve this or we use it that way.

Yes. Yes. Absolutely. That's why it's extremely valuable, the work that you do with videos, the people who write articles, people who bring this to the public discussion so it's more visible, and we can shape the patterns. People can test the pattern. Right? Okay. And now I learned about in line composables, they will test it, bring it back, and this is how it goes. Yeah.

Still people doing. I've seen I've seen it very often. Yep.

Like, put everything in the watcher. You and computers just slowly evolved to be a norm, and, like, watch your strength to, like, yeah. I really need this side effect. I really need this side effect from this particular prop changing. Like, I'm watching it. But this is what is happening with composables too. People try many different things. Sometimes, some of them are very wrong.

Mhmm.

And then we have some best practices crystallizing.

Yeah. I mean, it's the same with composition API and server side rendering, which, also wasn't easy for the Nuxt team. It wasn't easy because at least from my point of view, composition API wasn't really written with service side rendering in mind. It's like sharing a ref between the server and client is not that straightforward when you just, like, have plain Vue with SSR. I mean, that's why we have, like, useState in in Nuxt.

And you need to find a way again, find the best practices and trying to figure out. But, yeah, this is the evolution we're dealing with.

Absolutely. And, as you said, everybody creating content or maybe someone is like, hey, I've I've had a really cool method. Please write it down, share it with the community, be ready for some constructive criticism, but, like, that's the best way to do it even if somebody's like, oh, okay. Not my jam, but I see the point there. Doesn't hurt. So, like, sharing knowledge even, like, you don't have to be the the best in in Vue. Js or, like

Absolutely not.

Don't. Just like, hey. ok. We do this in our company. This was useful. So in our use case, yeah, wanna try it out. Here, this is how we do it. Why not? I think it's

Creating issues, asking questions, bringing things up, like sharing your little tips. That's all important. And I can understand it can feel a bit scary

Mhmm.

To just bring something to the public. But if you even try to do this, you're already helping the whole community. And Vue is not the biggest framework. It's one of big three. Yes. And we have very active and nice community as you know.

Absolutely.

But the more content you produce and because it's also content. Creating an issue is a content. Yeah. Creating pull request to docs is a content. Like, the more content you create this way, it's the better is for everyone.

Yeah. People searching, finding issues, like, I mean, I've searched so many times in land and issue on my own because, like, oh, yeah. I wrote that. Or I answered it. I was like, damn. That was not a very satisfying answer. But

I'm still using some of my articles to set up my Vue apollo client.

Yeah. I mean, that's, like, sometimes it's just self documentation and then if you'd write it anyway, why not sharing it? Like, it doesn't hurt. But also doesn't hurt, of course, that we talked about public speaking before is coming to the Vue.js DE conference in Bonn in Germany.

It's a really nice event. Totally recommend it.

Yeah. So, hope, to see you there. I'll be there. Vanessa will

Vanessa will be there.

Daniel. There will be Evan, you, not, like, in place, but with a remote live q and a. So if you have a question, want to ask Evan, then, don't write him a DM but, come around and and ask it there straight away.

It's go it's going to bite them back.

Yes. Yes. Vue 2 to Vue 3 migration. Yeah. That that's how lots of people felt, and we don't even talk about, like, not knocked on top. It's also hold up like, that's once again another level. Yeah. How how did and do you experience that

I'm sweating already. So, yes. First of all, disclaimer. We're still on Vue 2.

In GitLab.

At GitLab. Trying to move to Vue compat mode 3. We started with at GitLab.

So, like, the Vue 3 3 build with Vue 2 functionalities.

Yes. Currently, like, what we have in place is Vue 2 with Vue compat in mode 2, because otherwise we just break it completely. And we slowly trying to get to Vue compat mode 3. Not even to Vue 3, not possible at the moment because it happened that we use bootstrap Vue And unfortunately for us, we use it in our component library.

Yeah. What a surprise. Like, oh, yeah. The MVP we will clean it up later. Yeah.

Later.

Never. Mhmm. Yeah.

Now those components use bootstrap here under the hood. And before we even move the main code base to mode 3, we need to move the component library to mode 3. Makes sense. Right? We cannot just move use the dependency that doesn't work with mode 3.

Mhmm.

Now you can use this one for the Vue 3. So we were stuck, and now we are trying to solve this problem. And on top of this, we have bunch of tests passing. We were using Vue from the very start, from 2016. We were using Vuex. It didn't exist, so we brought our own state management back in time.

Still in the code?

In a few places, unfortunately. Yes. Now we have 4 state managers.

So Vuex, Pina?

Vuex, Pina, Apollo, and the old one. Yeah. Wow.

I I've seen a lot, but everything go okay.

But, yeah, it's a pretty big

project.

And it's big. Yeah. And it's also we don't use it as an SPA. That's also one of the things. We do mount Vue applications on different pages. On some pages, multiple Vue applications don't do these kids. On some pages, it's up to 20 Vue applications.

Because you use rails under the hood. So everything is server and by rails, and Vue is basically for progressive enhancement, let's say.

That's the good point because we do say in Vue 2, you remember we did say that you can just drop Vue at some little place of your page to make it more interactive, and that's what they did and let it grow uncontrollably. And now we are slowly moving to the idea of cluster, SPAs cluster, because we cannot just realistically move this to one big SPA, but to multiple SPAs. So at least on the when you're on the issue list, you go into the issue and back. That's one app dot page flow. But, yeah, that's a bit of an off topic, which has given an idea that it's not a monolith application.

Oh, okay. You remember when

I had slot scope? Mhmm. Not scope, slot. And I think the last occurrence of Vue dollar sign delete was only removed 2 weeks ago.

Oh, wow. I haven't heard that in long, long time.

The Vue site is still there, by the way. But

Yeah. Okay.

So you you can think about how bad and old it is. And there are lots of problems with the migration even outside of bootstrap Vue. Bootstrap Vue is a big problem, obviously. But I would say one of the biggest one is unit testing. Unit tests do fail in mode 3 a lot.

Yeah. Fun that's it'll be fun finding the problem.

Yeah. Just even trying to figure out what exactly from the tree causes the problem is already not a good thing.

So it's not about that the composition API that was back toward 2.7 2.7 has a problem with the Vue three implementation. It's more like this is that learning curve architecture structure.

It's like we already have a lot right now to deal with, and we don't want to add more problems right now with the migration. So let's port it as it is with an options API. Some sometimes really bad options API, I have to say. Sometimes you figure that, well, that people mutated computed properties, object. You put an object in it that returns in the computed, and you can mutate it. I learned. I didn't know that you can the property.

That sounds interesting. Okay.

That's the point. And Vue 3 what what is cool about Vue 3 tests? They're way more strict. Vue 2 is very forgiving in tests. So for example, quick thing. You access some property in some of the methods. Methods, not template important. In Vue 2, that doesn't exist. It you forgot to declare a property in data, and you use it somewhere in the method. If the method is involved, probably you will have end of undefined thing.

But it's perfect. Like, you catch some bug just

by when you have 3,000 tests failing.

It's not fun anymore.

That's not fun. Like, you understand how much you need to fix, and some of them are very unclear because of the moment. Right? And, honestly, our pipeline that tries to run the test in mode 3 is out constantly out of memory. My laptop is out of memory when I try to run all the tests as well.

Really? I can't remember. Nuxt

bridge took some time.

Yeah. I mean, Nuxt bridge got feature, like, feature Nuxt bridge got released, like, couple months ago. So and also that the whole Nuxt journey is is once again very difficult.

And you cannot blame library authors because they were all already building something on top of the framework. Not only on the language, on the framework. And the framework suddenly changes, and I need to adopt. Some libraries are quick and easier to adopt. They didn't use some particular rendering mechanism, especially rendering mechanism. That was a big, big, big shift. Right? Like, if a library were just calculating some things, I think form validation libraries moved faster

Mhmm.

Just because the logic was easier to move. Things like component libraries, though, they were digging deep into the internal methods of you. And lots of things like dollar sign parent, dollar sign root puts the fewer list. Like, lots of dollar sign root.

All gone. Yeah.

It's all gone, and you need to deal with it. And the project depend on you also.

And there's also on top of figuring out how to, like, rearchitecture everything working with composables because now you have that. And, okay, Vue 3 is out or, like, beta and composition API, but still the best practices aren't there. So you have to put really lots of thoughts into it because you also don't wanna, like, put another version 4 or 5, 6 of the library, like, another major after major. I was like, okay, we tweaked the composables. They work differently now.

Yes. And, again, that's one of the things that, unfortunately, when we talk about Vue 3, which is pretty standard right now, it's not even new. It's a standard. Right? The people who have those big teams and big code base, we do feel forgotten, honestly. It's like it's cool. Like, all the cool kids are using this new toy. Right? And you cannot realistically and it's a problem for the company too. Like, during the hiring process, we did have a few candidates. Like, oh, you're using Vue two.

Yeah.

No. Thanks. Mhmm. Which is, I think, completely fine because you would need to deal with the code base. Maybe not legacy legacy right now, but slowly getting to this stage.

Yeah.

It's not supported anymore, and it's it reached end of life. So, yes, like but the efforts for this migration, like, if we finish I'm not saying I'm not saying when. If we finish it one day, I swear I will write a book about this.

Vue Two to Three migration.

Like, story of my life.

Though, I I think, like, lots of things that you also mentioned here and, like, that you tackled during migration, I think they would also be very helpful, like blog posts or, like, even in that podcast, obviously. So other people on the same boat that like, okay, we have to migrate over. We don't have to rewrite everything. Big bang doesn't work. We can't just do that. They might also, like, get some teeny tiny points with, like, okay, we can try this. We can do this.

Yeah. Especially, we already identified some cases. Like, okay. If you see this cryptic error, probably this is what happening, and this is how you need to restructure. There are already the guidelines, and I think they're not even internal guidelines. We document everything as public. Yep. So people can just, take right now, it's not super public. You just need to look into epics and see what we decided to go with.

Maybe you can, like, put an example link in the show notes so people know what to look for.

But a few things were super helpful. You identify some cases and you bring them back. And, like, in test, for example, don't use native methods with bootstrap few components. Like, never. Don't do click. Do emit click because this is going to break the test, or this is going to break the test. And also this is snapshots. Yeah. At this point, I'm like, never test with snapshots, which is pretty strong statement. Yeah.

You have to update them all, but also check that they're

But you need to check that it's updated for a reason. Like, okay, this there is no break then there is no breaking or there is no white space there. Yeah.

Yeah.

It's okay. But if it has different apparently, part of half of the componentry is gone sometimes.

Yeah. That's, it will be tricky. And I also like the typical, like, okay, just click on update the step, but it's fine.

It's fine.

Like, that's, like, you also wanna deal with, I said, 2,000 test failings, and, like, all the snapshots taking each of them. It's tedious work, but it's it's necessary. But I I I see the point where it's like, okay. Snatch for testing. At least not the whole tree, that's

Yeah. Mount, maybe just a little thing from the tree, not the whole component. And, god forbid, not the whole component tree, not the whole component in general. So, yeah, at this point, it's fixing the test, trying to bring things. On the good side of things, main core libraries were good to migrate.

Just the others.

I mean, bootstrap-vue was the biggest problem. Yeah. Maybe view test details to some extent, but we also put a lot of work to fixing them, contributing to the Vue test utils upstream.

That's also really nice that you like and we we also had a countless time stamp. So, like, okay, fixing a bug internally versus, like, actually pushing it up being making that extra effort to do the PR. That's that's also very helpful. So if anyone ever encountered a bug, fixed it locally, maybe patched it, like, hey, come. Do do at least a little work. Write an issue. Write the, hey, here's a try.

It was also, multiple contributions to Vue compat

Mhmm.

And to Vue core just to fix a few things that were not working for us. I think the last one was merged last week.

Oh, well.

Yeah. So if you also if you encounter that issues, at least try. Sometimes it's not merged from a while saying, like, fine. I'll patch it on my side, and we'll work with it on our code base. Yeah. But maybe it will merge later and you can just update and remove your patch. So

Everybody will benefit as well. So that's good. And how about the Vue 3 breaking changes themselves in the core? Was that a bigger problem for you?

No. We will still need, like, when slash if, we will move to exactly view 3 Yeah. Outside of the compat. Updating model values mostly. I think that will be the biggest one. We use v model quite a lot. Removing all the reactivity caveats like hello Vue set because we use it we use it. It'd be

so nice to just, like, have properties everywhere.

That's the point. And I think that's about it. It will look pretty okay in most cases if you don't mutate your computed properties of props. By the way, Vue three allows you still to mutate props Oh. If it's an object. Don't do this.

It should probably be a warning or something if you actually do that.

That's the problem with detection.

Yeah. It's not that. Yeah.

It's easy. It gives you a warning. If it was a primitive value, you you would immediately have a warning. When it's an object, it's a bit more problematic because JavaScript allows you.

Yeah. Yeah.

So, like, you cannot just go against the language and just do this detection properly.

No. I see.

Un unref them.

It's it's it's definitely it's definitely interesting. I was, like, cases that you would never think about people doing it, but it's it's kinda

That's why I told you people have the wildest imagination possible.

Yeah.

And they will do things you would never expected them to do. And need to deal with it both as a team member and as documentation co author.

So you said if for the future distribution. Like, but you you are you certain that you'll finish it one day, ever? Not stuck forever on Vue 2?

Well, right now, there is a huge effort to vendor bootstrap you and rewrite the only use the parts of it that we have in our components and rewrite them in the compatible way. So that's that's going on

Mhmm.

Right now, but it will take lots of time. And there are components that are super, super complicated, like a booster view table. This one breaks all the laws of physics in terms of Vue. It just uses everything it shouldn't. Yes. If if you look at the source code of bootstrap Vue table, you will see what I mean. So, yeah, this will take some time to migrate. And, see, I'm already on the pessimistic side because we've been there for a few years

Mhmm.

Trying to migrate, trying to move. Probably, we didn't make a good step. We should have decided to render the library from the start instead of just trying to fix it. It's is just trying to get it to compact mode, but we didn't realize we are not able to bring it to vue 3. Yeah. So our best best possible for right now is get to compat mod 3, which will give us headache with tests. But

That's how it's going. And is there any fails in terms of Vue 2 to Vue 3 integration that you like to tell the audience, the listeners, everybody, you out there everywhere, that also, like, suffering from that? Maybe some tips like, hey, Don't worry. It will be fine. Just a few more years.

Just wait for 5 more years to ???. The main point is you will find root causes for your problems. At first, you should think like, okay. There are 33,000 failing tests. Not all 3,000 have the the same issue, but it's not 3,000 problems too. Normally, it will boil down to maybe 10 cases. And then you will be solving problems in chunks. Like, okay, this is different. This causes a bunch of tests to fail. And now you have an idea what to fix exactly in the components.

Mhmm.

So some of them them is automatable. That's that's a good part too.

Great. So, basically, don't give up.

It's Yeah. Keep keep trying. One day, you'll get there.

You also mentioned this, this thing maybe some people are not familiar with, a test. So Oh. What so what would you recommend people saying, like, okay, we have this big view to code base and we we maybe don't really have tests.

At

all. Like, maybe an end to end test for, like, some

And turn's already good.

For, like, the mission critical part, like, the app is starting.

Well, it's it's good and bad for you. Good, because you don't need to fix tests. No tests, no problems, right? The pipeline is we do have a pipeline too. Okay. The CI is green, but at the same time, you might miss issues. Compat gives you lots of warnings. That's a good point. When you enable the compat mode 3, it gives gives you a bunch of warnings you can fix. So in this particular case, I would never recommend going migrating in bunch.

In the same time, if you've mixed things, like

I mean, you can start with tests and then go you can you can start with tests after, but at some point, write the test, please.

Yeah. That make that totally makes sense. And then would you say, like, is there a chance that people would be better off with a rewrite than migrating things over? Are the scenarios like, Yeah, let's just just rewriting an application would be the better choice.

This is this really depends on the size of the application and complexity of the application. Some of them can accept as burn this to the ground, write it from scratch thing. Some of them, unfortunately, are too big, too old, and too complicated. Sometimes, yeah, I can just try this. Well, no.

it's not possible. Yeah.

It's also a valid point, honestly, even though the Vue 3, Vue 2 is end of life. But I don't remember super major bugs fixed even from Vue to point 6 to Vue to point 7. It's pretty mature product. Right? There wasn't anything super critical. The problem is, though, with the is with the libraries. I doubt that there is any product that is not evolving at all. If it's not, like, what are you even doing? I mean, you're lucky. You just need to maintain it.

Don't touch it.

Let it be. It works. Yeah. Right? It works. Don't touch it.

Like petite view. Like, okay. It's it's feature complete. It's done.

Like, it's fine. But when you add new features, you have new drag and drop library. And, apparently, there is one old forgotten super buggy library for Vue 2, and all the new ones are for Vue 3. They're not compatible with you. And, again, product evolves, you discover new things, you discover, I don't know, VueQuery, TanStack Query now. I'm not even sure it's compatible with Vue 2, honestly.

Right now, I don't think so.

I think I don't think so. It's composables. It's built on composables. Yeah. Like, Vue Apollo still supports both, but you want now to be cool and use Tan Stack Query, and you cannot. So enjoy axios.

Not even fetch API. But, yeah, in the end, as you said, it's a lot lots of big decisions, and it's also not only on the depth. It's like, okay. The whole business in the end needs to decide on that. But if you can't move forward, if that's like blocking his head, like using the newest libraries, not just because they're trendy, just because they actually make you more productive.

You will have to at some point, that's that's the point of your productivity. Yes. You will need to use dependencies. You want maybe you want more performance for some parts of the application. We do have this case where the rendering performance is critical. It's diffs. When you render 10,000 components, the difference is there.

Yeah. And with Vapor Mode, we'll even go better. And for that, you need composition API.

For us, the idea was we move from there. And then we can afford writing composition API. We don't want this in the same component because there was an idea there that just bring Apollo composables to the options API component. No. Thank you. It's it will help us abstract things, but it's also super complicated things on the component. So after this, the idea is we develop composition? Not not how we use composition. Not on how we use composition API.

At GitLab.

At GitLab. Yeah. That's that's how we want to write it. And, again, from my experience with big team, literally any opinionated convention is still better than no convention at all.

100%.

On the scale, it just it just easier.

I mean, you then at least know what you expect in certain scenarios. Right? And for example, like, what Vue use is doing, they also have, like, some best practices for their composables and just, like, adapting them and say, hey. Look. In our in our code base, this is the guideline.

And we do have one project in Vue 3. I need to say this, GitLab dedicated, where we already put some things to test, right, like, in terms of convention. So this is a little playground where other people, even from the main product, who don't work on the dedicated, we are reviewing the code. And, like, okay. This part, we want to be okay. Now we see there are a few problems already here. So we probably will go this way. We'll go that way.

Mhmm.

Like, there are questions that come up naturally. Like, do you create reactive values in tests? In tests? Like, do you ever feel that this was later on my question today in the morning because in v two tests, you don't have the way to create oh, you do have the way. You have your observable, but I didn't say this.

Yeah. Absolutely. I mean, once again, that can also influence the the greater discussion community. So, like, whenever you settled on some things, you you write why you settled on these because there there will be a reason. And then

Then you write a conference talk, and you come to the conference, and you bring this to the wider audience. And

So people will have you back at the stage? Is that what you're saying?

Well, if if there is more material. That's also the point where right now, I'm not even sure that it's a good idea to speak about something that is view 3 centered if you don't work on it every day. Right? Documentation, you know the source code. But knowing the source code and knowing how the source code, this this of this library is actually used in the product is is very different.

That makes sense. So it might take a little bit longer until tiny tiny Yes.

For sure. Or finding the topics that are common for everyone, like test testing is not very different. If you think about the concepts of unit testing you can adapt it even to a different framework. But, like, for vue 3 specific development, yeah, it will take time.

Makes sense. Is there anything else that we, should talk about in terms of Vue two Vue 3 migration? Anything that we haven't covered yet?

Besides crying, no.

Oh, we don't do that here. We're we're happy podcasts. Lots of laughter. I mean, tears of joy when it's done. But, yeah. No. Fair. It's it is a tedious process. That's, fair to admit. Maybe on that note, there is there is one more question.

The point is it would be nice to involve engineers from those to maybe some kind of the early access. If you remember the documentation and the product itself, the project, the Vue 3 project, was private for a long time. We allowed, developers from the libraries in Nuxt, Vuetify. I remember for sure Nuxt and Vuetify and a few more. But then it was pretty new for everyone.

Yeah.

How many at the View conferences have you heard a talk that criticizes some parts of you?

Really. Yeah.

It almost never happens because it's like, it doesn't feel okay to come there on the stage, see the audience, and, like, say, okay. We do have a problem. Let's talk about it. But, honestly, we should. I think, like, if you have something that you want to criticize constructively, you don't go on stage like, this sucks. No.

That gives no value to anybody. Of course not. No.

But you go to we suffered here a lot. This is things we did. This is what probably could have done better from us and from the team side, but this is our story. That's an amazing story. I would be happy to hear more of those at the conferences.

Also, something with open CFPs from Vue Toronto are still up, for for CFP. And And

there will be more to come after. Right?

Indeed. Indeed. There will always be more. Great. And I think, in terms of migration, in terms of docs, we we talked a lot.

We do have the part of the documentation, Nuxt.

That's true. GitLab is using Nuxt.

Yeah. We do.

Very important.

Nuxt two. So

Well, maybe, it will be already migrated, but, no, probably not. But we will we'll get there at some point. So, yeah, definitely check it out.

Any like, my last last question is meta. Any questions, steaming questions? No. I think I think we covered pretty much everything. And, yeah, it was a pleasure. Thank you for inviting me.

Likewise. You can, follow Natalia, pretty much everywhere, question mark. Like, Twitter, mastodon or mastodon?

No. Not mastodon. Twitter. Yeah. Like, LinkedIn?

LinkedIn. Oh, very important as well. Yeah. That's also all in the show notes, so, definitely, check it out. And, of course, watch all the other older or maybe newer episodes of Deja View. Also looking forward to have you back on, the show for another time because it was Thank you. Lots of fun. So, folks, stay tuned. Let us know what you think. Write everywhere in the comments, on social media.