Will the Vue 3 (class component) props API improve ?

The default component generated with vue cli is like this

@Options({
  props: {
    msg: String
  }
})
export default class HelloWorld extends Vue {
  msg!: string;
}

versus the Vue2 version (class components + property-decorators)

export default class HelloWorld extends Vue {
  @Prop() msg!: string;
}

Reasons why the new API is an obvious downgrade:

1. Boilerplate wise the new version has a fixed cost of 4 new lines + an additional cost of one redundant line per Prop, this is huge especially for something as common.
2. You literrally write the same lines twice beyond the boilerplate aspect this is really annoying for thinking process of the dev as it is a non-sensical action (or at best an implementation detail that should never have leak) 2.1) You write the same types twices making no use of TS inference but actually you can write msg: Number which is an error that will not be catched at compile time.
3. the worst point is that

export default class HelloWorld extends Vue {
  msg!: string;
}

On the line msg!: string; you have zero visual information that tells you that msg is indeed a Props, one must lookup manually on the props object and remember the association (error prone, and take harmfully cognitive load).

Can this be solved before every sane dev jump on the react ship ? 'sorry for the snark I try sincerely to be constructive here.

@ktsn

[kenkopelson]

Well, honestly, the way it all works in Vue 2 is great, and it seems you are choosing a future thing like property type checking to override a much more important thing like easy-to-read syntax, and clean code. If you really want to type the properties, just allow the specifying of the type in the @Prop() decorator, like @Prop(int) value = 0, or something of that nature. Anyhow, those are my thoughts, as one who used the Vue 2 class method of defining components quite extensively. Thanks.

[EnderKilledYou]

@LifeIsStrange this is what I was looking for.

They should be solving problems like the list item view state debacle not rewriting stuff.

When you get a list of items that end up getting rendered holding state for each item not-trivial.

I’ve considered using Proxy({}, { } ) and custom getter setters that check the base object for the property and return get/set but then hold a state for the same object. I know vuex and such are for state but when you’re rendering a list it adds to much abstraction.

Simply put, if I were to get a list of long running back ground processes and I wanted keep a state AROUND a single object outof the list it requires coercing the object some how out of vuex or it’s state via an id index. There needs to be a vue solution for this. Per object state that works well with render changes.

I have a list of long running processes. I need to send a message to cancel one. I need the error message next to the button so the user look at a familiar place. I need the response from using that object to affect that object’s internal vue state but not it’s persistent remote values. Per Object State

so far proxy is the best solution but it lacks typing that my ide so loves. Who wants to type :blah=“soemobj.WHATDIDINAMETHATSHIZAGAIN” … so it’s not PERFECt.

I bet you they started writing in rust.

Rust rots programmers brains and creeps out to other languages. It’s just terrible. If they suddenly (the vue devs) doing a lot of rust the last few years that’s why. It’s like a turing machine, put in rust, rewrite existing good code to be more “rusty” at the same expense as why no one likes rust. it looks like dog doo.