[Abandoned] Class API proposal #17
Conversation
|
What about local component registration? Also, I might start using TypeScript after this :) |
|
@ashokgelal any existing option can be mapped to a static property: class Foo extends Vue {
static components = {
Bar,
Baz
}
} |
|
@yyx990803 That's what I thought. And does that mean with Typescript it would be something like It'd be nice to mention local component registration in the RFC as well. |
|
In regards to using |
|
@ashokgelal no, you do that the same way in TypeScript. @crutchcorn the note on |
|
How would inject/provide look like? |
|
Would we need to us TS if we wanted prop validation? Edit: Nevermind, dumb question. |
|
Would this work in the script section of an SFC? Don't especially want to give up all of the advantages of having a separate |
|
@aparajita of course! |
|
@yyx990803 Well, your first "basic usage" example uses a template string, and none of the examples show usage within an SFC, so I hope you can see why I was wondering. It's obvious to you, but not necessarily to everyone else. The more explicit you are in docs, the better. In any case, I would suggest that the overwhelming "basic usage" will be in an SFC, not using a template string, and perhaps the first example should be changed accordingly. |
|
So it sounds like based on the Alternatives section that you're going to be using decorators, is there any way we could something like this to make it simpler to keep our interfaces in one spot without generics? interface propType {
numeric: number,
text: string,
}
class MyComponent extends Vue {
@props()
props: propType = {
numeric: 0,
text: 'string',
}
created() {
this.msg
}
}I guess this doesn't solve the issue of validators. But I wish that I could create one interface for props and one for my data. that keeps the different concerns isolated. |
|
as long as the old object notation remains valid, this is perfect. |
|
I'm sold on it, given the last paragraph in the adoption strategy. As long as the |
|
Should component inheritance be covered in the RFC? Like how one component extends another one, possibly with mixins included at the same time. |
|
Hi, I have some questions:
For question 1, maybe vue can provide a decorator For question 2, maybe vue can provide some special constant key to declare a hook. For example: import Vue, { Options, Lifecycles } from 'vue'
class Component extends Vue {
[Options.provide] () {
return { bar: 'foo' }
}
[Options.data] () {
return { foo: 'bar' }
}
[Lifecycles.created] () {
// ...
}
} |
|
Note about mixins, we are trying to align multiple frameworks to provide sugar for the current stage 1 proposal for mixins, and so far, people seems to like it. Have you consider using: class Foo extends mix(Bar).with(X, Y) {
...
}The implementation of that utility is quite simple, and in maps exactly to the syntax that we are proposal for the language: class MixinBuilder {
constructor(superclass) {
this.superclass = superclass;
}
// This is a method of the class, not a "with" statement
with(...mixins) {
return mixins.reduce((c, mixin) => mixin(c), this.superclass);
}
}
export default superclass => new MixinBuilder(superclass); |
|
What distinguishes a method from a filter? |
|
What about checking prop type in template? |
|
Guessing watchers will also be defined via decorators. |
|
Which will be called first? constructor() or beforeCreate()? Currently beforeCreate will be called first. import Vue from 'vue';
import Component from 'vue-class-component';
@Component
class App extends Vue {
constructor() {
super();
console.log('constructor');
}
beforeCreate() {
console.log('beforeCreate');
}
created() {
console.log('created');
}
}
new App();
// beforeCreate
// constructor
// created
|
|
Could you remove the need the prop decorator if props were only available via Also, how do you go about defining what the types are for |
|
I also like the idea of only having or being accessed through There also is a need for non-reactive properties, like storing Popper instance, without having it trigger useless updates. |
|
The RFC does not mention anything about
|
|
@rickyruiz This is Class API proposal |
|
@kabaluyot - From what has been said in the past by the Vue team, yes. But, you'll hopefully learn at some point that it is the lesser pragmatic use of Vue. 😀 Scott |
|
Really sad about this, the class approach with decorator was so easy to read, no more weird "declare an object with a property named computed that contains a method to just have something that is implemented in base javascript with getters :(. I was really hyped by this until I found out it was going to be dropped. It would have been perfect for smaller projects than my angular ones. |
|
There will be support through vue-class-component |
Still mean that this will not be present in web courses, not in base documentation, less community :( Wish they kept that(and added service injections for stuff like ionic) |
|
Actually the main thing that im hoping tha the vue-class-component still be supported officially is the transition when the time comes when the composition API matures and had advantages in real application compared to class components. Also, the class component will have a bridge to composition APIs. We have assurance with the vue-class-component author: vuejs/vue-class-component#402 |
|
Sorry if my question duplicates others, but I really want to ask Evan. What was the main reason when he was preferring the Functional API over the Class API. Has the Functional API won because of current JS/TS limitations (lack of JS decorators, TS typing limitations, etc... ) or because of functional style is more awesome? BTW: could't open "read why" link on top |
|
@alexey2baranov - #17 (comment) Scott |
|
from what I understand, export default { // this is a object which mean this is an instance of class, only the class is Object
setup() {
const state = reactive({
count: 0,
double: computed(() => state.count * 2),
})
function increment() {
state.count++
}
return { // again this is another instance of Object,
state,
increment,
}
},
}let me transform you to typescript class word class MyConfigurate{
state : any = reactive({
count: 0,
double: computed(() => this.state.count * 2),
}) ;// sorry I do not know want type it is, so I'm using AnyScript 🤣
increment() : void {
this.state.count++
} // if this `this` is the problem, then use
increment2:()=>void = ()=>{
this.state.count++;
}
}
class MyComponent{
setup() {
return new MyConfigurate();
}
}
export default new MyComponent();so you can see, there are nothing wrong with and my prototype being abandoned previously because it can not find a proper time to attach the projected after use the @Component()
export default class Hellowork{
count = 0;
get double(){
return this.count * 2
}
increment() : void {
this.state.count++
}
// if use some reused function
position :{ x:number, y:number } = useMousePosition()
// or
constructor()
{
var { x, y } = useMousePosition();
this.x = x;
this.y = y;
}
x:number;
y:number;
//inject
@inject(()=>useStore())
store:any!;
}the
|
|
[composition class] Component setup using ES6 class works out of the box in Vue 3, why not officially support it! |
|
I implemented a simple scheme. |
|
我已收到你的邮件
|
|
I like class base syntax, may be https://github.com/facing-dev/vue-facing-decorator 's implementation could give us some inspirations. |
I don't see how this is, in any way, an improvement. Nor do I see any real world use cases for this. This doesn't seem relevant to the discussion, it comes across as pointless self-promotion. |
|
Hello everyone, I have created a vue3 framework with ioc container, named as You can find it here: https://github.com/cabloy/cabloy-front Do you agree with such a concept: Class should not be used in the Therefore, it is completely different from Cabloy-Front has a very important feature: With the support of ioc container, defining reactive states no longer needs Demonstration: no
|
|
Business layer is typically one layer below the backend API. I think you should use some other term for whatever you are proposing (maybe presenter from MVP? or VM from MVVM?) |
This is not related to this now LONG CLOSED issue. This is spam. This is not the place to post advertisements for your repos. |
The business layer can be understood as various types of resources related to business, including models, presenter, style, and so on. These can be encapsulated as class beans to hosted in the ioc container, so that it is easier to share the business -related data and logic. |
|
@hybridwebdev Cabloy-Front is a new idea for vue3+tsx+ioc, and introduces a different new dx. So maybe no problem taking it out to share with community. |
My point was that some people might be puzzled about what you mean (I certainly was). Just because you use DI does not mean that you also need to adopt all the naming conventions. Because SPA is presentational layer, and if you zoom out, then you will have 2 business layers (SPA + backend) in the whole picture, and it's weird. Just my 2 cents. |
|
From a full-stack perspective, I agree with you that the business layer refers to the backend API. But if you just look at it from a f 1088E ront-end perspective, in a large project, there is a concept of business layer. |
You don't seem to be grasping what I am saying. You are spamming. This is not the place to advertise your product. Stop. |
Rendered
Update: this proposal has been dropped. Read why here.