3 ms·
Could you explain why you think the class-oriented interface is better than the data-oriented one? Personally, I don't see it. The class-oriented one is more o
by likeclockwork 8y ago
Could you explain why you think the class-oriented interface is better than the data-oriented one?
Personally, I don't see it. The class-oriented one is more official looking, but classes almost require instantiation and introspection to be understood at runtime.
Can JS classes even be generated at runtime? I'm sure they can, if you desugar them, but the class syntax isn't composable.
- IggleSniggle 8y agoCan you explain your comment? I don’t understand how the class syntax isn’t composeable? You instantiate a class the same way you instantiate an object, eg ‘new Date()’ or ‘new Set(array)’
- likeclockwork 8y agoGladly. With the data interface you can reuse or generate part or all of a component definition. A class declaration can only contain methods. The data object contains much more information. You could say both are descriptions that will be used to build an object, but the Vue API data object will be interpreted arbitrarily by Vue's runtime while the class declaration will be interpreted by the JS runtime and will only expose methods. You could use decorators or put properties on the class's constructor, but that has to happen outside of the scope of the class declaration and negates any cleanliness advantage. You can also put those properties in the constructor but then they are only available after instantiation. Here's a discussion on class syntax in Vue: https://github.com/vuejs/vue/issues/2371 https://github.com/vuejs/vue/issues/2371 I think that there's a temptation for class-oriented programmers to want to write everything as classes, but there's nothing inherently superior about using classes in your api and depending on the use case classes may actually be limiting.
- pier25 8y ago> Here's a discussion on class syntax in Vue: https://github.com/vuejs/vue/issues/2371 https://github.com/vuejs/vue/issues/2371 This is the typical answer from the Vue team. I've had a number of (civilized) discussions with them on other issues and it always ends up with "you are holding it wrong" or "this is not an issue". I won't argue classes vs objects, both have pros and cons, but locking the issue when there is clearly a boilerplate problem with Vue is bit ridiculous.
- likeclockwork 8y agoFrom your article: > My point here is not about using classes or not, but that Vue is using arbitrary object structures instead of language features. Which language features do you think they should be used that they aren't being used now? Your class example doesn't express the same things that Vue's object structure can. Object literals are an important, useful, and universal feature of JS. Class syntax doesn't really replace them. I'd really like to know what your alternative is.
- pier25 8y agoThere are some good proposals in the Github issue you linked but again, I'm not arguing in favor of classes vs objects. For example it would be possible to simply use an object with regular functions for methods, getters and setters for computed properties and watchers, and regular variables for data. That would solve 90% of Vue's boilerplate problem.
- pier25 8y agoLike I said in the article, my point is not about using classes or not, but about all the boilerplate that Vue introduces to the object notation.