Component (base issue)

[ubugeeei]

Currently TODO

• Handle Failed to resolve component #196
• Component slots #154
• perf(compiler-vapor): template abbreviation of end tag #186
• ...

---

Component (Runtime)

• Base Implementation
  feat: vapor component base #5
• Basic APIs
  • props
    [Runtime] Component Props #25
    feat(runtime-vapor): component props #40
  • emits (PR)
    Component Emits #41
    feat(runtime-vapor): component emits #103
  • attrs
    feat(runtime-vapor): component attrs #124
    • inheritAttrs
      feat: implement inheritAttrs #153
  • slots
    Component Slots #53
    feat(runtime-vapor): component slot #143
    Component slots #154
  • slot outlet
    feat(runtime-vapor): createSlot #170
    Component slots #154
  • expose
    feat: Added expose to component instances #75
    feat(runtime-vapor): implement expose #181
  • provide/inject
    feat(runtime-vapor): provide and inject #158
  • SetupHelpers
    feat(runtime-vapor): setup helpers useAttrs & useSlots #172
  • setRef
    Component setRef #184
    feat(runtime-vapor): template ref on component #185
    setRef update #190
    feat: implement setRef update #191
  • ..
• LifeCycle Hooks
  Component LifeCycles #31
• Other APIs
  • Template Refs
  • currentInstance
    • getCurrentInstance
    • setCurrentInstance
  • AsyncComponent
  • ..
• What is the API that is the target for the drop?
  ref: https://x.com/sanxiaozhizi/status/1719734796832932062?s=20
• Integration of Vapor components and regular non-Vapor components
• ..

[ubugeeei]

NOTE：
It seems that we first need to proceed with a team discussion on the component design in vuejs/core.
Until then, it might be difficult to proceed with the work?
ref: #5 (review)

[sxzz]

After team discussion, we (with Evan) think that the basic feature of components should be implemented, including props/emits/slots... (Basic APIs part)

However, I guess maybe we can have another version of functional components that are lightweight and cheap cost (in the future).

---

So the to-do is: To implement Basic APIs and LifeCycles first and align the behavior with the core as much as possible.

[sxzz]

Well done! The basic implementation was merged. So the next step is about LifeCycles (Hooks API) and props/emits/attrs.

[ubugeeei]

archive

Props

I'm going to work on props/emit from now on (I plan to separate them into separate PRs).
Regarding the design, there are already some points that I'm concerned about.
First, let's consider the design of propsOptions.

Based on some comments in previous PRs, I feel that components should be expressed as functions that return Block.
Now, in order to implement props, we need to store the runtime types, default values, and user-defined props definitions somewhere.

Discussion 1

It is likely that the interface will be defined through defineProps for now, but I'm wondering if we are assuming that users will use Props Option in the Options API format.

Discussion 2

How should we store the options information of user-defined props in the component?
Since this is an internal matter, I think it will be stored in ComponentInternalInstance.
The problem is how to store it.
Currently, in the compiler,

export default (props, { expose }) => {
  // .
  // .
  return t0;
}; // satisfies BlockFn

code like this is planned to be outputted. (Currently, the output is represented as setup or render options, but referring to the interface Block in runtime-vapor/render, it seems to be temporary.)

And ComponentInternalInstance is generated in the form of receiving BlockFn as follows:

export function render(
  comp: BlockFn,
  container: string | ParentNode
): ComponentInternalInstance {
  const instance = createComponentInstance(comp);
  // .
  // .
}

So, we need to discuss how to store user-defined props options.

---

@sxzz
p.s. Should we change this discussion to a different issue? Or should we continue it here?

moved to #25

[ubugeeei]

The implementation of Props has been merged. I have already submitted a PR for Emit.
Now, I'm thinking of working on attrs next. 😄