[Runtime] Component Props

[ubugeeei]

related: #4

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.

---

Drafts

• define internal

  https://github.com/sxzz/vue-simple-props

  // how provide propsOptions? (e.g. default value) 
  export default ({ expose }) => {
    const props = useProps();
    // ...
    return t0;
  };

  export default ({ expose }) => {
    const props = useProps({ p1: { type: String, default: "v" } });
    // ...
    return t0;
  };

  ---

  const useProps = (options: PropsOptions) => {
    const i = getCurrentInstance()
    i.propsOptions = option
    // or no use options, and refer to attrs like https://github.com/sxzz/vue-simple-props
  }

• export internal options

  export default {
    props: { p1: { type: String, default: "v" } },
    blockFn: (props, { expose }) => {
      // ...
      return t0;
    },
  };

  export const props = { p1: { type: String, default: "v" } };
  
  export default (props, { expose }) => {
    // ...
  
    return t0;
  };

[ubugeeei]

@sxzz
I've written a few drafts, but regarding the design of Props, has there been any discussion within the team, or is there a planned time to discuss this?

[sxzz]

It's too long, and I haven't had enough time and read it yet...

[ubugeeei]

Oh, I'm sorry for rushing you, I understand.
I'll wait until there's some progress! 💪🏻

[sxzz]

The essence of designing Vapor is: that we need to maximize compatibility with the existing behavior of Vue core.

• Currently, we don't need to consider macros like defineProps; they belong to the scope of SFC compiler and will ultimately be compiled into the props option.
• We need to support options like props, emits, and others, as well as the setup function. However, there's no need to implement the Options API such as data, created, computed, etc.
• Props should be stored in the ComponentInternalInstance for composable retrieval.
• As you mentioned the https://github.com/sxzz/vue-simple-props project. Currently, we might need a formal RFC or experiment first in Vue Macros before landing it in Vue Vapor.

[ubugeeei]

I'm trying..

https://github.com/Ubugeeei/vuejs-core/tree/feat/component-props

[ubugeeei]

I've probably implemented the basic functionality, so once I refine it a bit more, it seems like I'll be able to submit a PR.

Unlike the render function of traditional components, which generates new rawProps and patches them each time, we need to find a way to always get the latest values of the original props.
I tried implementing this by modifying the traditional initProps function and defining a getter using Object.defineProperty, but I wonder if there's a smarter way to do this. 😵‍💫

I'll raise a PR soon for a bit of discussion...