11–20 of 34 posts
Will have to experiment a bit. Maybe it's possible to do something decent with some helper functions.
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.
Why do you feel left out?
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.
:).
A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it has gained so much popularity as I don't think you can make it more KISS.
Transition from vue1 to vue2 was really simple. I just hope that when the dust settles and things are finalized, Vue remains true to it's core of keeping things simple.
I have to admit - I had the same reaction that many people had when the function api first appeared ("what is this insanity and why are you breaking everything i love"). But I read through, checked out the new (simpler) example, read Evan's arguments about logical task grouping, and on a second read with a more-open mind, I actually kind of like the new syntax and am now looking forward to trying it out. I'm glad the…
My favourite part is the re-usability of the functions it encourages and the fact it breaks up the core Vue into individual functions (instead of one big module with options) which means Webpack can tree-shake not only your code but Vue's, resulting in far smaller libraries. Edit: After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to pr…
That's a bit of a shame. I know it's a bit more work, but I wonder if they could have added in a switch where the compiler knows whether its object syntax vs function component syntax where the tree shaking is expected.
Reading the comments here and on previous Vue thread, I see a nice example of psychological reactance at play. First, it was "You're going to replace the API? No no don't do this, don't force us to use this new thing that sucks over the old better one!". Now, it is "Oh, so you're not going to replace the old API? Come to think of it, the new API is a really nice idea, has some pretty useful concepts in it!". :).
Reading the comments here and on previous Vue thread, I see a nice example of psychological reactance at play. First, it was "You're going to replace the API? No no don't do this, don't force us to use this new thing that sucks over the old better one!". Now, it is "Oh, so you're not going to replace the old API? Come to think of it, the new API is a really nice idea, has some pretty useful concepts in it!". :).
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.
Don’t the existing and new apis have type definitions? Why do you feel left out?
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...
I think the best part about Vuejs right now is how simple it is and everything just works! A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it has gained so much popularity as I don't think you can make it more KISS. Transition from vue1 to vue2 was really simple. I just h…