Vue: [放棄] RFC：スコープスロットの使用を簡素化

いいね。 引数を使用してスロット名を指定することを考えていましたが、これにより、複数のディレクティブvスコープを同じコンポーネントで使用できるため、コンポーネントに提供されたコンテンツを再利用できます。 それが有用かどうか、または問題につながる可能性があるかどうかはわかりません

全体的に、これにより、時間とともに使用されるレンダリングレスコンポーネントのAPI使用が改善されます🙌

私が正しく理解していれば、 v-scopeは1つのユースケースにしか役立ちません。 書く代わりに：

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

我々は書ける：

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

この場合、かなりのノイズが減少しますが、それが唯一のケースのようです。 新しいディレクティブを導入するのは、ある種のやり過ぎのように感じます（コンポーネントでのみ機能し、その下の<slot>ロジックに依存しているため、 v-forからでも、他のディレクティブとはまったく異なる動作をします）。 もう1つの懸念は、このリポジトリで検索すると、テンプレートサブツリー（https://github.com/vuejs/vue/issues/5269）のデータスコープの縮小について話し合っているのは2回だけであるということです。 ＃issuecomment-288912328、https：//github.com/vuejs/vue/issues/6913）、JavaScriptでwithどのように機能するかなど。

それはいいですね。 私に残っている1つの質問は、名前付きスロットをどのように処理したいかということです。 名前付きスロットが同じディレクティブを使用できるようにする場合は、 <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に置き換えることができます。

同じことについて、2つの異なる概念（ v-scopeディレクティブとslot-scope属性）で終わるべきではないと思います。

補足：今、それを見ると、人々は要素の階層から印象を得るかもしれません＆
指定されたスロットのotherScopeおよびscopeにアクセスできるディレクティブ。 マイナス面かもしれません。

@LinusBorgという名前の場合、引数はv-scope:slotName実行できます。 コンポーネントでのみこれを許可することのポイントは、 @ Justineoが言ったことを置き換えることだと思います（https://github.com/vuejs/vue/issues/9180#issuecomment-446168296）

補足：今、それを見ると、人々は要素の階層から印象を得るかもしれません＆
指定されたスロット内の他のスコープおよびスコープにアクセスできるディレクティブ。 マイナス面かもしれません。

それはうまくいきますよね？ 🤔スロットスコープをネストしたと確信しています

それはうまくいきますよね？ 🤔スロットスコープをネストしたと確信しています

私はそれらをネストしませんでした、しかし、それらは兄弟スロットです。 私は、デフォルトのスロットの範囲を定義したv-scopeコンポーネント上、および（兄弟スロットである）という名前のスロットで<template slot="someName">
見る？ 紛らわしいです^^

@LinusBorg使い方が

• v-scopeがコンポーネントで直接使用されている場合、それはデフォルトのスロットのみを使用していることを意味します。
• 名前付きスロットを使用する場合は、 slot + slot-scopeを使用する必要があります。

v-scopeとslot-scope両方を使用すると、特に現在の設計にどのように到達したかを知らない新規ユーザーにとって、一貫性がなく混乱する可能性があることに同意します。

問題の内訳

合成しようとすると、次のようなソリューションが必要なようです。

• スコープスロットからのデータにアクセスするために必要な定型文を減らす
• デフォルトスロットのデータが名前付きスロットで利用可能であることを暗示することは避けてください
• 導入する必要のある新しいAPIの数を最小限に抑える
• Webコンポーネントの仕様にすでに許容可能なソリューションがあるAPIを再発明しないでください
• データがどこから来たのかについての混乱を避けるために、明示的にしてください

私はこれらすべてに対処する解決策があるかもしれません！ 🤞で$eventについて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の表面積は大幅に削減されます。

• $プレフィックスが付いたプロパティを使用することで、 $slotがVueのものであることを明確にする方法でWebコンポーネントスロットAPIを構築しています。

• 現在、ライブラリは<slot v-bind="user" />ようなことをすることが多く、ユーザーはslot-scope="{ user }代わりにslot-scope="user"数文字を保存できます。 一見エレガントに見えますが、アンチパターンとして体験するようになりました。 この問題は、コンポーネントがユーザー以外のデータを公開したい場合に発生します。 次に、2つの選択肢があります。ユーザーとはほとんど関係がない場合でも、APIに重大な変更を加えるか、この新しいプロパティをuserオブジェクトに強制します。 どちらも素晴らしい選択肢ではありません。 幸い、 $slotは、コンポーネントの将来性を低下させたいという誘惑を取り除きます。 $slotはまだ$slot.userよりも短いのですが、ユーザーを$slotとしてエイリアスすると、重要なコンテキストが失われるためです。

短所

• 一部のネストされたスコープスロットでは、一部のデータがどのコンポーネントからのものであるかが明確でないエッジケースがいくつかあります。 ただし、これらの場合でも、ユーザーは最大限の明示性が必要なときにslot-scopeに到達できるため、大したことではないと思います。 さらに、前述したように、そもそもこの問題が発生した場合、ユーザーが州のプロバイダーコンポーネントを使って自分の足を撃っている可能性が非常に高いと思います。

$始まるプロパティは、Vueインスタンス全体で一貫している必要があると思います。 $slotを各スロットに暗黙的に挿入することで混乱が生じるかどうかはわかりませんが、実際にはこれらのスロットスコープ内のローカル引数を表しています。 $始まるプロパティは、すべてのVueインスタンスで使用できるものを表すため、ライフサイクルフック、メソッド、レンダリング関数など、どこでも使用できるという慣習のようなものです（私の観察によると）。 この特別な$slotを追加すると、この規則が破られます。

@chrisvfritzこれは興味深い提案ですが、通常のスロットとスコープスロットが統合されていることに依存しています（したがって、v3で検討できるものかもしれません）。 これに関する最大の問題は、スロットコンテンツが子コンポーネントの$slotsまたは$scopedSlotsかどうかです。 唯一のヒントは、式のどこかに$slotが存在することです（ツリーのどこにでも配置できます）。これは、 slot-scope （スロットルートにのみ存在できます）ほど明示的ではありません。 技術的にはコンパイラでこれを検出できますが、ユーザーがテンプレートで$slotを使い始めると、スロットは$slotsから$scopedSlotsします...

これはJSXユーザーに大きな影響を与えますか？

@donnysimいいえ、これはJSXにはまったく影響しません。

$始まるプロパティは、Vueインスタンス全体で一貫している必要があると思います。 $slotを各スロットに暗黙的に挿入することで混乱が生じるかどうかはわかりませんが、実際にはこれらのスロットスコープ内のローカル引数を表しています。

@Justineo最初は同じ考えでしたが、 $eventでこれを行っており、誰も文句を言っていないようです。そのため、すでに前例があり、ユーザーは通常混乱せず、本当に便利であるという証拠があります。

これに関する最大の問題は、スロットコンテンツが子コンポーネントの$slotsまたは$scopedSlotsかどうかです。

@ yyx990803すばらしい質問です！ 私はうまくいくかもしれないという考えを持っています。 あいまいな場合（ $slotを使用してネストされたスロット）、すべてのスロットをスコープスロットにコンパイルするだけでなく、すべての$scopedSlotsを$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
  })
}

そのように、次の場合：

<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下でゲッターとして利用できるようにします

$slots.fooと$scopedSlots.fooを区別して、レンダリング関数で別々に使用することはできなくなりました。

$ slots.fooと$ scopedSlots.fooを区別して、レンダリング関数で別々に使用することはできなくなりました。

正直なところ、すべて（slotsと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) {

しかし、私はまだそれが重大な変化だとは思いません。 まず、同じ名前のスロットとスコープスロットの使用を文書化/推奨したことがないため、公開契約の一部ではありませんでした。 次に、前述のように、テンプレートのスコープスロットは、同じ名前のスコープなしスロットにすでにフォールバックしています。これは、スコープ付き/スコープなしの境界をこのように使用することを意図していなかったという歴史的な証拠として役立ちます。

それは理にかなっていますか？ また、スロット名を再利用するための実際の使用例を見たことがありますか？ それとも何か考えられますか？ できませんが、それが可能にする便利でユニークなパターンがあれば、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>

これは混乱する可能性があります

この場合のより直感的な使用法は次のようになります

全く同感であります。 また、引き続き破壊を使用できます。
例えば：
`` `vue

<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>コンポーネント用のスコープスロットは1つだけです。 <BaseIcon>はスコープのないスロットを受け入れますが、スロットをまったく受け入れるため、 $slotは未定義であるか、マージ動作のない空のオブジェクトであり、より不格好なリファクタリングを強制します。

<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とは異なり、コンポーネント自体またはテンプレートスロットコンテナでのみ使用できます（これは、 <template>使用した場合にslot-scopeとまったく同じように機能することを意味します） ：

ネストされたデフォルトスロット：

<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と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>

デザインが当初提案されたものとは大きく異なるため、締めくくります。 代わりに新しいスレッドを開きます。