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

For the 20th episode we surprise you with a "in-person" podcast episode!

Alex is joined by Principal Engineer and Vue Core Team Member Natalia Tepluhina to talk about two important topics - Documentation and the Migration from Vue 2 to Vue 3.

Learn in this episode what Natalia does in the core team, how difficult writing docs is and how to improve your doc writing skills. Also, gain insights in how GitLab's migration from Vue 2 to Vue 3 is going and get invaluable tips if you also have to migrate a project over!

Enjoy the episode!

Chapters

(00:00) - Welcome to DejaVue!
(01:32) - When did you start using Vue.js?
(02:42) - How could you introduce Vue at work?
(04:43) - Joining GitLab
(07:15) - Getting into public speaking
(10:05) - Memorable moments as a speaker
(16:22) - Moving to Amsterdam
(18:22) - Being part of the Vue.js Core Team
(20:27) - (Not) Documenting Vue Methods
(22:21) - $parent in Vue 2
(22:59) - AI as the new docs?
(25:00) - Regular Contributors to the Vue docs
(26:14) - Is writing docs is easy?
(31:45) - Documenting Vue 3 at release
(34:04) - Documentation as a garden
(37:00) - Separating Options and Composition API docs
(38:20) - Preferring the Options API for huge teams?
(41:49) - Inline Composables and other architectural patterns
(45:35) - Overusing Watchers
(46:57) - People - Share your thoughts and patterns!
(48:39) - Vue.js DE Conference
(49:14) - Migration from Vue 2 to Vue 3
(50:10) - How the component library blocks migration
(54:10) - Updating Unit tests during migration
(55:16) - No CAPI during migration
(57:13) - Migration of big old projects
(58:45) - Responsibility of library authors
(01:05:01) - Vue 3 Breaking changes
(01:06:31) - Will the migration ever end?
(01:07:48) - Other tips for migrating
(01:09:19) - Migrating without tests
(01:10:45) - Rewrite vs Migration?
(01:11:35) - Not migrating at all?
(01:13:54) - No CAPI during migration?
(01:15:58) - New questions with CAPI
(01:16:58) - Natalia back on stage at a conference?
(01:18:16) - What could the Vue team have done better?
(01:20:21) - Nuxt Tips Collection
(01:21:00) - Wrapping up

Links and Resources

$10 off for Michael's Nuxt Tips Collection* with this link and the code DEJAVUE
10% discount for the vue.js de Conf in Bonn, Germany* with code DEJAVUE

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

Creators & Guests

Host

Alexander Lichter

Web Engineering Consultant • Founder • Nuxt team • Speaker

Guest

Natalia Tepluhina

Vue.js core team, Principal Engineer at GitLab, Google Developer Expert

Editor

Niki Brandner

Sound Engineer

What is DejaVue?

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

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

Alexander Lichter: 00:00

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.

Alexander Lichter: 00:24

But today, we're here in in Amsterdam, and I'm joined by a wonderful guest, give a warm welcome to Natalia Tepluhina. How are you doing?

Natalia Tepluhina: 00:32

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

Alexander Lichter: 00:36

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,

Natalia Tepluhina: 00:51

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.

Alexander Lichter: 00:59

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,

Natalia Tepluhina: 01:11

yes, that's correct.

Alexander Lichter: 01:12

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?

Natalia Tepluhina: 01:26

Since 2018.

Alexander Lichter: 01:28

2018. Wow. It's awesome.

Natalia Tepluhina: 01:30

Like, 6 years.

Alexander Lichter: 01:31

Quite some time.

Alexander Lichter: 01:32

And do you remember, like, when you started using for the Vue for the first time? Was it, like, couple years before that?

Natalia Tepluhina: 01:38

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

Alexander Lichter: 01:46

Wow. Okay.

Natalia Tepluhina: 01:46

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.

Alexander Lichter: 02:09

Oh. Like Angular 1?

Natalia Tepluhina: 02:10

Yeah. Uh-huh. Yeah. Not not the cool Angular. And Vue was really, like, a fresh air there.

Natalia Tepluhina: 02:17

So, yeah, after the after this, I think I only used Vue at my workplaces. Yeah. Vue and then a bit of Angular again.

Alexander Lichter: 02:24

Interesting. Okay. So how does it came at you? Like, said, okay. Let's introduce Vue 2.

Alexander Lichter: 02:29

Let's bring a bit of fresh air in there when you were using AngularJS.

Natalia Tepluhina: 02:32

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.

Natalia Tepluhina: 02:47

Again, we were not super proficient in AngularJS. I think nobody was at this point. It was all new for everyone. Maybe in React, it was a bit older. And we tried to do it, and we saw that it actually sped up the development quite a lot.

Natalia Tepluhina: 03:00

Mhmm. Documentation was amazing right from the start.

Alexander Lichter: 03:03

It still is.

Natalia Tepluhina: 03:05

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?

Natalia Tepluhina: 03:17

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.

Alexander Lichter: 03:33

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.

Alexander Lichter: 03:41

So, yeah, that was also often argument, like, okay, not, like, using something more heavyweight or, like, so strict as in, like, okay, you have use the Angular HTTP client everywhere and this and that. Yeah. A little bit of flexibility. But also there, we like, if people want that, if people want that strong guidance for every single part, like, this is the way to do it, then Angular might make sense.

Natalia Tepluhina: 04:03

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.

Alexander Lichter: 04:23

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.

Alexander Lichter: 04:43

Yes. So okay. You you start using Vue introducing it, then at some point, you you joined GitLab.

Natalia Tepluhina: 04:49

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.

Natalia Tepluhina: 05:07

I probably remember her

Alexander Lichter: 05:08

I remember. Yes. Yes.

Natalia Tepluhina: 05:09

From Vue, Amsterdam. And then

Alexander Lichter: 05:11

2019 or something. Yeah.

Natalia Tepluhina: 05:13

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.

Natalia Tepluhina: 05:25

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.

Alexander Lichter: 05:35

Yeah.

Natalia Tepluhina: 05:36

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

Alexander Lichter: 05:39

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

Natalia Tepluhina: 05:42

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.

Alexander Lichter: 05:50

That's fast. Yeah.

Natalia Tepluhina: 05:51

Still the fastest hire.

Alexander Lichter: 05:53

Congrats to that. Thank you. So, VGS core team member, principal engineer, and fastest hire at GitLab. Yeah. Pretty amazing.

Alexander Lichter: 06:01

And, yeah, you're still at GitLab. You, didn't, change companies for for quite a while.

Natalia Tepluhina: 06:07

No. No. Part of the reasons, again, we are using Vue and we are open source. I think part. Yeah.

Natalia Tepluhina: 06:14

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.

Alexander Lichter: 06:23

Yeah.

Natalia Tepluhina: 06:23

Right? Everyone can

Alexander Lichter: 06:24

Probably for better.

Natalia Tepluhina: 06:25

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.

Alexander Lichter: 06:35

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

Natalia Tepluhina: 06:43

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.

Alexander Lichter: 06:55

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.

Natalia Tepluhina: 07:08

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

Alexander Lichter: 07:11

100 Percent. Yeah.

Natalia Tepluhina: 07:12

A bit later.

Alexander Lichter: 07:13

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?

Natalia Tepluhina: 07:24

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.

Natalia Tepluhina: 07:44

And, back in times, you remember there was an organization called Vue Vixens.

Alexander Lichter: 07:48

Yes.

Natalia Tepluhina: 07:49

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.

Alexander Lichter: 08:08

Okay.

Natalia Tepluhina: 08:09

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

Alexander Lichter: 08:18

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

Natalia Tepluhina: 08:21

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.

Natalia Tepluhina: 08:37

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?

Alexander Lichter: 08:48

Yeah. Just do it.

Natalia Tepluhina: 08:49

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.

Alexander Lichter: 08:55

What did you talk about?

Natalia Tepluhina: 08:57

I talked about, RxJS and Vue. Vue RX.

Alexander Lichter: 09:00

Oh, interesting.

Natalia Tepluhina: 09:01

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.

Natalia Tepluhina: 09:18

So I I gave it a try. It was cool to talk about and, actually, that gave an idea for one of the further talks, not about you, about RxJS in general. I can tell that was really the worst talk. I was absolutely scared, stressed, stuck on the stage. You just stay like this with eyes wide open.

Natalia Tepluhina: 09:37

Like, why did why did I agree on that? You come with your laptop, look at that, people, like, freeze. Mhmm. Then you finish your talk. Like, yeah, that's cool.

Natalia Tepluhina: 09:47

I should do it again.

Alexander Lichter: 09:48

Yeah.

Natalia Tepluhina: 09:49

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.

Natalia Tepluhina: 10:05

I remember the best one, if I may share from the conference, is when you have the feedback from the people. That was one of the VueConf US in Austin.

Alexander Lichter: 10:16

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

Natalia Tepluhina: 10:18

Yes. We also bear that

Alexander Lichter: 10:19

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

Natalia Tepluhina: 10:22

Yes. Yes. That's correct. It was in 2020. And, I gave my talk on the 1st day of the conference.

Natalia Tepluhina: 10:28

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?

Natalia Tepluhina: 10:51

Okay. I've been to your talk yesterday. And he turns his laptop to me, like, I'm building an experimental project using VueApollo, and it works already.

Alexander Lichter: 11:04

That's super cool.

Natalia Tepluhina: 11:04

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.

Alexander Lichter: 11:16

What else do you want?

Natalia Tepluhina: 11:16

What else do you want? Exactly.

Alexander Lichter: 11:18

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.

Alexander Lichter: 11:50

Yeah.

Natalia Tepluhina: 11:50

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.

Alexander Lichter: 12:01

Yeah. Yeah.

Natalia Tepluhina: 12:02

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

Alexander Lichter: 12:10

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.

Natalia Tepluhina: 12:28

Or even when they come with a constructive criticism

Alexander Lichter: 12:31

Even better.

Natalia Tepluhina: 12:32

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.

Natalia Tepluhina: 12:49

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?

Natalia Tepluhina: 13:02

It's like a not like you come in and talk about Vue router or Nuxt or whatever, and it's the same. They always evolve and your feedback actually helps to shape the or even change it, like, maybe completely. The testing I mean, I remember I was given a talk about unit test and was the best discussions after because we have we all have slightly different approaches to unit tests. And just to listen to people to see about their experiences, that's super cool.

Alexander Lichter: 13:27

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.

Alexander Lichter: 13:35

There might be good reasons for people doing it at

Natalia Tepluhina: 13:37

the way. Yeah.

Alexander Lichter: 13:38

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.

Alexander Lichter: 13:48

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.

Alexander Lichter: 13:57

For me, it's usually, like, when I I go to meet ups, or, like, things with daylight, it's usually okay to turn in light mode just because it's better progress. But, I mean, I know that you know it as well. Like, we we do talks a bit more often than probably the the average person, especially, like, as first time speaker. It's also just, like, nice to know, okay. Hey.

Alexander Lichter: 14:15

Can you, like, do that? Just, like, have just people, like, criticizing in a as I said in a constructive way. I think that's that's really, really important. Also, yeah, to grow, to learn more because you're nobody's the perfect speaker. So and it also that also helped me a lot.

Alexander Lichter: 14:30

Even so, like, when you gave me feedback, for example, also after my my talk in Austin. It's, yeah, there were things that, like, I I was thinking about then eventually and, yeah, try to, improve.

Natalia Tepluhina: 14:42

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.

Alexander Lichter: 14:53

But if you want to

Natalia Tepluhina: 14:54

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.

Natalia Tepluhina: 15:09

You're on the opposite side of things. And, like, hearing things about font size or your presentation skills or, even slide theme

Alexander Lichter: 15:20

Yep. Structure as well.

Natalia Tepluhina: 15:22

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.

Alexander Lichter: 15:31

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.

Alexander Lichter: 15:46

What what does it do? What solves the problem? So, I I tried to adhere it a little bit, and that kinda works also for, like, content in general. So, yeah, that's that's very valuable feedback.

Natalia Tepluhina: 15:58

For docs too, by the way.

Alexander Lichter: 15:59

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

Natalia Tepluhina: 16:05

Yes.

Alexander Lichter: 16:05

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.

Alexander Lichter: 16:22

And, back then, you already mentioned it before, we were talking. We, like, we both didn't live in Amsterdam.

Natalia Tepluhina: 16:27

In Amsterdam. No.

Alexander Lichter: 16:28

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

Natalia Tepluhina: 16:31

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.

Natalia Tepluhina: 16:48

Don't mix tourism with immigration, we say. But it felt super, super good. And, back in time also, GitLab offered the package, the relocation package, specifically only to the Netherlands in the whole year. That's two factors that I already have. Why not give it a try?

Alexander Lichter: 17:05

Yeah.

Natalia Tepluhina: 17:07

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

Alexander Lichter: 17:22

Yeah. I I also think so.

Natalia Tepluhina: 17:24

What about you? What made you move to?

Alexander Lichter: 17:25

What made you so the the person behind that camera right now

Alexander Lichter: 17:29

made me made me move.

Alexander Lichter: 17:31

So but yeah, I mean, I I lived in Germany before. It's also a very livable country and, like, haven't had plans for a while to move out of the country for, like, ever or at least a longer, longer time. I mean, I've been abroad for long, but, yeah, eventually, I mean, I can work from everywhere. Like, having my own company, then it's, was the decision either moving to Germany, but it's a bit difficult. This one has permanent job here, contract.

Alexander Lichter: 17:57

So I thought, yeah, why not give them a go? I was commuting a lot between, East Germany and Amsterdam by train, so it took, like, 8 to 10 hours depending on

Natalia Tepluhina: 18:05

On Deutsche Bahn.

Alexander Lichter: 18:07

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.

Natalia Tepluhina: 18:21

Totally.

Alexander Lichter: 18:22

So, yeah, we're we're both here, and maybe let's come to the part of the Vue. Js core team.

Alexander Lichter: 18:29

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?

Natalia Tepluhina: 18:46

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?

Alexander Lichter: 19:02

That's

Natalia Tepluhina: 19:03

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.

Natalia Tepluhina: 19:18

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.

Natalia Tepluhina: 19:36

It doesn't feel okay to write a documentation for this. It's need to write really long explanation, and it still doesn't make sense to you. You come back and try to fix it in the core or bring it back to Evan. Okay. Why we do even have this?

Natalia Tepluhina: 19:51

Yeah. I remember we had a discussion about v model not even modifiers. What was that? I think it was about something about v model modifiers, but not the name. Mhmm.

Natalia Tepluhina: 20:02

Like, specifically, the custom modifiers you can pass to v model. Yeah. Because it didn't make sense to me to have it as as a user facing thing, but it was required for libraries. Now I know it was required for libraries. So yeah.

Natalia Tepluhina: 20:15

Okay. I can see why. So that's part of it. Yeah. Mostly, it's Vue documentation, and this work comes in spikes because you do not write documentation every single day two hours.

Natalia Tepluhina: 20:27

Nope. And even triaging and fixing pull requests and issues. It's still just a very minor point. It comes on the major releases, it's, like, huge spike of things, of course. On the minor releases, just a few things you need to fix, you need to add, you need to move around.

Alexander Lichter: 20:44

Like some new features to document

Natalia Tepluhina: 20:46

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

Alexander Lichter: 20:54

Oh, like internal methods. Mhmm.

Natalia Tepluhina: 20:57

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

Alexander Lichter: 21:01

If it breaks, up to you. Yeah.

Natalia Tepluhina: 21:03

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.

Alexander Lichter: 21:18

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

Alexander Lichter: 21:22

So it was like, getCurrentInstance the way using it.

Natalia Tepluhina: 21:25

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.

Alexander Lichter: 21:33

Mhmm.

Natalia Tepluhina: 21:34

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.

Natalia Tepluhina: 21:55

Like, do not touch getCurrentInstance, please.

Alexander Lichter: 21:58

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

Natalia Tepluhina: 22:03

people have lots of imagination.

Alexander Lichter: 22:06

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.

Alexander Lichter: 22:14

Often there is, or what you're trying to do might not really work. Like, you might have to shift your mental model around.

Natalia Tepluhina: 22:21

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.

Natalia Tepluhina: 22:47

Like, okay. If you need to use getCurrentInstance, one of those cases, and use this or that instead. From my experience, people always find the ways to use the things you don't want them to use.

Alexander Lichter: 22:59

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.

Alexander Lichter: 23:14

Why did

Natalia Tepluhina: 23:14

Why did you write it in the first place?

Alexander Lichter: 23:16

And, like, what like, okay. Yeah. What's your goal? Describe your goal. Like, the code doesn't do any of these.

Alexander Lichter: 23:21

Not even close. Like, yeah, but chat GPT sent that to Yeah.

Natalia Tepluhina: 23:24

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

Alexander Lichter: 23:27

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.

Natalia Tepluhina: 23:36

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.

Natalia Tepluhina: 23:57

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.

Natalia Tepluhina: 24:12

It's funny. I can promise.

Alexander Lichter: 24:13

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.

Alexander Lichter: 24:21

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.

Alexander Lichter: 24:40

They just don't know enough about it.

Natalia Tepluhina: 24:42

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.

Alexander Lichter: 24:58

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?

Alexander Lichter: 25:08

Natalia Tepluhina: 25:09

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.

Natalia Tepluhina: 25:20

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.

Natalia Tepluhina: 25:32

He joined the core the core team, and then he left because there was a little disagreement within the team about I think it was about certification.

Alexander Lichter: 25:41

Oh, mhmm.

Natalia Tepluhina: 25:42

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.

Alexander Lichter: 25:58

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

Natalia Tepluhina: 26:04

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.

Alexander Lichter: 26:14

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.

Alexander Lichter: 26:32

But if it's shitty, then people will complain. So it's either people complain or they select, okay, that's how

Natalia Tepluhina: 26:39

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.

Natalia Tepluhina: 26:47

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.

Natalia Tepluhina: 27:06

Write the docs for your own product and look how it goes.

Alexander Lichter: 27:09

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?

Alexander Lichter: 27:26

Some goals, some what you should not do. Like, so

Natalia Tepluhina: 27:28

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.

Alexander Lichter: 27:38

Mhmm.

Natalia Tepluhina: 27:38

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.

Natalia Tepluhina: 27:49

I can see, like, what's what's wrong about this.

Alexander Lichter: 27:51

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.

Natalia Tepluhina: 27:59

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.

Natalia Tepluhina: 28:19

But diagrams were extremely helpful. Like, we had feedback about them and way, way less questions about props in the slots pop up since we have this, like, little arrow thing. And you always need the way to find to explain something.

Alexander Lichter: 28:34

Yeah.

Natalia Tepluhina: 28:34

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.

Alexander Lichter: 28:41

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.

Alexander Lichter: 28:53

For example, also one reason why lots of content I do in in the Nuxt ecosystem. They could also probably go to the docs, but then the docs would be super long. Instead, I write a link to the video of, like, if you want more context than this, feel free to have a look. But if that's enough for you, that's fine. So, like, finding a good cutting point is, yeah, it's tricky too.

Natalia Tepluhina: 29:13

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.

Alexander Lichter: 29:30

Yeah.

Natalia Tepluhina: 29:30

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.

Natalia Tepluhina: 29:42

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

Alexander Lichter: 29:56

Mhmm.

Natalia Tepluhina: 29:57

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.

Alexander Lichter: 30:19

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.

Alexander Lichter: 30:47

So, that's one of the downsides of, like, nicely coupling everything to an own package is you have to understand the whole waterfall to, like, fully grasp something sometimes. Or, like, make

Natalia Tepluhina: 30:58

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?

Alexander Lichter: 31:09

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

Natalia Tepluhina: 31:11

Feature you're

Alexander Lichter: 31:12

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

Natalia Tepluhina: 31:44

Oh, yes.

Alexander Lichter: 31:45

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.

Natalia Tepluhina: 31:58

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.

Natalia Tepluhina: 32:16

It wasn't like this from the beginning. Some chapters were removed. Some chapters were like, we we were reading completely everything. And then once again, there was an additional rewrite after that. And Evan also participated in this additional rewrite quite a lot.

Natalia Tepluhina: 32:32

And then we're fixing things after Evan because, there are a few things still in the docs that break our own style guide. Like, if you're watching this and you want to contribute, go to the docs and search for foo and bar and replace them with something meaningful, because I'm tired of doing that already.

Alexander Lichter: 32:47

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

Natalia Tepluhina: 32:50

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.

Natalia Tepluhina: 33:03

Who is working on what? There were a few people working on the docs. Like, how do we write this? And lots of reviews too. Because when you write something important, critical, like, part about reactivity, It needs to go through multiple reviews because back in times also, we didn't have a clear understanding about what is preferable between reactive and refs.

Alexander Lichter: 33:24

Now we know.

Natalia Tepluhina: 33:27

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.

Natalia Tepluhina: 33:36

What do they prefer? Framework evolves, like, we and we write different recommendations as well.

Alexander Lichter: 33:42

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

Natalia Tepluhina: 33:45

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.

Natalia Tepluhina: 34:04

So yes. And documentation is ever evolving. Sometimes you also need to do what I call a cleanup. When you have multiple contributions, all of them make sense. You add them and add them and add them.

Natalia Tepluhina: 34:15

But when you read that chapter after this, it's not that nice. There is no user flow. It looks like it was combined from random pieces here and there. And you need to rewrite it again to make it smooth, remove warnings. People like adding warnings.

Natalia Tepluhina: 34:31

I don't know why. But they just want to put the warning, and we try not to. They break readers' attention. Like, imagine you're reading the text, like, warning, like, about something else. Tip.

Natalia Tepluhina: 34:41

Yeah. Again, warning, like, don't use it. It's really hard to follow. So, yes, it's like you need to track things because it's like a garden. You turn away, you come back, and it's all in weeds.

Alexander Lichter: 34:53

Clean up again.

Natalia Tepluhina: 34:54

And weeds will be growing all the time.

Alexander Lichter: 34:56

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

Natalia Tepluhina: 34:59

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

Alexander Lichter: 35:04

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.

Alexander Lichter: 35:11

I mean, I guess we all set it on ref nowadays.

Natalia Tepluhina: 35:15

Oh, I I still can see reactive in some cases where it makes

Natalia Tepluhina: 35:18

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.

Natalia Tepluhina: 35:32

And it's quite easy when people make contributions. So, again, thanks to everyone who created issues or pull requests, because this is how you can see what is the mood of the most active part

Alexander Lichter: 35:43

Yeah.

Natalia Tepluhina: 35:43

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

Alexander Lichter: 35:47

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.

Natalia Tepluhina: 35:58

That was a good example. Yes. Reactivity forms.

Alexander Lichter: 36:01

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.

Alexander Lichter: 36:10

Usually, use ref, but for form state, that might be a good case. But but commonly, you should maybe settle on on one way of doing things except you have a good reason to not to do it. So, yeah, it's a good idea to educate users about it as well and then sticking with what works. But it's also a problem if you have too many things to do like composition API, options API. It's also a big part, like, how right now, like, we have to toggle in Yes.

Alexander Lichter: 36:36

In documentation. We can, like, say, okay, for an Options API, composition API. We also talked about that, beforehand, like, various times. That that might be a bit tricky. Also, Evan agreed that, like, the the learning story for people coming to Vue is not okay.

Alexander Lichter: 36:50

We have these 2 APIs, and then you could technically even use, like, composition API without script setup, which is probably not in the docs anymore, but still we could just use a setup function also for migration and so on.

Alexander Lichter: 37:00

So what do you think could be, like, a solution to a a better learning path for for the users?

Natalia Tepluhina: 37:08

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.

Alexander Lichter: 37:35

Yeah.

Natalia Tepluhina: 37:36

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.

Alexander Lichter: 37:55

Yeah.

Natalia Tepluhina: 37:55

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

Alexander Lichter: 37:59

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.

Alexander Lichter: 38:19

Why not going for that?

Natalia Tepluhina: 38:20

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.

Natalia Tepluhina: 38:50

That's the biggest problem. Like, composition is amazing, and it also gives you a lot of freedom, which is a benefit if you're developing your own project or you have a few colleagues and you all agreed on like this. For bigger ones, you will need to invent your own convention. Otherwise, it will be really hard, and those conventions can be as silly as you want. I saw people grouping composition API, just like the options API.

Natalia Tepluhina: 39:14

They literally have data, like, methods Yeah. Computed commands.

Alexander Lichter: 39:18

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

Natalia Tepluhina: 39:22

maybe It's not the way, but

Alexander Lichter: 39:23

Yeah.

Natalia Tepluhina: 39:24

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?

Natalia Tepluhina: 39:39

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.

Natalia Tepluhina: 39:50

I'm sure not in the Vue docs because this is not the responsibility. Yep. It should be adapted adapted to the project. But there should be some kind of the guide, like, okay. You have this kind of how do you decide on your conventions?

Natalia Tepluhina: 40:05

How do you shape your code so that everyone can understand? So composition API is the way to go. Like, I think we all understand that it's it's kind of the future. There are libraries that only work with composition API.

Alexander Lichter: 40:17

Vapor mode coming up, also only for composition API.

Natalia Tepluhina: 40:20

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.

Natalia Tepluhina: 40:46

Yes. People want predictability from the code. Yeah. Options give them this predictability with some price. And this price being not the flexible code, like, very opinionated grouping.

Alexander Lichter: 40:59

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.

Natalia Tepluhina: 41:08

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.

Alexander Lichter: 41:16

Exactly.

Natalia Tepluhina: 41:16

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.

Alexander Lichter: 41:42

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

Natalia Tepluhina: 41:47

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

Alexander Lichter: 41:49

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.

Alexander Lichter: 42:19

Otherwise, you probably wouldn't be asked to help out. But still, it's it's super interesting that not that many people are like, okay, like in normal JavaScript, script, you write a function to, like, encapsulate your code.

Natalia Tepluhina: 42:28

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

Alexander Lichter: 42:31

Yeah.

Natalia Tepluhina: 42:31

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?

Alexander Lichter: 42:38

Okay.

Natalia Tepluhina: 42:38

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.

Alexander Lichter: 42:50

Yep.

Natalia Tepluhina: 42:51

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

Alexander Lichter: 42:59

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.

Alexander Lichter: 43:10

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.

Alexander Lichter: 43:18

Wow. But just leaving it in there, and then, like, Okay, I call my composables and reusable functions for that component just on the top. Maybe I pass in some state I get from other composables in there, or like, Okay, I have my v model bound to something that I passed in there. That totally makes sense. But making that connection, that took a little bit.

Alexander Lichter: 43:40

And I hope that something like this, like more architectural patterns, like how to deal with certain scenarios, maybe there will be somewhere documented to have, like, a bit of maybe something like a cookbook or best practices because then

Natalia Tepluhina: 43:51

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.

Alexander Lichter: 43:58

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.

Natalia Tepluhina: 44:03

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

Alexander Lichter: 44:09

Yes.

Natalia Tepluhina: 44:10

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.

Alexander Lichter: 44:22

Yeah. Yeah. I also like this, like, symbiosis, like, hey. It's always a feedback loop. Right?

Alexander Lichter: 44:25

You you do something. People use it. People complain about certain things. They, hey. We can improve this or we use it that way.

Alexander Lichter: 44:30

Does it make sense? For example, I also seen people saying they use, like, IIFEs, like, immediately invoked function expressions just in, the script part. So, like, okay, I don't want to reuse it. I just want to use it straightaway there to encapsulate things. So there are lots of interesting patterns, let's say, But, of course, they're also keeping misusing composables for other things or, like, don't know the difference between what a composable is and what a function is.

Alexander Lichter: 44:55

So, like or why do we even have to separate them? It doesn't matter. So, of course, talked about lots of these things, but, yeah, these these patterns and these practices, I think if we would see more of them contributed by by many people, like, suggesting suggested by many people, I think that would help the whole community.

Natalia Tepluhina: 45:14

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.

Natalia Tepluhina: 45:28

Right? Okay. And now I learned about in line composables, they will test it, bring it back, and this is how it goes. Yeah.

Natalia Tepluhina: 45:35

And I think it's natural process because at the beginning of Vue 2, I remembered there were so many people overusing watchers.

Natalia Tepluhina: 45:41

Oh, yeah. I don't know if you remember, like

Alexander Lichter: 45:42

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

Natalia Tepluhina: 45:46

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.

Natalia Tepluhina: 46:01

But this is what is happening with composables too. People try many different things. Sometimes, some of them are very wrong.

Alexander Lichter: 46:07

Mhmm.

Natalia Tepluhina: 46:09

And then we have some best practices crystallizing.

Alexander Lichter: 46:12

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.

Alexander Lichter: 46:33

So, also, that's like, okay. People have to come up with with ways dealing with that. Everything in terms of server side rendering, it's fine. Just like meta frameworks to deal with it. That's I understand the reason behind that because there's enough to deal in the the view core itself.

Alexander Lichter: 46:48

But, yeah, same applies there.

Natalia Tepluhina: 46:50

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.

Alexander Lichter: 46:57

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.

Alexander Lichter: 47:16

So, like, sharing knowledge even, like, you don't have to be the the best in in Vue. Js or, like

Natalia Tepluhina: 47:21

Absolutely not.

Alexander Lichter: 47:22

Don't. Just like, hey. ok. We do this in our company. This was useful.

Alexander Lichter: 47:26

So in our use case, yeah, wanna try it out. Here, this is how we do it. Why not? I think it's

Natalia Tepluhina: 47:31

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

Alexander Lichter: 47:41

Mhmm.

Natalia Tepluhina: 47:41

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.

Natalia Tepluhina: 47:52

And we have very active and nice community as you know.

Alexander Lichter: 47:55

Absolutely.

Natalia Tepluhina: 47:56

But the more content you produce and because it's also content. Creating an issue is a content. Yeah.

Natalia Tepluhina: 48:01

Creating pull request to docs is a content. Like, the more content you create this way, it's the better is for everyone.

Alexander Lichter: 48:07

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.

Alexander Lichter: 48:15

That was not a very satisfying answer. But

Natalia Tepluhina: 48:18

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

Alexander Lichter: 48:22

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.

Alexander Lichter: 48:31

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.

Alexander Lichter: 48:39

So we from DejaVue got a little 10% discount here. Link in the show notes. So if you wanna join, Natalia, you were in Berlin, the same conference, just one day. This this year is 2 days, 2 years ago, and, had a blast. I remember we, talked about there also.

Natalia Tepluhina: 48:53

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

Alexander Lichter: 48:56

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

Natalia Tepluhina: 48:59

Vanessa will be there.

Alexander Lichter: 49:00

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.

Alexander Lichter: 49:14

But, yeah, now let's talk about, what we already started a little bit. You said, like, okay, composition API, options API, and the same component.

Alexander Lichter: 49:22

I've seen it countless times people using composables and, like, the options API part and, like, uh-oh.

Natalia Tepluhina: 49:28

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

Alexander Lichter: 49:30

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.

Alexander Lichter: 49:42

It's also hold up like, that's once again another level. Yeah. How how did and do you experience that

Natalia Tepluhina: 49:52

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

Alexander Lichter: 50:00

In GitLab.

Natalia Tepluhina: 50:00

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

Alexander Lichter: 50:06

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

Natalia Tepluhina: 50:10

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.

Natalia Tepluhina: 50:33

And even more unfortunate, and here people are going to blame GitLab a lot, what happened with the GitLab's component library is that we wanted first to build it as a beta, like, just to try things. And as a beta, we wrapped bootstrap view components with our own components, passing everything with the bind address. And then the idea was that when we have it in place, we exclude bootstrap view from the main codebase as dependency. We use our only our own component library, and then we can rewrite components. This step never happened.

Alexander Lichter: 51:05

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

Natalia Tepluhina: 51:09

Later.

Alexander Lichter: 51:10

Never. Mhmm. Yeah.

Natalia Tepluhina: 51:12

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.

Natalia Tepluhina: 51:26

And here comes the problem. Boodstrap never migrated to Vue three. There was a valiant effort from one of our team members, also super active in the Vue community, Ilya. Mhmm. He worked he took over the Bootstrap Vue and tried to at least make it work with compat, which is already a huge step.

Natalia Tepluhina: 51:47

Unfortunately, making it work with Vue 3 is not possible. It will be literally the rewrite, and the rewrite is already happening in the other library. It will bootstrap Vue next.

Alexander Lichter: 51:56

Mhmm.

Natalia Tepluhina: 51:56

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.

Natalia Tepluhina: 52:13

It didn't exist, so we brought our own state management back in time.

Alexander Lichter: 52:18

Still in the code?

Natalia Tepluhina: 52:19

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

Alexander Lichter: 52:24

So Vuex, Pina?

Natalia Tepluhina: 52:26

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

Alexander Lichter: 52:29

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

Natalia Tepluhina: 52:32

But, yeah, it's a pretty big

Alexander Lichter: 52:33

project.

Natalia Tepluhina: 52:34

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.

Natalia Tepluhina: 52:43

On some pages, multiple Vue applications don't do these kids. On some pages, it's up to 20 Vue applications.

Alexander Lichter: 52:51

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

Natalia Tepluhina: 52:57

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.

Natalia Tepluhina: 53:30

That's why we can tweak different parts a bit differently. But, yes, lots of tests failing, lots of old practices being used. It took some time to clean it even from old slot syntax.

Alexander Lichter: 53:44

Oh, okay. You remember when

Natalia Tepluhina: 53:45

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.

Alexander Lichter: 53:56

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

Natalia Tepluhina: 53:59

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

Alexander Lichter: 54:01

Yeah. Okay.

Natalia Tepluhina: 54:03

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.

Natalia Tepluhina: 54:21

And sometimes it takes a lot of time to even understand why why it's happening, why the node is rendered not right now in a different way. Yeah. Like, with binary attributes, like disabled. A few of them. Right?

Natalia Tepluhina: 54:36

They disabled and checked and whatnot. It's very different between Vue 2 and Vue 3. Sometimes it goes about the testing practices. Like, I had to talk why we use why why shouldn't you should use shallow mount and had lots of discussion with people who love mount. But now try to imagine that you have a component tree with a depth of 12 at the maximum from root to the child component, and you mount the root one in the test.

Natalia Tepluhina: 55:04

And it fails. I have no idea why.

Alexander Lichter: 55:06

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

Natalia Tepluhina: 55:09

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

Natalia Tepluhina: 55:16

And we migrated to Vue 2.7. And just to give you an idea, we prohibited people to use composition API in Vue 2.7 because we don't want to deal with more problems during migration. And inevitably, we would just because the people that never wrote composables, starting with composables is going to have some learning curve.

Natalia Tepluhina: 55:37

Alexander Lichter: 55:38

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.

Natalia Tepluhina: 55:47

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.

Natalia Tepluhina: 56:09

I learned. I didn't know that you can the property.

Alexander Lichter: 56:12

That sounds interesting. Okay.

Natalia Tepluhina: 56:15

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.

Natalia Tepluhina: 56:27

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.

Natalia Tepluhina: 56:42

But Vue 2 basically says this is undefined. It's okay. If it's not directly preventing the method from the execution, you will never see it, which you just called with undefined. Defined. In Vue 3, in tests, if you miss the property, the test will be like, this is missing.

Natalia Tepluhina: 57:01

I found the component that is missing 6 properties. I have no idea how this past the review.

Alexander Lichter: 57:06

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

Natalia Tepluhina: 57:09

by when you have 3,000 tests failing.

Alexander Lichter: 57:11

It's not fun anymore.

Natalia Tepluhina: 57:13

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.

Natalia Tepluhina: 57:28

So this just gives you an idea that migration of the old big project is a bit different from migrating the small personal one or the one that was more modern. At least, we're getting after view 2.6. At least slow scope is doesn't require cleaning, or you don't or you don't use view delete because you know it's bad now. Or you don't mutate your commuted properties. Don't do this again.

Natalia Tepluhina: 57:55

And I think that, unfortunately, this scope of old big projects with massive teams was not the target audience when, we as a core team developed a migration path. Because there is a helper, it doesn't help. There is testing library that unfortunately is very problematic when you start dealing with the migration. There are many things with dependencies. It's not exclusive to Bootstrap View.

Natalia Tepluhina: 58:21

Vuetify took really long time and lots of effort to just get there. And imagine that were there were project dependent on Beautify. Nuxt took some time.

Alexander Lichter: 58:31

Really? I can't remember. Nuxt

Natalia Tepluhina: 58:34

bridge took some time.

Alexander Lichter: 58:35

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.

Natalia Tepluhina: 58:45

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.

Natalia Tepluhina: 59:05

That was a big, big, big shift. Right? Like, if a library were just calculating some things, I think form validation libraries moved faster

Alexander Lichter: 59:13

Mhmm.

Natalia Tepluhina: 59:13

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.

Alexander Lichter: 59:29

All gone. Yeah.

Natalia Tepluhina: 59:30

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

Alexander Lichter: 59:34

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.

Alexander Lichter: 59:58

So, yeah, that's all in addition to, like, updating the library with the internals. And as you said for a project, I've seen lots of, like, migrations, and they usually often have, like, a big, big table library and then not needed or there's a replacement or, well, we have a problem.

Natalia Tepluhina: 01:00:16

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.

Natalia Tepluhina: 01:00:33

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.

Natalia Tepluhina: 01:00:46

Like, oh, you're using Vue two.

Alexander Lichter: 01:00:47

Yeah.

Natalia Tepluhina: 01:00:48

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.

Alexander Lichter: 01:00:58

Yeah.

Natalia Tepluhina: 01:00:59

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.

Alexander Lichter: 01:01:13

Vue Two to Three migration.

Natalia Tepluhina: 01:01:15

Like, story of my life.

Alexander Lichter: 01:01:17

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.

Alexander Lichter: 01:01:36

They might also, like, get some teeny tiny points with, like, okay, we can try this. We can do this.

Natalia Tepluhina: 01:01:40

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.

Natalia Tepluhina: 01:01:50

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.

Alexander Lichter: 01:02:02

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

Natalia Tepluhina: 01:02:07

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.

Natalia Tepluhina: 01:02:19

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.

Natalia Tepluhina: 01:02:33

I understand many people will disagree, like, I like snapshots. But, lord, the snapshots testing is every snapshot is different between Vue 2 and Vue 3.

Alexander Lichter: 01:02:43

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

Natalia Tepluhina: 01:02:45

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.

Alexander Lichter: 01:02:53

Yeah.

Natalia Tepluhina: 01:02:53

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

Alexander Lichter: 01:03:01

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.

Natalia Tepluhina: 01:03:07

It's fine.

Alexander Lichter: 01:03:08

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

Natalia Tepluhina: 01:03:26

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.

Natalia Tepluhina: 01:03:43

Mhmm. Like, we I think we didn't have any problem back with Vuex or VueRouter. A few fixes here and there, but Yeah. Not nothing major, neither with, not core, but important for us was Vue Apollo. Mhmm.

Natalia Tepluhina: 01:03:56

Pretty good, pretty well compatible with View. Yep. Compat mode as well. So, like, I cannot blame anything from the core, honestly.

Alexander Lichter: 01:04:05

Just the others.

Natalia Tepluhina: 01:04:06

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.

Alexander Lichter: 01:04:15

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.

Alexander Lichter: 01:04:31

Write an issue. Write the, hey, here's a try.

Natalia Tepluhina: 01:04:35

It was also, multiple contributions to Vue compat

Alexander Lichter: 01:04:38

Mhmm.

Natalia Tepluhina: 01:04:39

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.

Alexander Lichter: 01:04:45

Oh, well.

Natalia Tepluhina: 01:04:46

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.

Natalia Tepluhina: 01:04:57

But maybe it will merge later and you can just update and remove your patch. So

Alexander Lichter: 01:05:01

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?

Natalia Tepluhina: 01:05:09

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.

Natalia Tepluhina: 01:05:21

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

Alexander Lichter: 01:05:28

so nice to just, like, have properties everywhere.

Natalia Tepluhina: 01:05:31

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.

Natalia Tepluhina: 01:05:43

Don't do this.

Alexander Lichter: 01:05:44

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

Natalia Tepluhina: 01:05:47

That's the problem with detection.

Alexander Lichter: 01:05:49

Yeah. It's not that. Yeah.

Natalia Tepluhina: 01:05:51

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.

Alexander Lichter: 01:06:00

Yeah. Yeah.

Natalia Tepluhina: 01:06:00

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

Alexander Lichter: 01:06:06

No. I see.

Natalia Tepluhina: 01:06:07

Un unref them.

Alexander Lichter: 01:06:11

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

Natalia Tepluhina: 01:06:17

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

Alexander Lichter: 01:06:21

Yeah.

Natalia Tepluhina: 01:06:22

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.

Alexander Lichter: 01:06:31

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?

Natalia Tepluhina: 01:06:40

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

Alexander Lichter: 01:06:52

Mhmm.

Natalia Tepluhina: 01:06:52

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.

Natalia Tepluhina: 01:07:08

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

Alexander Lichter: 01:07:21

Mhmm.

Natalia Tepluhina: 01:07:22

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.

Natalia Tepluhina: 01:07:37

Yeah. So our best best possible for right now is get to compat mod 3, which will give us headache with tests. But

Alexander Lichter: 01:07:48

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.

Natalia Tepluhina: 01:08:06

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.

Natalia Tepluhina: 01:08:25

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.

Natalia Tepluhina: 01:08:41

Sometimes it's in the components, not the or in the tests, how you manage your tests to fix them. So, like, if in the beginning, it feels like, yeah. Oh my god. How how I'm fixing those? It will be it will get easier as you go.

Natalia Tepluhina: 01:08:54

So this this is a good part. And some of the things are still fixable with the compatibility tool. You can just or your own. Like, you can really write code modes. It will fix things for you with some human inspection after.

Alexander Lichter: 01:09:08

Mhmm.

Natalia Tepluhina: 01:09:08

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

Alexander Lichter: 01:09:13

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

Natalia Tepluhina: 01:09:15

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

Alexander Lichter: 01:09:19

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.

Natalia Tepluhina: 01:09:33

Alexander Lichter: 01:09:34

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

Natalia Tepluhina: 01:09:37

And turn's already good.

Alexander Lichter: 01:09:38

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

Natalia Tepluhina: 01:09:42

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.

Natalia Tepluhina: 01:09:53

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.

Natalia Tepluhina: 01:10:13

You will need to enable mode 3 component per component. If you don't have tests, definitely don't enable it for the whole application. There will be places it will break, and you will have no idea. Go component per component. Check the warnings that you have in the dev mode.

Natalia Tepluhina: 01:10:29

Try to reduce the number of warnings to 0, move on to the next component, and start writing tests.

Alexander Lichter: 01:10:36

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

Natalia Tepluhina: 01:10:39

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.

Alexander Lichter: 01:10:45

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.

Natalia Tepluhina: 01:11:01

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.

Natalia Tepluhina: 01:11:19

You cannot because, apparently, now it's a system where you touch one place and everything's ruined immediately. So you will need to decide for yourself, honestly. Sometimes, yes, it makes sense to burn it in the right. Sometimes

Alexander Lichter: 01:11:33

it's not possible. Yeah.

Alexander Lichter: 01:11:35

And there's also a third way we didn't really touch. Or, well, you kinda did a little bit. What if we don't migrate at all?

Alexander Lichter: 01:11:41

What if people just, like, okay. We stay on v 2 till the end of day.

Natalia Tepluhina: 01:11:45

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.

Natalia Tepluhina: 01:12:03

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.

Natalia Tepluhina: 01:12:16

If you just need to maintain it and you're not adding any new features at all

Alexander Lichter: 01:12:20

Don't touch it.

Natalia Tepluhina: 01:12:20

Let it be. It works. Yeah. Right? It works.

Natalia Tepluhina: 01:12:22

Don't touch it.

Alexander Lichter: 01:12:23

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

Natalia Tepluhina: 01:12:27

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.

Natalia Tepluhina: 01:12:53

I'm not even sure it's compatible with Vue 2, honestly.

Alexander Lichter: 01:12:56

Right now, I don't think so.

Natalia Tepluhina: 01:12:56

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.

Natalia Tepluhina: 01:13:08

So enjoy axios.

Alexander Lichter: 01:13:11

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.

Natalia Tepluhina: 01:13:32

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.

Natalia Tepluhina: 01:13:46

It's diffs. When you render 10,000 components, the difference is there.

Alexander Lichter: 01:13:50

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

Alexander Lichter: 01:13:54

And you mentioned, like, with migrations, stick to the options API first, and then when everything works, move forward?

Natalia Tepluhina: 01:14:00

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.

Natalia Tepluhina: 01:14:15

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.

Natalia Tepluhina: 01:14:35

We have Vue docs for that. Yeah. But how do we use composition API?

Alexander Lichter: 01:14:38

At GitLab.

Natalia Tepluhina: 01:14:39

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.

Alexander Lichter: 01:14:51

100%.

Natalia Tepluhina: 01:14:52

On the scale, it just it just easier.

Alexander Lichter: 01:14:55

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.

Alexander Lichter: 01:15:08

All composables, they should handle refs if you put them in also normal values. Like, there there are some things, like, providing composables, and we mentioned also when we talked about VueUse in a previous podcast episode, like, they're super helpful, and companies can adopt them already. Like, there's a really good page on that. So probably you also at GitHub adapt some of them. And at least developer developer says, no.

Alexander Lichter: 01:15:29

It's not a good idea. But in in most cases, it might be.

Natalia Tepluhina: 01:15:33

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.

Natalia Tepluhina: 01:15:52

Now we see there are a few problems already here. So we probably will go this way. We'll go that way.

Alexander Lichter: 01:15:58

Mhmm.

Natalia Tepluhina: 01:15:58

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.

Natalia Tepluhina: 01:16:15

But I never felt the need to create an observable in tests as a mock value. Yeah. But, apparently, now you have the test where you use use a router, and you don't mock it away. Or you use some terms of the composables, and you want to mock the value composable returns. This also happens.

Natalia Tepluhina: 01:16:31

Do you even mock the composable returns or not? That's also the question. True. If you do like, for me, seeing computed or have been imported in test file, for example, was new, and this sparks discussions.

Alexander Lichter: 01:16:43

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.

Alexander Lichter: 01:16:53

And then

Natalia Tepluhina: 01:16:53

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

Alexander Lichter: 01:16:58

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

Natalia Tepluhina: 01:17:00

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.

Natalia Tepluhina: 01:17:22

And, like, without this experience, I use this every day. I stepped on this Lego a million times. Now I can tell you how not to step on it. That's the point where you want this experience.

Alexander Lichter: 01:17:34

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

Natalia Tepluhina: 01:17:39

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.

Alexander Lichter: 01:17:52

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?

Natalia Tepluhina: 01:17:58

Besides crying, no.

Alexander Lichter: 01:18:01

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.

Alexander Lichter: 01:18:09

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.

Alexander Lichter: 01:18:16

What do you think could the Vue team have done better to, like, more incorporate these, like, bigger projects in terms of migration?

Natalia Tepluhina: 01:18:23

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.

Natalia Tepluhina: 01:18:48

So involving this communication a bit earlier would be super nice. But it's also not only with Vuetim. It's also about what we talked earlier. People should be more vocal about their feelings, and they should be more vocal publicly. Being open to this.

Natalia Tepluhina: 01:19:04

That's constructive criticism being brought to the higher level.

Alexander Lichter: 01:19:07

Yeah.

Natalia Tepluhina: 01:19:07

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

Alexander Lichter: 01:19:12

Really. Yeah.

Natalia Tepluhina: 01:19:13

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.

Natalia Tepluhina: 01:19:35

No.

Alexander Lichter: 01:19:36

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

Natalia Tepluhina: 01:19:38

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.

Natalia Tepluhina: 01:19:53

That's a very cool idea. Gives me some food for thoughts and talks. If you if you have any experience saying, like, wanna share a story, why not submit it? Local meetups, conferences. There are quite some cool conferences coming on that we already talked about.

Alexander Lichter: 01:20:06

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

Natalia Tepluhina: 01:20:11

there will be more to come after. Right?

Alexander Lichter: 01:20:13

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

Alexander Lichter: 01:20:21

Maybe one last tip before we wrap it up. I have to mention, Michael is not here today, but he released, when this podcast, will come out, it's already out, on the August 5th. His Nuxt Tips collections with, more than 100 tips available at with the code deja view awesome show notes. You get $10 off. It's more than 10% discount.

Alexander Lichter: 01:20:39

So, if you're interested in that and, Nuxt developer, they'll have to get you more involved into using Nuxt a bit more, entirely.

Natalia Tepluhina: 01:20:46

We do have the part of the documentation, Nuxt.

Alexander Lichter: 01:20:49

That's true. GitLab is using Nuxt.

Natalia Tepluhina: 01:20:50

Yeah. We do.

Alexander Lichter: 01:20:51

Very important.

Natalia Tepluhina: 01:20:52

Nuxt two. So

Alexander Lichter: 01:20:53

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.

Alexander Lichter: 01:21:00

And, then my last question is, any any other things, the other topics that you

Natalia Tepluhina: 01:21:05

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.

Natalia Tepluhina: 01:21:13

Thank you for inviting me.

Alexander Lichter: 01:21:15

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

Natalia Tepluhina: 01:21:22

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

Alexander Lichter: 01:21:26

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.

Alexander Lichter: 01:21:36

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.

Alexander Lichter: 01:21:45

Write all the migration questions, and Natalia should answer all of them. We promise. No. But we'll we'll reach for all of them anyway. And, yeah, see you soon, folks.