Closed adityapurwa closed 10 months ago
Hi, thanks for wanting to contribute with an RFC.
However, you posted this as an issue whereas RFC are done as Pull requests.
So please follow these steps:
/active-rfcs
directory, preferably in its own branchPlease see existing RFCs for examples. If you have any more questions, feel free to ask here.
Also, your RFC should address points from the abandoned class API RFC that we already had, and how your approach intends to solve them or why they don't apply etc.
Hi @LinusBorg and thank you for responding!
I am creating this as an issue because I wanted to have a discussion first about this with others, following:
Gathering feedback before submitting It's often helpful to get feedback on your concept before diving into the level of API design detail required for an RFC. You may open an issue on this repo to start a high-level discussion, with the goal of eventually formulating an RFC pull request with the specific implementation design.
At the meantime, while gathering more feedback - I am currently trying to implement a PoC for this API.
If a discussion in a PR is preferred, I would close this issue and starts working on the PR.
Thank You!
Ah, I see. Well, that's totally fine. It's just that you already wrote the issue in the formulaic way of the actual RFC, so I thought you wanted to submit it as an RFC directly.
It's fine to discuss here, just make sure to give some context at the beginning of your post that this is not yet meant as an RFC. Otherwise people might be confused, as evidenced by me :-P
Oops, sorry for the confusion @LinusBorg - I edited the issue description, I hope it doesn't cause any more confusion. Sorry!
There are inherent issues with using Class based componets in general. It's the motivation for why React came up with hooks.
Please read....https://reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines
However, we found that class components can encourage unintentional patterns that make these optimizations fall back to a slower path. Classes present issues for today’s tools, too. For example, classes don’t minify very well, and they make hot reloading flaky and unreliable. We want to present an API that makes it more likely for code to stay on the optimizable path.
I'm sure this is also what Evan knows and understands and is trying to avoid. 😃
Scott
Maybe TypeScript Transformer Plugin(typescript.CustomTransformers
) is a possible way?
Hi @lovetingyuan, what would be the use case for the transformer plugin as I never used it?
I tried to create a sketch of the API design,
Demo available https://stackblitz.com/edit/vue-ts-class-api-0001
// A quick sketch of the API Design
// Not an actual Vue app
abstract class Component<TProps, TState>{
protected abstract data(): TState;
protected state: TState;
abstract render();
constructor(protected props: TProps, protected onRefresh: (c: Component<TProps, TState>) => void) {
this.constructProxyFromData();
// This is to simulate Vue rendering logic
this.onRefresh(this);
}
private constructProxyFromData(){
const obj = this.data();
this.state = new Proxy(obj as any, {
set: (obj, prop, val) =>{
obj[prop] = val;
this.onRefresh(this);
return true;
}
}) as any;
}
}
class Counter extends Component<{
counter: number
}, {
counter: number
}>{
data(){
return {
counter: this.props.counter
}
}
render(){
// This would be the template in real Vue app
return `<h1>Counter ${this.state.counter}</h1>`;
}
click(){
// Simulates a button click
this.state.counter++;
}
}
const appDiv = document.getElementById("app");
// This would be written as <Counter counter="1" /> in template
const counter = new Counter({
counter: 1
}, (c)=> { // simulates Vue rendering logic
appDiv.innerHTML = c.render();
});
// Simulates click
setInterval(()=>counter.click(), 1000);
Using mobx we can build a ui framework-independent data layer. You are free to choose to use vue or react. And It has TypeScript Friendly Class API.
Also, your RFC should address points from the abandoned class API RFC that we already had, and how your approach intends to solve them or why they don't apply etc.
17
Now that class
component is not support in Vue3, is there anyway to migrate vue2 class component to vue3 component? @LinusBorg
The vue-class-component is still being supported and has seen a release that's compatible with Vue 3.
so just continue using this.
the class API just won't be integrated into Vue core, which the dropped RFC was about.
I believe this is no longer relevant as we have better TypeScript support now. As the issue poster, I won't mind if this issue is closed. Thank you to everyone involved on this discussion.
cc @LinusBorg Please feel free to either close or keep this issue opens depending on your insight. Thank you!
This is not an RFC - this issue is written so we can discuss more on how to make Class API works perfectly with TypeScript. Discussion is welcome and highly appreciated!
Summary
This RFC tries to make Vue Class API TypeScript friendly by breaking some of the things that now exist in Vue but not really practical to use with TypeScript. This is TypeScript oriented, so expect a lot of things that are already in Vue to be broken so it could fit TypeScript designs.
Inspired by React TypeScript supports.
Basic example
The new Class API would be able to be used like:
Motivation
The motivation behind this that we hope Vue will have first class TypeScript supports like React. It's been a breeze to use React with TypeScript, but couldn't say the same with Vue. Having first-class TypeScript support means we can reduce the number of bugs related to inconsistent typings and better coding assistance in IDE.
The Class API is well structured, so it is easier to read and explore, that is why we hoped that we can continue to improve the Class API.
Detailed design
The goal is to separate the main instance with user-land and type-land properties. We then won't have to worry about merging the user-land code and type-land code, we can safely annotate each part that we wanted to annotate.
So we might end breaking a lot of existing Vue code because everything would be removed from the main instance.
It might look like this:
TApi
might be used to expose the API that the component exposes, such as its methods. AndTEvents
is used to expose events that can be fired or listened to by other components.Drawbacks
Alternatives
The Function API is a good way of supporting TypeScript.
Adoption strategy
We can write tools that detect the user state and props, and then modify the code that accesses them so it got prefixed by
this.state
orthis.props
.We can also make the
state
andprops
property live side by side with the user existing state and props that lives on the instance directly. But it might mean we have to support both designs on the run.Unresolved questions
We still don't know how to utilize TypeScript and make these things better: