Source
r/vuejs•
anothermonth

Upgrading to Vue 3: v-model

Aside from other breaking changes, v-model is the one that sets me off the most. Our project is 200+ components, around a quarter of them have v-model and most of the rest use those components. Sometimes via v-model, sometimes with @input event, occasionally with both.

I'm not looking forward to rewriting all of this mess. What are your plans for Vue 2 -> 3 transition for medium-to-large projects?

I'm seriously considering delaying it as much as possible, perhaps waiting until intermediate bump to 2.7 and putting my faith (praise be!) in some automated upgrade tools that were promised in the roadmap.

Posted Mar 5, 2021, 3:29 PM UTC

3828
ulti-ulti•

I'm waiting for Vuetify to be ready for v3

25
queen-adreena•

The alpha just released a few days ago, but there's barely any components available for it at the time of writing.

3
cagataycivici•

If you like material design, PrimeVue has numerous material themes. This link opens the showcase in material theme, there are many other like bootstrap, fluent as it is design agnostic. It has Vue 3 support since October.

0
benabus•

I have no intention on migrating from 2 to 3 on existing projects. New ones will be written in 3, though.

15
anothermonthOP•

Interesting, I assume this is near term? I'd guess I'd be okay with this long term (year+) if there was no active development. But this is not the case with our project.

But yes, new projects are Vue 3 + typescript all the way.

4
benabus•

We're grant funded, so we tend to work on things piecemeal based on how our grants go. We usually don't have the time or resources to do migrations like that. We'll have like 6 months to add X feature working on it 25% of our time. If we were to migrate everything to the latest version every time we got a chance to work on a project, we'd be spending all our time with migrations and never fulfill the grant requirements. It's come back to bite us more than once, unfortunately, but we usually take a "If it's not broke, don't fix it" approach to most of our projects.

If I had one big project that I was working on 100% of my time, it might be worth it to migrate, but that's not the case here. Such is life in academia :(

8
Vahlk•

This is the way.

3
Cheshamone•

Tell me about it. Most of the other changes are "Ok that's no big deal to migrate", but this one is a major pain. Haven't really even considered upgrading yet because the ecosystem still seems pretty unstable tbh.

11
rema96•

We are in the same bucket. Our biggest project is around 90k lines (you read that right) and 350+ components. Migrating that is basically impossible, therefore, I am looking for different ways to approach this.

Either use webpack 5 and module federation to run Vue 2 (compiled) inside Vue 3. Essentially micro frontends with Vue all around.

Or another idea is to use vue-demi to slowy rewrite components in Vue 3 and import them with demi in vue 2 (existing platform), repeat this until we have everything rewritten.

I am really looking for other's to share their opinion and discuss different approaches.

10
douglasg14b•

Why do you think that is impossible to migrate?

I, alone, have done larger and more difficult migrations before... It just took time.

If you have a whole team behind you it gets that much easier.

This is a rather easy migration, It's so simple that it can be performed with a marginally complex find and replace... Or you could just write your own tokenizer and have it sort it out for you.

2
rema96•

I am not talking about a migration for the sake of bumping the version number (removing deprecated api). Talking about a refactor that will use the benefits of the composition API for some components like wizards and others that we solve currently with mixins. In a way it will be like writing from scratch plus refactoring all the pages with new components.

Just to point out I am not mad at Vue, it is a necessary change for an added benefit. No one if forced to upgrade and Vue 2 is perfectly fine. We see a DX benefit in updating that is why I am looking at it.

1
OriginalSyn•

I was never a fan of v-model. Having come from AngularJs where it was too magical in doing things under the hood for you, one of the things I decided for the team as part of our code standards was explicit over implicit including to avoid v-model and just use the more verbose v-bind:prop & @input/@change. I'm glad I did, avoids a whole class of migration issues.

8
billymcnilly•

Agreed, at least for custom components. I use v-model for form inputs and such. I always find myself using v-bind and emit explicitly because i actually forget that you can use v-model on a component. And when i do remember, it feels a bit nebulous. Already binding several other things, and emitting multiple things also

1
aleaallee•

I think the "magical" directives are a charm of Angular and Vue(not AngularJs because it was a mess). I feel a lot more productive when I code in Angular and Vue compared to React.

1
Smilinkite•

Yeah. For us the v-model changes will also be the major work of migrating. It's mostly administrative though, so it's doable.

4
sproingie•

I really wish they kept the .sync modifier and just made it an alias for the new v-model behavior. Would have made for a seamless migration path for anything not already married to v-model as an idiom (such as form widgets usually are)

3
thankyou_not_today•

Sorry for being uninformed, but what difference does vue3 bring to the v-model syntax/method?

3
anothermonthOP•

Read up "BREAKING" parts here: https://v3.vuejs.org/guide/migration/v-model.html

1
anothermonthOP•

I think their motivation was the conflict with native value attribute. For example guidelines suggest avoiding one word component names for similar reason.

2
starfox64_0•

I’m not technically employed as a dev, though looking for my first junior job, but I’ve simply gone with the route of write new stuff in Vue 3 and don’t worry about writing in Vue 2 if I don’t have to, granted, obviously I’m not working on massive code based that are already done and for professional reasons so I have that luxury.

It seems like a lot of the popular classes on Udemy (at least when I last looked) takes this approach as well by teaching Vue 3 then teaching Vue 2 afterwards in case you need to mess with legacy code.

2
kryptoneat•

Reading all these comments make me fear the plan will be community split for some people.

2
ShetlandJames•

Oof we are probably close to 800 components. I had no idea v-model was affected?

1
JinSantosAndria•

Can you not write a vue2-compat plugin that reintroduces v-model and it's behaviour?

1
Easy-Philosophy-214•

I'm with you.

IMO they absolutely botched Vue.... Having 2 versions is the beginning of the end (see Angular).

-6†
godbrain•

I'm surprised more people don't have this opinion. After Angular became a total rewrite and pissed off so many you would think Vue would not have gone down this road. I pretty much told my boss, oh Vue won't make the same mistake and here I am with a major Vue 2 app and the same situation we had with AngularJS. I was selling Vue to everyone and really made this my main frontend framework over Angular and React and now I'm note sure I made the right decisions.

1
Environmental-Cap-92•

After seeing migration issues on vue 1 to vue 2, and many breakages in libraries vee-validate 2 to 3, vuetify 1 to 2, etc...

I began moving as much as possible to vanilla js and html 5 custom elements. Trying to reduce my exposure to such. modularizing so that breakages do not impact a large footprint. So far this method has been the least worrisome for me at the moment.

The downside is some components you need to build from ground up, e.g. interactive tables and combobox+autocomplete+multiselect+tags.

Although there are web components built by others available, however, they use things such as lit-element, stenciljs etc. which adds learning curve and dependency.

Finally, if there is really a need to use libraries, etc, then use one where there is a corporation supporting it like ant design vue.

1
Arkhenstone•

It all depends on the size of the project and peoples you work with. Develop and migrate a vue app is in my opinion cheaper than developing in vanilla JS.

1
sh1td1cks•

I need to hear and understand the rationalization behind the versioning portion of your statement.

0
[deleted]•

[deleted]

0