Will the Vue 3 (class component) props API improve ?
See original GitHub issueThe 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:
- 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.
- 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.
- 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.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:11
- Comments:8 (3 by maintainers)
Top Results From Across the Web
From vue-class-component to Composition API
Vue 3 is on the market for a while now. Time to ditch your Vue 2 class components and go for the all...
Read more >The Complete Guide to Provide/Inject API in Vue 3: Part 1
Get started building plug-ins using Vue 3's Provide/Inject API. Learn about Props, Prop Drilling and how to solve the side effects of Prop...
Read more >Vue 3 - Tips & Best Practices - Medium
Get tips and the best practices when working with the latest version of Vue, Vue3. Learn how you can really utilize the key...
Read more >Props | Vue.js
We use PascalCase for component tags when possible because it improves template readability by differentiating Vue components from native elements. However, ...
Read more >vue3 class component access props - Stack Overflow
That would only work for Vue 2. The API has changed for Vue 3. – tony19. Mar 29, 2021 at 20:11.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
@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.