Hacker News Reader

Comment by moogly | Hacker News Reader

As a TypeScript user who always disliked the object API and preferred vue-class-component, I feel a bit left out in the fallout of this. JavaScript users are always the loudest. IMO there is no clear, great option for people who are TS devotees. Again it feels like TS was an afterthought.

Will have to experiment a bit. Maybe it's possible to do something decent with some helper functions.

View on HN

They've said improved TypeScript support was a major motivator for this new syntax, and for Vue 3 in general. It just doesn't look like class components.

Class components seemed to be the best bet with the issues introduced over the past 6+ months. Issues that have languished presumably due to work on Vue3.. Which looks like it's a ways off still?

I disagree. Overall v3 will be more TS friendly as they’re working to make the lib more functional and less reliant on JS syntactic sugar like classes, hocs, and mixins.

Don’t the existing and new apis have type definitions?

Why do you feel left out?

I started writing a huge post with examples from the RFC and how I'd like things to look, but it became too involved and large, and no one wants to read that crap. I'll just summarise it with that props are problematic, both the old-school ones (which don't use TypeScript types at all, instead uses its own ad-hoc type system `{type: ..., required: ..., defaultValue: ...})` and the rather horrible `(null as any) as PropType<{ msg: string }>` type annotations for complex types and the "TypeScript-only Props Typing" which is better but does not have a way to set default values that I can see. Oh, also all props are optional per default which is not what you want in a `--strict` TypeScript project (which should be any new project).

Generally it's relying strictly on type inference instead of interface declarations, which might make edit-time type safety work OK, but lack in error messages (spewing out complex inferred type definitions) and overall readability (much more easier to reason about an interface you wrote yourself).

Also, everything inside the setup function are just variables and functions, so your editor will colour/highlight everything the same, whereas in the class proposal, you have clearer separation between properties (props/data), getters (computeds), methods and even static methods. It's just less messy. Now, I get that classes don't work with React hooks, and the other reasons for dropping classes are rather sound, but I really think that whole setup "God" function is a massive eyesore. TypeScript isn't only about correct type inference, it's also about improved ergonomics, readability, and, pardon the pun, less typing (on a keyboard).

I guess I wrote too much again...

Reply on news.ycombinator.com