Use standard JS classes instead of custom syntax?

[nullptr128]

Hello!
First of all, I'd want to thank you for providing this great library.

After creating few projects with Vue I've came across an idea - could it be possible to allow using ES6 classes in place of standard Vue component syntax?

I think we already have a nice ES6 standard for classes so using these would be ideal because code would become less framework-dependent, more readable (esp. for people who never were using Vue), I believe that also less error-prone and more versalite.

It could look like this way:
http://pastebin.com/mqy2r2XW

This is how it worked in for example KnockoutJS. They werent making their own way of declaring component, properties, methods as JS nested objects, they've used standaard javascript class syntax instead.

I've managed to make it this way using some hacky module (that translates a class into structure readable by Vue) but it'd be great to have this as build-in functionality.

My proposal is to tune up component builder in Vue - for now it only accepts JS objects with Vue declarations like props, methods etc. For backwards compatibility it could work this way:

a) if object is passed to Vue.component then it works using original behaviour

b) if function is passed, Vue.component treats it as class constructor and uses new syntax.

It could be nice, modular and simplier, I'd love to use:

import SomeComponentClass from 'components/some-component.js';
Vue.component( 'some-component' , SomeComponentClass );

Or just return it from .vue file via vue-lodaer/vueify.

[posva]

Object literals are easier and more clear than classes that are applying some black magic.
However a webpack transform could be a great way to handle this

[smolinari]

I know for a fact, if Vue would be programmed as @nullptr128 suggests, it would win a lot more backend developer hearts, including mine. Though, I love Vue anyway. LOL!

Scott

[yyx990803]

My opinion is that ES6 classes offer no practical advantages over plain object definitions except for syntax preferences.

But if you really like classes, you can use https://github.com/vuejs/vue-class-component

[smolinari]

I will bet you a beer ES6 classes will become more the norm as time goes on. 😉

Scott

[yyx990803]

@smolinari that's why there are tools that allow you to write components as a class, but I don't think I'll ever change Vue's default API to use classes.

[phobos2077]

I agree that some kind of solution for ES6 should be added to the base (or at least as an official plugin). It is silly to say that the feature that is already in EcmaScript standard (ES6 class syntax) is "bad" and ignore it. I am a more of a backend developer but we have to use JS for our projects so I'm looking for a good MVVM library that will be easy to learn for any backend developer. OOP is much easier to understand for backend dev than more exotic (for us) functional/prototype patterns.
Previously I used KnockoutJS for a short time and stumbled upon VueJS recently. It seems almost perfect, but the way Vue objects are created bugs me. It's not a show stopper, but a disadvantage in my opinion (in Knockout you could create objects any way you want, successfully using ES6 classes as view models).

[znck]

Vue has official plugin for ES6 class components: https://github.com/vuejs/vue-class-component

[smolinari]

I've learned a bit more about JavaScript and I must say, concerning my comments above, I see now I was a bit mistaken. For those of you who don't know the power of JS's prototype based object model, you should really take the time to learn it. Trying to fit classical OOP over JS' prototype system is like putting a stocking over your head for a date thinking you might look better. Ok. That analogy might not be perfect, but hopefully you get the idea. Learn the true power of JS and you won't need the stocking. 😄

Scott

[nullptr128]

This however does not address original issue.

Having custom object literal syntax is less flexible than using inbuild class system. If Vue would take function parameter and treat it like class contructor, you could either use prototype based definitions or ES6 class syntax (which is more like syntatic sugar).

Class based definitions are easier to understand, easier to follow and you can even use modules that were originally designed to make another task, extend them and add UI features.

It also could be compataible with dependency injection libraries like Inversify.

Also it makes programming components with TypeScript easier because you can get autocomplete for fields, functions, checking parameters, return types etc.

And also my personal opinion is that class based design is more readable than defining data in literal structures... I just dont feel it is neccessary to recreate the same class structure that original JS has using literals... We have "data" which are instance fields, "computed" which are in reality getters, "methods" which are methods. I feel it is unnecessary to recreate ES6 and OOP basics that everyone understands in form of literals dedicated only to one library.

I am considering moving to Angular just because Vue does not have good TypeScript support, and class based components would help it a lot.

[Akryum]

Computed properties are not just getters, they are cached and smartly updated if a data dependency change.

[LinusBorg]

We have "data" which are instance fields, "computed" which are in reality getters, "methods" which are methods.

• We also have watch:, which has no equivalent in ES6 classes
• We also have props:, which has no equivalent in ES6 classes
• we have provide:/inject:, which have no equivalent in ES6 classes
• we have model: , which has no equivalent in ES6 classes
• And with object literals, we have an easy and readable way to add options for 3rd party extensions to a component, like firebase of the vuefire extension.

All of those features are not easy to integrate into an ES6 class - hence the use of @decorators in vue-class-component to provide the stuff that is missing - which makes it less readable to me, personally, and also is not supported in browsers (it's not even standard yet).

I fail to see how ES6 classes are "more flexible" in any way.

The only point I can concede is that the objet literal approach makes support of type systems like typescript and flow harder (but I'm sure that will change) - personally, I don't see the use of those in components specifically - complicated business logic worth typing resides in other modules for the store, api etc.

[yyx990803]

Basically what @LinusBorg said. I know people coming from a class-heavy language will want to use classes, but JavaScript is not Java or C# or whatever backend language you happen to be used to, and ES2015 class as it is right now is simply not expressive enough unless you resort to not-even-standard features like decorators and class property initializers.

You may want to say it's ok, everyone is using build tools now, stage-2 is fine too... well no it's not. While using a class-based API by default may make it more "friendly" to devs used to classes, it also makes it more hostile to a large group of users who use Vue without build tools or transpilers. When you are advocating your preference, you might be missing some nuance we have to take into account as a framework.

This is why we offer the object-based API as the baseline and the class-based API as an opt-in. This allows us to cater to both groups of users.

[Schenn]

We also have watch:, which has no equivalent in ES6 classes

Watch is a setter.

props: is a getter.

Inject / Provide is Object.assign

Model is a selector to a node which is changed on Set / Get + event listeners

ES6 - Object.defineProperties solves all of these and can be used in the constructor of a class, not to mention other means, to provide this identical functionality to any class....