Hacker News Reader

Comment by avolcano | Hacker News Reader

I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone who hasn't yet adopted them in my React projects, either).

This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.

View on HN

I really disliked the function API and felt the class API with decorators was much easier to read and work on.. I'm pretty sad they are doubling down on function API and, apparently, ditching the class API?

The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.

Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.

In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).

I’m curious what it means for people using single page components and how the default exported module would be structured with the new API. All the examples use the inline template strings.

The primary change seems to just be merging most of the keys/options (data, computed, watchers, etc) of the module into various functions within setup() which itself may require from coding best-practice guidelines since setup() is going to get pretty big.

I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.

I've noticed this example of converted component on the RFC discussion: https://gist.github.com/Akryum/6eff23ae9f7483d6b5151c26d1884...

Reply on news.ycombinator.com