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

[LifeIsStrange]

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

[ktsn]

Please search the existing issue #447

[LifeIsStrange]

@ktsn I have seen your current proposal (mixin)
first question: what does required: true mean ?

By making every props an object this still remain very verbose and what is the technical reason for Props to be necessarily outside of the class ? Is there hope that a next version of Vue or of Vue class component can alleviate this issue ?

[ktsn]

As I wrote:

They receive as the same value as component props and emits options

required: true is the exact same as Vue's canonical option.
https://v3.vuejs.org/api/options-data.html#props

what is the technical reason for Props to be necessarily outside of the class

This is also stated in the proposal, by using decorator we cannot type Props type property, then we cannot utilize up comming advanced type features like props type checking. (I saw Evan just announced it https://twitter.com/youyuxi/status/1307398376464539648)

Also If you don't like to define props in details you can just use simpler options shape:

const Props = props(['msg'])

export default class HelloWorld extends Props {}

[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.

[ktsn]

Thank you for your feedback. Let's consolidate the discussion in #447

[EnderKilledYou]

Yeah, this really feels like step backwards. Every time I used vue2 with class components I felt like I was designing things. With vue 3 I feel like I'm designing thing but I'm chained to someone's stoned ego and pontifications of "How it should be done properly and way too broadly"

vue 2 class components was peak vue. I may just stay in that ecosystem. Thanks for all the code.

[LifeIsStrange]

@EnderKilledYou I agree the class component API was peak clarity and conciseness.
Since it is currently unmaintained you might want to use
https://github.com/facing-dev/vue-facing-decorator

[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.