Component slots

[Ubugeeei]

• <slot> in child component
  • feat(runtime-vapor): createSlot #170
  • feat(compiler-vapor): slot outlet #182
• pass slot from parent component
  • Demo
  • static slot / dynamic named slot
    • feat(compiler-vapor, runtime-vapor): impl comp slot content #202
    • feat(compiler-vapor): implement basic usage of v-slot #203
  • slot props
    • feat(compiler-vapor): v-slot props + v-slot on component #223
    • TODO runtime
  • slot + v-if / v-else / v-else-if
    • feat(compiler/runtime-vapor): implement v-slots + v-for / v-if #207
  • slot + v-for
    • feat(compiler/runtime-vapor): implement v-slots + v-for / v-if #207
  • perf dynamic slots, finer update granularity
    • perf(compiler-vapor): finer update granularity #222

[LittleSound]

I am trying to implement this issue, I noticed that currently slot outlets need to be obtained through the instance, do we need to create a createSlot function to handle this?

function render(_ctx) {
 // some codess

  const n3 = _createSlot('default', {
    foo: ()=> _ctx.bar
  }, () => {
    return _template('<div>fallback content</div>')
  })

 // some codes
}

[Ubugeeei]

I see. Is this similar to the discussion here?
#84
#74 (comment)

Is it not good to directly reference currentInstance or use getCurrentInstance?

[Ubugeeei]

Considering props and attrs as well, it might be better to have a function that directly references the instance or a function for accessing parts of it, rather than creating createSlot. 🤔
getCurrentInstance, or getSlots, getAttrs, getProps, .... 🤔 🤔

What do you think? cc @sxzz

[LittleSound]

I think it is necessary, because for complex requirements such as dynamic slot outlets (<slot :name="foo" />), encapsulating functions can reduce the complexity of generating code.

[Ubugeeei]

Indeed. That might be better.

[sxzz]

I think createSlots is a proper abstraction considering scope slot is a pretty complex feature.