-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: vapor component base #5
Conversation
The design of the components has not yet been discussed. We have to put this PR on hold. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution. However, we have to wait until the team discusses component design.
One of the goals is to simplify the current complexity. Maybe we have to explore it in mainline (Vue Core) first...
Ok, that’s fine. I’ll wait for further updates! (I can't get to sleep because of…) |
316a903
to
990eb68
Compare
990eb68
to
e4f87ae
Compare
69ca76e
to
ffd91d9
Compare
Size ReportBundles
Usages
|
ffd91d9
to
895f91d
Compare
I get an error |
related: #4
I have implemented some foundational aspects of components.
I've made changes to manage
setup~render execution, which was on the playground side in the existing implementation, and effectScope, which was a local variable in the render function, as component instances.These instances are planned to be implemented in the future to register lifecycle hooks and manage provides, similar to traditional components.
Also, regarding the setup and render options, they are treated only as compile outputs this time and were not intended to be public for users, so I have named them InternalOption.
Please let me know if these APIs (Options) were supposed to be treated as public, and I will make the necessary adjustments.
@vue/*
orvue
?