Vue: [Abandoned] RFC: 범위 지정 슬롯 사용 간소화

좋아 보인다. 슬롯 이름을 제공하기 위해 인수를 사용하는 것에 대해 생각하고 있었지만 이렇게 하면 동일한 구성 요소에서 여러 지시문 v 범위를 사용할 수 있으므로 구성 요소에 제공된 콘텐츠를 재사용할 수 있습니다. 유용한지 또는 문제를 일으킬 수 있는지 확실하지 않습니다.

Overral, 이것은 시간이 지남에 따라 더 많이 사용되는 렌더리스 구성 요소의 API 사용을 향상시킬 것입니다 🙌

내가 올바르게 이해한다면 v-scope 는 하나의 사용 사례만 제공합니다. 쓰는 대신:

<foo>
  <template slot-scope="{ item }">{{ item.id }}</template>
</foo>

우리는 쓸 수있다:

<foo v-scope="{ item }">{{ item.id }}</foo>

이 경우 소음이 상당히 줄어들었지만 유일한 경우인 것 같습니다. 새 지시문을 도입하는 것은 일종의 과잉 처리처럼 느껴집니다(구성 요소에서만 작동하고 아래의 <slot> 논리에 의존하기 때문에 v-for 에서도 다른 지시문과 완전히 다르게 작동함). 또 다른 문제는 이 repo 에서 v-scope 를 검색 할 때 템플릿 하위 트리의 데이터 범위를 줄이는 것에 대해 논의하는 경우가 두 번뿐이라는 것입니다(https://github.com/vuejs/vue/issues/5269 #issuecomment-288912328, https://github.com/vuejs/vue/issues/6913), JavaScript에서 with 작동 방식과 같습니다.

좋아요. 나에게 남은 한 가지 질문은 명명된 슬롯을 처리하는 방법입니다. 명명된 슬롯이 동일한 지시문을 사용하도록 허용하려면 <template> 에서도 허용해야 합니다.

<comp v-scope="scope">
  {{ scope.msg }} <!-- default slot, inheriting from the scope from above -->
  <template slot="someName" v-scope="otherScope">
    <p>{{ otherScope }}</p>
    <div> whatever</div>
  </template>
</comp>

이 기회를 사용하여 sot-scope 를 더 이상 사용하지 않고 Vue 3에서 제거하여 v-scope 대체할 수 있습니다.

같은 것에 대해 두 가지 다른 개념( v-scope 지시문 및 slot-scope 속성)으로 끝나지 않아야 한다고 생각합니다.

Sidenote: 이제, 사람들은 요소의 계층 구조에서 인상을 얻을 수 있습니다.
명명된 슬롯에서 otherScope 및 scope 에 액세스할 수 있습니다. 단점이 될 수 있습니다.

이름에 대한 @LinusBorg 인수는 v-scope:slotName 수행할 수 있습니다. 구성 요소에서만 이것을 허용하는 요점은 @Justineo가 말한 것을 대체하는 것입니다(https://github.com/vuejs/vue/issues/9180#issuecomment-446168296).

Sidenote: 이제, 사람들은 요소의 계층 구조에서 인상을 얻을 수 있습니다.
명명된 슬롯의 otherScope 및 범위에 액세스할 수 있습니다. 단점이 될 수 있습니다.

그게 효과가 있어, 그렇지? 🤔 나는 중첩된 슬롯 범위를 가지고 있다고 확신합니다.

그게 효과가 있어, 그렇지? 🤔 나는 중첩된 슬롯 범위를 가지고 있다고 확신합니다.

나는 그것들을 중첩하지 않았지만 형제 슬롯입니다. 내가 함께 기본 슬롯의 범위를 정의 v-scope 구성 요소에, 그리고 (형제 슬롯입니다) 지정된 슬롯이있는 <template slot="someName">
보다? 혼란스럽네요^^

@LinusBorg 사용법이 혼란스러울 것 같습니다. 나는 개념적으로 다음과 같다고 생각한다.

• v-scope 가 구성 요소에 직접 사용되면 기본 슬롯만 사용하고 있음을 의미합니다.
• 명명된 슬롯을 사용하려면 slot + slot-scope 를 사용해야 합니다.

v-scope 와 slot-scope 를 모두 사용하는 것이 일관성이 없고 혼란스러울 수 있다는 점에 동의합니다. 특히 현재 디자인에 도달한 방법을 모르는 신규 사용자에게는 더욱 그렇습니다.

문제 분해

종합하려고 하면 다음과 같은 솔루션을 원하는 것처럼 들립니다.

• 범위가 지정된 슬롯의 데이터에 액세스하는 데 필요한 상용구 감소
• 기본 슬롯의 데이터를 명명된 슬롯에서 사용할 수 있다는 암시를 피하십시오.
• 도입해야 하는 새로운 API의 수 최소화
• 웹 구성 요소 사양에 이미 수용 가능한 솔루션이 있는 경우 API를 재발명하지 마십시오.
• 데이터의 출처에 대한 혼란을 피하기 위해 명시적으로 유지

이 모든 문제를 해결할 수 있는 솔루션이 있을 수 있습니다! 🤞 $event for v-on 사용하면 명명된 인수가 있는 암시적 함수 내에서 실행되는 표현식을 제공하는 선례가 있습니다. 사람들은 그 편리함을 즐기는 것 같으며 그로 인한 혼란은 그리 크지 않으므로 범위가 지정된 슬롯의 경우 해당 예를 따라야 합니다.

제안 된 해법

v-scope 를 사용하는 대신 슬롯 범위를 $slot 로 사용할 수 있습니다. 예를 들어:

<TodoList :todos="todos">
  {{ $slot.todo.text }}

  <template slot="metaBar">
    You have {{ $slot.totals.incomplete }} todos left.
  </template>
</TodoList>

컨텍스트의 경우 하위 템플릿은 다음과 같을 수 있습니다.

<ul>
  <li v-for="todo in todos">
    <slot :todo="todo" />
  </li>
</ul>

<div>
  <slot name="metaBar" v-bind="itemsStats" />
</div>

슬롯이 중첩되면 $slot 개체는 슬롯 데이터를 병합하고 가장 안쪽에 있는 슬롯이 우선순위를 무시합니다. 예를 들어:

<Outer>
  <Middle>
    <Inner>
      {{ $slot }}
    </Inner>
  </Middle>
</Outer>

병합은 다음과 같이 보일 수 있습니다.

$slot = {
  ...outerSlotData,
  ...middleSlotData,
  ...innerSlotData
}

네임스페이스 겹침을 처리하는 방법에 대해 걱정/궁금할 수 있으며 99.9%의 경우에는 실제로 문제가 되지 않을 것이라고 생각합니다. 예를 들어:

<UserData id="chrisvfritz">
  My email is {{ $slot.user.email }}, but you can reach Sarah at
  <UserData id="sdras">
    {{ $slot.user.email }}
  </UserData>.
</UserData>

위의 예에서 $slot.user 는 중첩 범위에도 불구하고 항상 올바른 값을 갖습니다. 그러나 다음과 같이 두 속성에 동시에 액세스해야 하는 경우가 있습니다.

<UserData id="chrisvfritz">
  <template slot-scope="me">
    <UserData id="sdras">
      <template slot-scope="sarah">
        <CollaborationPageLink :user-ids="[me.user.id, sarah.user.id]">
          View your collaboration history
        </CollaborationPageLink>
      </template>
    </UserData>
  </template>
</UserData>

이러한 드문 경우의 경우 사용자는 현재 동작과 함께 slot-scope 를 탈출용 해치로 사용할 수 있습니다. 하지만 v-scope 는 여전히 필요하지 않습니다. 내가 올바르게 이해한다면 $slot 개체가 동일한 문제를 일으키지 않고 이미 달성했을 가장 일반적인 사용 사례를 단순화하는 것이 목적이기 때문입니다.

장점

• 사용자가 슬롯에서 제공하는 데이터에 액세스하려고 할 때 유일한 상용구는 $slot 입니다. 속성이 정의된 위치를 확인하기 위해 구성 요소를 검색할 필요 없이 데이터가 슬롯에서 왔다는 것이 즉시 명백합니다.

• 어떤 데이터에 액세스할 수 있는지 알기 위해 사용자는 콘텐츠가 렌더링될 슬롯만 생각하면 됩니다 . v-scope 하면 v-for 처럼 작동한다고 가정하는 사람들에게 많은 혼란이 있을 것이라고 생각합니다. 왜냐하면 이것이 범위가 지정된 컨텍스트 속성을 정의하는 유일한 다른 지시문이기 때문입니다.

• 사용자는 범위가 지정된 슬롯을 사용하기 위해 구조화에 익숙하고 편안할 필요가 없으므로 학습 곡선이 줄어듭니다.

• 어떤 경우에는 특히 모두 상태를 제공하는 많은 중첩된 슬롯이 있는 경우 일부 상태가 _어느 구성 요소에서 왔는지 명확하지 않으며 사용자는 slot-scope 다시 도달해야 합니다. 이것은 단점처럼 들릴 수 있지만 중첩 범위 슬롯을 볼 때 거의 항상 상태 제공자 패턴에 대한 것입니다. 이는 반패턴이라고 강하게 느낍니다. 여기 내 추론이 있습니다. 따라서 많은 중첩 범위 슬롯이 더 많은 상용구를 필요로 한다는 사실은 실제로 안티 패턴의 사용을 줄일 수 있습니다 .

• 대부분의 Vue 개발자는 객체일 뿐인 $slot 만 기억하면 되므로 API 노출 영역이 크게 줄어듭니다 .

• $ -prefixed 속성을 사용하여 $slot 가 Vue임을 명확히 하는 방식으로 웹 구성 요소 슬롯 API를 구축하고 있습니다.

• 현재 라이브러리는 종종 같은 것을 할 <slot v-bind="user" /> 그래서 자신의 사용자가있는 몇 글자 저장할 수 slot-scope="user" 대신 slot-scope="{ user } . 언뜻 보기엔 고급스러워 보이지만, 안티패턴으로 경험하게 되었습니다. 구성 요소가 사용자 이외의 데이터를 노출하려고 할 때 문제가 발생합니다. 그런 다음 두 가지 선택이 있습니다. API를 크게 변경하거나 이 새 속성을 user 개체에 강제 적용하는 것입니다. 사용자와 관련이 거의 없을지라도 말입니다. 어느 쪽도 훌륭한 옵션이 아닙니다. 다행히 $slot 는 구성 요소를 덜 미래 지향적으로 만들려는 유혹을 제거합니다. $slot 가 $slot.user 보다 여전히 짧지만 사용자를 $slot 으로 별칭을 지정하여 중요한 컨텍스트를 잃기 때문입니다

단점

• 일부 중첩 범위 슬롯에는 일부 데이터가 _어느 구성요소에서 왔는지 명확하지 않은 일부 경우가 있습니다. 그러나 이러한 경우 사용자는 최대 명시성이 필요할 때 slot-scope 도달할 수 있으므로 큰 문제는 아니라고 생각합니다. 또한, 앞서 언급했듯이 사용자가 처음에 이 문제가 있는 경우 상태 공급자 구성 요소로 자신을 쏘고 있을 가능성이 매우 높다고 생각합니다.

$ -prefixed 속성은 전체 Vue 인스턴스 내에서 일관되어야 한다고 생각합니다. 암묵적으로 각 슬롯에 $slot 를 삽입하여 혼동을 일으킬지 확신할 수 없으며 실제로 이러한 슬롯 범위 내의 로컬 인수를 나타냅니다. 내 관찰에 따르면 $ -prefixed 속성은 모든 Vue 인스턴스에서 사용할 수 있는 것을 의미하므로 수명 주기 후크, 메서드 및 렌더링 기능을 포함하여 모든 내부에서 사용할 수 있습니다. 이 특별한 $slot 를 추가하면 이 규칙이 깨집니다.

@chrisvfritz 이것은 흥미로운 제안이지만 일반 슬롯과 ​​범위가 지정된 슬롯이 통합되는 방식에 의존합니다(따라서 v3에서 고려할 수 있는 것). 이것의 가장 큰 문제는 슬롯 콘텐츠가 자식 구성 요소의 $slots 또는 $scopedSlots 에서 사용할 수 있어야 한다는 것입니다. 유일한 힌트는 slot-scope (슬롯 루트에만 있을 수 있음)만큼 명시적이지 않은 표현식(트리 아래의 아무 곳에나 있을 수 있음)의 어딘가에 $slot 있다는 것입니다. 기술적으로 컴파일러에서 이를 감지할 수 있지만 사용자가 템플릿에서 $slot 를 사용하기 시작할 때마다 사용자 슬롯이 $slots 에서 $scopedSlots $slot 로 이동합니다...

이것이 JSX 사용자에게 큰 영향을 미칩니까?

@donnysim 아니요, 이것은 어떤 식으로든 JSX에 영향을 미치지 않습니다.

$ -prefixed 속성은 전체 Vue 인스턴스 내에서 일관되어야 한다고 생각합니다. 암묵적으로 각 슬롯에 $slot 를 삽입하여 혼동을 일으킬지 확신할 수 없으며 실제로 이러한 슬롯 범위 내의 로컬 인수를 나타냅니다.

@Justineo 저도 처음에는 같은 생각을 했지만 $event 대해 이 작업을 수행하고 아무도 불평하지 않는 것 같으므로 이미 전례가 있으며 사용자가 일반적으로 혼동하지 않고 실제로 편리함을 즐기고 있다는 증거가 있습니다.

이것의 가장 큰 문제는 슬롯 콘텐츠를 자식 구성 요소의 $slots 또는 $scopedSlots 에서 사용할 수 있어야 한다는 것입니다.

@yyx990803 좋은 질문입니다! 효과가 있을 수 있다는 생각이 있습니다. 모호한 경우( $slot 사용하는 중첩된 슬롯) 모든 슬롯을 범위가 지정된 슬롯으로 컴파일하고 $slots 아래에서 모든 $scopedSlots $slots 를 getter로 사용할 수 있도록 하면 어떻게 될까요? 예를 들면 다음과 같습니다.

for (const slotName in vm.$scopedSlots) {
  // Don't override existing slots of the same name,
  // since that's _technically_ possible right now.
  if (vm.$slots[slotName]) continue

  Object.defineProperty(vm.$slots, slotName, {
    get: vm.$scopedSlots[slotName],
    enumerable: true,
    configurable: true,
    writable: true
  })
}

그런 식으로 다음과 같은 경우:

<A>
  <B>
    {{ $slot.foo }}
  </B>
</A>

다음과 같이 컴파일할 수 있습니다.

// Assume new render helper:
// _r = mergeSlotData

_c('A', {
  scopedSlots: _u([
    {
      key: 'default',
      fn: function(_sd) {
        var $slot = _r($slot, _sd)
        return [
          _c('B', {
            scopedSlots: _u([
              {
                key: 'default',
                fn: function(_sd) {
                  var $slot = _r($slot, _sd)
                  return [_v(_s($slot.foo))]
                },
              },
            ]),
          }),
        ]
      },
    },
  ]),
}) 

foo 가 <A> 또는 <B> 에서 왔는지 여부는 중요하지 않습니다. 왜냐하면 해당 구성 요소 내부에서 this.$slots.default 및 this.$scopedSlots.default(someData) 모두 작동하기 때문입니다.

몇 가지 주의사항:

• 중첩된 슬롯이 있고 그 중 일부만 실제로 범위가 지정된 경우 $slot 사용하는 템플릿의 컴파일된 렌더링 함수는 slot-scope 사용하는 경우보다 약간 더 큽니다. 그래도 크게 눈에 띄는 정도는 아니라서 괜찮은 것 같아요.

• 실제 예는 생각할 수 없지만 사용자가 $slots / $scopedSlots 이상을 반복하고 새 속성이나 중복 속성이 있으면 예기치 않은 동작이 발생할 수 있는 극단적인 경우가 있을 수 있습니다. 몇 가지 흥미로운 패턴을 활성화하기 위해 이전에 동적으로 명명된 $slots 및 $scopedSlots 를 반복했지만 이 변경 사항은 내가 실행한 사용 사례에 영향을 미치지 않습니다.

생각?

우리는 $event 위해 이것을 하고 아무도 불평하지 않는 것 같습니다

@chrisvfritz 오, $event 놓쳤습니다. 분명히 규칙에 대한 예외이지만(나는 그것이 😅라고 생각합니다), $event 는 매우 제한된 범위에서만 사용할 수 있습니다(v-bind 속성 리터럴 내에서만 & 중첩 없음).

그리고 프록시에 대한 $scopedSlots 에 $slots :

나는 슬롯과 범위가 지정된 슬롯이 서로 다른 개념이라고 믿었고 Vue는 이를 별도로 사용합니다. 즉, 슬롯과 범위가 지정된 슬롯이 같은 이름을 공유하지만 다른 용도로 사용할 수 있음을 의미합니다. 그러나 나중에 Vue는 지정된 범위 슬롯을 사용할 수 없을 때 동일한 이름을 가진 슬롯으로 실제로 폴백한다는 것을 발견했습니다. 나에게 이것은 우리가 그것들을 같은 것으로 간주해야 한다는 것을 의미하지만 각 인스턴스에서 $slots 와 $scopedSlots 사용할 수 있기 때문에 더 유연하고 예상치 못한 방식으로 렌더링 함수에서 항상 사용할 수 있습니다. , 기본 슬롯을 사용하여 모든 목록 항목을 재정의하고 기본 범위 슬롯을 사용하여 단일 항목을 재정의하는 것과 같습니다. 이것은 3.0에서 슬롯의 단일 개념으로 병합할 가능성이 높으므로 실제로 권장되지 않습니다(문서 및 스타일 가이드 AFAIK에서 이에 대한 권장 사용법을 제안하지 않았습니다). 그러나 2.x에서 그렇게 하면 중단됩니다. 꽤 오래전부터 일부 사용이 허용되었습니다.

우리는 그것들을 3.0에서 단일 슬롯 개념으로 병합할 가능성이 있지만 2.x에서 그렇게 하면 꽤 오래전부터 허용된 일부 사용이 중단될 것입니다.

@Justineo 내가 오해하고 있을지도 모르지만 이미 2.x에서 병합하는 것을 제안하지 않습니다. 단지 현재의 대체 동작을 확장하는 것뿐입니다. $slots 및 $scopedSlots 모두 동일한 네임스페이스를 사용하는 설명된 사용 사례는 slot-scope 의 동작이 변경되지 않은 상태로 유지되기 때문에 여전히 가능합니다. 예를 들어:

<div>
  Default slot
  <template slot-scope="foo">
    Default scoped slot {{ foo }}
  </template>
</div>

여전히 정확히 동일하게 작동합니다. 말이 돼?

@chrisvfritz

2.x에서 병합하는 것에 대해 이야기한 것이 아닙니다. 나는 당신이 이것을 하는 경우에 말하고 있었다:

모든 $scopedSlots 를 $slots 에서 getter로 사용할 수 있도록 합니다.

$slots.foo 와 $scopedSlots.foo 구별할 수 없으며 더 이상 렌더링 기능에서 별도로 사용할 수 없습니다.

$slots.foo와 $scopedSlots.foo를 구별할 수 없으며 더 이상 렌더링 기능에서 별도로 사용할 수 없습니다.

솔직히, 나는 모든 것(슬롯 및 scopedSlots)이 scopedSlots에서 기능으로 액세스할 수 있다면 기쁠 것입니다. 그것은 더 이상 어떤 슬롯을 렌더링할지 확인하는 쓸모없는 일을 의미합니다. 개발자가 어떤 유형의 슬롯을 사용하는지 구성 요소 관점에서 실제로 차이가 없습니다. 혼합 JSX 및 템플릿 구문 사용자가 제공합니다.

@donnysim 예, 병합되어야 한다는 데 동의합니다. 나는 https://github.com/vuejs/vue/issues/9180#issuecomment -447185512에서 왜 그런 우려가 있는지 설명했습니다. 그것은 하위 호환성에 관한 것입니다.

$slots.foo 와 $scopedSlots.foo 구별할 수 없으며 더 이상 렌더링 기능에서 별도로 사용할 수 없습니다.

@Justineo 실제로 $slots 먼저 처리하고 이미 정의된 슬롯을 교체하지 않는 한 실제로 _할 수 있습니다. 위에 게시한 예제 구현을 참조하세요.

for (const slotName in vm.$scopedSlots) {
  // Don't override existing slots of the same name,
  // since that's _technically_ possible right now.
  if (vm.$slots[slotName]) continue

  Object.defineProperty(vm.$slots, slotName, {
    get: vm.$scopedSlots[slotName],
    enumerable: true,
    configurable: true,
    writable: true
  })
}

@chrisvfritz

다음 예를 고려하십시오.

render (h) {
  if (!this.$slots.default) {
    return h(
      'div',
      this.items.map(item => this.$scopedSlots.default(item))
    )
  }
  return h('div', this.$slots.default)
}

구성 요소 사용자가 vm.$scopedSlots.default 만 전달한 경우 this.items 반복하고 item 를 범위 지정 슬롯에 렌더링해야 합니다. 그러나 이제 vm.$scopedSlot.default 가 범위 지정 슬롯이고 존재하므로 범위 지정 슬롯이 슬롯 대신 호출됩니다.

@Justineo 이 사용 사례는 매우 드물다고 생각하지만 다음을 변경하면 패턴이 여전히 가능합니다.

if (!this.$slots.default) {

에게:

if (this.$scopedSlots.default) {

또는 사용자가 때때로 어떤 이유로 무시되어야 하는 범위 지정 슬롯을 제공하는 경우:

if (!Object.getOwnPropertyDescriptor(this.$slots, 'default').value) {

그래도 나는 그것을 획기적인 변화로 생각하지 않을 것입니다. 첫째, 동일한 이름의 슬롯 및 범위 지정 슬롯 사용을 문서화/권고한 적이 없으므로 공개 계약의 일부가 아닙니다. 둘째, 언급했듯이 템플릿의 범위가 지정된 슬롯은 이미 같은 이름의 범위가 지정되지 않은 슬롯으로 대체됩니다. 이는 범위가 지정된/범위가 지정되지 않은 경계가 이와 같이 사용되도록 의도한 적이 없다는 좋은 역사적 증거 역할을 합니다.

말이 돼? 또한 슬롯 이름을 재사용하는 실제 사용 사례를 본 적이 있습니까? 아니면 생각나는 것이 있습니까? 나는 할 수 없지만 그것이 가능하게 하는 유용하고 독특한 패턴이 _are_ 있다면, Vue 3에서 그것들을 병합하기로 한 우리의 결정에도 영향을 미칠 것이기 때문에 지금 그것들에 대해 배우는 것이 좋을 것입니다.

나는 범위가 지정된 슬롯과 다른 목적을 위해 같은 이름을 가진 슬롯이라고 생각합니다.
나쁜 생각. Vue의 이전 버전에서 이것을 약속하고 제거했습니다.
혼란스러웠기 때문이다. 이제 기본 슬롯을 모두 확인해야 합니다.
개발자가 데이터를 소비하지 않고 슬롯을 제공할 수 있도록 범위가 지정된 슬롯.
그리고 제 기억이 맞다면, 당신은 사용할 때 같은 이름을 가질 수 없습니다
템플릿.

@chrisvfritz

패턴이 도움이 되며 지원되어야 한다고 말한 것이 아닙니다. 실제로 혼란을 일으킬 수 있습니다. 나는 단지 기존 코드를 깨는 것이 가능 하다고 말한 것입니다. 우리는 슬롯과 범위가 지정된 슬롯 간에 동일한 이름을 공유하는 것을 문서화한 적이 없지만 사용자에게 공유하지 말라고 제안한 적도 없습니다. 그리고 템플릿의 폴백 로직은 문서화되어 있지 않습니다. 의도적이지는 않을 수도 있지만 적어도 템플릿에서 폴백 로직을 배울 때까지는 합법적인 사용법이라고 믿었습니다...

@posva 경험을 공유해 주셔서 감사합니다!

@Justineo 이 엣지 케이스가 사용자에게 너무 많은 고통을 줄 것이라고 생각합니까, 아니면 Vue 2.x에서 범위가 지정된 슬롯 API를 개선하는 편의를 위해 허용됩니까?

이것은 "Todo"로 옮겨졌습니다. - 우리는 무엇을 구현할지에 대한 합의가 있습니까?

나는 지난 주에 이것에 대해 생각해 왔습니다. @chrisvfritz 의 $slot 변수 제안이 마음에 들고 구현 방해 요소를 해결하려고 했습니다. 실현 가능하다고 생각하는 것은 다음과 같습니다.

• 모든 슬롯은 3.0에서와 같이 함수로 컴파일되므로 더 이상 정적 슬롯이 없습니다(이는 더 정확한 구성 요소 업데이트 추적으로 이어짐).
• $scopedSlots 는 모든 슬롯을 함수로 노출합니다.
• $slots 는 빈 객체로 해당 함수를 호출한 결과로 모든 슬롯을 노출합니다.

따라서 다음은 동일합니다.

this.$slots.default
// would be the same as
this.$scopedSlots.default({} /* $slot */)

위의 내부 변경으로 $slots 및 $scopedSlots 는 본질적으로 통합되지만 이전 버전과 호환되어야 합니다! 또한 3.0으로 쉽게 마이그레이션할 수 있습니다.

제안된 $slot 변수를 사용하는 일부 사용 샘플:

<!-- list and item composition -->
<fancy-list>
  <fancy-item :item="$slot.item"/>
</fancy-list>

<!-- hypothetical data fetching component -->
<fetch :url="`/api/posts/${id}`">
  <div slot="success">{{ $slot.data }}</div>
  <div slot="error">{{ $slot.error }}</div>
  <div slot="pending">pending...</div>
</fetch>

중첩 범위를 병합하는 것은 좋은 생각이 아니라고 생각합니다. 중첩이 관련될 때 명시적인 것이 더 낫다고 생각합니다(즉, 중첩 범위 슬롯이 있는 경우 항상 slot-scope 사용).

<!-- nested usage -->
<foo>
  <bar slot-scope="foo">
    <baz slot-scope="bar">
      {{ foo }} {{ bar }} {{ $slot }}
    </baz>
  </bar>
</foo>

마지막 예에서 $slot 참조하는 슬롯은 무엇입니까?

@Akryum { ...foo, ...bar } 입니다.

@Akryum @Justineo 흠 혼란스러울 수 있습니다... 우리는 slot-scope 슬롯 의 습니다 . 즉, 여기서 foo 는 <foo/> 제공하는 슬롯 범위입니다. bar 는 <bar/> 하고 $slot 는 <baz/> ... 지금은 이러한 사용을 허용 한 것이 실수라고 생각합니다. 왜냐하면 이 경우 보다 직관적인 사용법은 다음과 같습니다.

<!-- nested usage -->
<foo slot-scope="foo">
  <bar slot-scope="bar">
    <baz slot-scope="baz">
      {{ foo }} {{ bar }} {{ baz }}
    </baz>
  </bar>
</foo>

이것은 혼란 스러울 수 있습니다

이 경우 더 직관적인 사용법은 다음과 같습니다.

절대적으로 동의합니다. 또한, 우리는 계속해서 Destructuring을 사용할 수 있습니다.
예를 들어:
```뷰

<FieldValidation field="login" slot-scope="{ value, setValue, error }">
  <LoginInput
    :value="value"
    :error="error"
    @input="setValue"
  />
</FieldValidation>

<FieldValidation field="password" slot-scope="{ value, setValue, error }">
  <PasswordInput
    :value="value"
    :error="error"
    @input="setValue"
  />
</FieldValidation>

7988a554 및 5d52262f를 통해 폐쇄

요약:

• 모든 슬롯에서 $slot 변수를 지원합니다. ( $slot 있으면 슬롯이 범위 지정 슬롯으로 컴파일됩니다).

• 일반 슬롯을 포함한 모든 슬롯은 이제 this.$scopedSlots 에 함수로 노출됩니다. 즉, this.$slots.default 가 존재한다고 가정하면 this.$scopedSlots.default() 는 해당 값을 반환합니다. 이를 통해 렌더 기능 사용자는 항상 this.$scopedSlot 있으며 더 이상 전달되는 슬롯의 범위가 지정되는지 여부에 대해 걱정할 필요가 없습니다. 이것은 모든 슬롯이 함수로 노출되는 3.0과도 일치합니다(그러나 this.$slots 대신).

• slot-scope 사용에 대한 변경 사항이 없으며 새로운 지시문이 도입되지 않았습니다. 구문 변경을 최소화하고 잠재적인 손상을 3.0으로 남겨두고자 합니다.

@yyx990803 $slot 모든 외부 슬롯 범위를 병합합니까, 아니면 가장 가까운 슬롯만 참조합니까?

@Justineo 병합하지 않고 가장 가깝습니다.

내가 액세스할 수 있는 앱의 범위가 지정된 슬롯 사용량을 살펴보면 중첩된 슬롯 병합 동작이 없는 경우의 절반 이상에서 $slot 속기를 실제로 사용할 수 없는 것 같습니다. 문제는 기본 구성 요소가 일반적으로 원시 HTML 요소 대신 사용되며 이러한 구성 요소에는 종종 자체 슬롯이 있다는 것입니다. 예를 들어:

<MapMarkers :markers="cities">
  <BaseIcon name="map-marker">
    {{ $slot.marker.name }}
  </BaseIcon>
</MapMarkers>

위의 예에는 <MapMarkers> 구성 요소에 대해 범위가 지정된 단일 슬롯 <BaseIcon> 는 범위가 지정되지 않은 슬롯을 허용하지만 슬롯을 전혀 허용하기 때문에 $slot 는 정의되지 않거나 병합 동작이 없는 빈 객체가 되어 clunkier에 대한 리팩터링을 강제합니다.

<MapMarkers :markers="cities">
  <template slot-scope="{ marker }">
    <BaseIcon name="map-marker">
      {{ marker.name }}
    </BaseIcon>
  </template>
</MapMarkers>

여기 내 우려 사항이 있습니다.

• 적어도 내 자신의 샘플링에서 가장 안쪽 슬롯만 참조하는 경우 $slot 의 이점 중 _대부분_이 손실될 수 있는 것으로 보입니다. 사실, 사람들이 배울 API가 더 많기 때문에 득보다 실이 더 많을 수도 있습니다.

• UI 라이브러리는 $slot 를 사용할 수 없다는 사용자 불만에 대한 응답으로 슬롯이 더 적합한 v-html 소품을 과도하게 사용하기 시작할 수 있습니다.

• 사용자는 경우에 따라 기본 구성 요소를 피하기 시작하여 범위가 지정된 슬롯 사용을 보다 우아하게 유지하여 유지 관리가 덜 쉬운 코드를 만들 수 있습니다.

@yyx990803 $slot 병합에 대한 주요 관심사는 어떤 구성 요소 슬롯 데이터에서 왔는지 말하기가 어렵다는 것입니까? 그렇다면 내가 사용하는 중첩 범위 슬롯에 액세스할 수 있는 앱이 상태 공급자 구성 요소에 대한 유일한 경우라는 것을 아는 것이 도움이 될 수 있습니다. 따라서 특히 이름이 잘 지정된 슬롯 속성의 경우 합법적인 사용 사례에서 실제 모호성이 발생하는 경우는 매우 드뭅니다. 그리고 자동 병합 동작을 통해 사용자는 더 많은 명시성이 필요한지 여부를 스스로 결정할 수 있으며 그럴 때 slot-scope 가 존재합니다.

그러나 절충안으로 여기에 잠재적인 대안이 있습니다. 중첩 범위 슬롯을 병합하는 대신 $slot 가 _범위를 제공한 가장 가까운 슬롯을 참조하도록 하면 어떻게 될까요? 그렇게 하면 가장 모호한 사례를 제거하면서 여전히 내 우려 사항을 해결할 수 있습니다. 생각?

병합을 피하는 주된 이유는 명확하지 않기 때문입니다. 템플릿을 읽는 것만으로는 어떤 $slot 속성이 어떤 공급자 구성 요소에서 오는지 알 수 없습니다. 이를 위해서는 현재 진행 중인 상황을 확인하기 위해 보고 있는 각 구성 요소의 구현 세부 사항을 완전히 알고 있어야 하며, 이는 많은 정신적 부담을 가중시킵니다. 그 시점에 전체 컨텍스트를 염두에 두고 있기 때문에 작성하는 순간에는 괜찮게 들릴 수 있지만, 미래의 독자(당신이든 다른 팀원이든)가 코드를 이해하기가 훨씬 더 어려워집니다.

$slot은 범위를 제공한 가장 가까운 슬롯을 나타냅니다.

나는 그것이 효과가 있다고 생각하지 않습니다. 동일한 문제가 발생합니다. 무슨 일이 일어나고 있는지 확인하려면 구성 요소의 구현 세부 사항에 대해 알아야 합니다. 병합보다 훨씬 더 암시적이고 잠재적으로 혼란스러울 수 있습니다.

장기적으로 가장 좋은 해결책은 slot-scope 의 의미를 변경하여 $slot 별칭/해체 방법이 되도록 하는 것입니다. 따라서 귀하의 예는 다음과 같습니다.

<MapMarkers :markers="cities" slot-scope="{ marker }">
  <BaseIcon name="map-marker">
    {{ marker.name }}
  </BaseIcon>
</MapMarkers>

이렇게 하면 병합할 필요가 없고 어떤 변수가 어떤 공급자로부터 오는지 명시적이며 지나치게 장황하지 않습니다. (이것이 아마도 3.0에서 할 일이라고 생각합니다)

지금 우리가 처한 어색한 부분은 템플릿이 아닌 경우에 slot-scope 를 사용할 수 있도록 허용했는데 이제는 구성 요소 자체에서 사용하지 못하도록 막는 것입니다.

3.0에서 의미 체계를 변경하면 많은 혼란과 마이그레이션 문제가 발생할 수 있습니다.

아마도 우리는 새로운 속성 slot-alias 을 도입함으로써 while 문제를 피할 수 있습니다. $slot 를 다른 것으로 앨리어싱하는 것과 정확히 일치합니다. 달리 slot-scope , 그것은 단지 구성 요소에 사용할 수있는 자체 또는 템플릿 슬롯 컨테이너 (이 그것과 같은 정확히 일하는 것이 의미합니까 slot-scope 에 사용하는 경우 <template> ) :

중첩된 기본 슬롯:

<MapMarkers :markers="cities" slot-alias="{ marker }">
  <BaseIcon name="map-marker">
    {{ marker.name }}
  </BaseIcon>
</MapMarkers>

<foo slot-alias="foo">
  <bar slot-alias="bar">
    <baz slot-alias="baz">
      {{ foo }} {{ bar }} {{ baz }}
    </baz>
  </bar>
</foo>

중첩이 없는 명명된 슬롯:

불가피하게 장황하게 되는 유일한 경우는 중첩이 있는 이름이 지정된 슬롯입니다.

<foo>
  <template slot="a" slot-alias="a">
     <bar slot-alias="b">
        {{ a }} {{ b }}
     </bar>
  </template>
</foo>

(사실 이것은 slot-scope AND slot-alias 를 모두 사용하여 덜 장황할 수 있지만, 오히려 혼란스러울 수 있다고 생각합니다. 저는 slot-scope 모두 사용하지 않는 데 찬성합니다.)

<foo>
   <bar slot="a" slot-scope="a" slot-scope="b">
      {{ a }} {{ b }}
   </bar>
</foo>

마지막으로 () (JSX 렌더 소품은 일반적으로 () 시작하는 화살표 함수이기 때문에):

<MapMarkers :markers="cities" ()="{ marker }">
  <BaseIcon name="map-marker">
    {{ marker.name }}
  </BaseIcon>
</MapMarkers>

<foo ()="foo">
  <bar ()="bar">
    <baz ()="baz">
      {{ foo }} {{ bar }} {{ baz }}
    </baz>
  </bar>
</foo>

위와 동등한 JSX와 비교하십시오.

<foo>
  {foo => (
    <bar>
      {bar => (
        <baz>
          {baz => `${foo} ${bar} ${baz}`}
        </baz>
      )}
    </bar>
  )}
</foo>

디자인이 원래 제안된 것과 매우 다르기 때문에 닫습니다. 대신 새 스레드를 엽니다.