Vue: UIコンポーネントのAPIが改善され、属性とイベントを転送するための定型文が削減されました

うーん、それについてはわかりませんが、そのようなコンポーネントの場合は、JSXまたはcreateElementを使用して小道具を広めることができると思います。

https://github.com/doximity/vue-genome

私たちにとって、これは素晴らしいことです。 スタイリングとUXの目的で、すべての入力をラベルでラップします。 代わりにjsxにドロップダウンできることに同意しますが、テンプレートは誰にとっても非常に簡単です。

@Austio 、残念ながら、それはテンプレートの見返りです...待ってください...多分私たちはspread小道具をvueテンプレートに入れる方法を考えることができますか？

私は個人的にこの機能が好きです。 しかし、ルート要素のclassプロパティをバインドする必要がある場合があるように、v-bindの動作の一貫性が損なわれているようです。

では、次のようなゲッターとセッターとしてディレクティブのペアを使用するのはどうですか？

コンポーネント内で、 v-exposeアンカーを定義します。

<input v-expose="foo" />

使用する場合：

<the-component v-define:foo="{propA: '', propB: ''}"></the-component>

<!-- or maybe use v-bind for it directly -->
<the-component :foo="{propA: '', propB: ''}"></the-component>

@jkzing 、それは素晴らしいように見えますが、これも基本的なスプレッドのように見え、 @keyup.enter.prevent="myAction"どのように定義するかなどの潜在的な問題がありますか？

<the-component :foo="{'@keyup.enter.prevent': myAction}"></the-component>だけを保持することはできません。つまり、ランタイム（vue-template-compilerの一部）でenterやpreventなどのすべての修飾子を保持する必要があります。 atm）

@nickmessing

それは基本的なスプレッドのように見えます

私たちが話しているのは、テンプレートユーザーにスプレッドのようなものをもたらすことです

<the-component :foo="{'@keyup.enter.prevent': myAction}"></the-component>

@はv-onショートランドであり、 prop （v-bind）を意味するものではありません。

@jkzing 、説明からのリンクには、 v-onバインディングもたくさんあります

@nickmessing Um ... v-onバインディングに関しては、イベントバブリングのような別のトピックIMOです。 🤔

@jkzing 、これはv-expose afaikの全体的な概念であり、すべてのプロパティをコンポーネント内の特定の要素に「移動」させるためのものです。

@nickmessing 、元の提案については確信が持てませんが、イベントリスナーをattributeと見なすべきではないと思います。

@jkzing 、おそらくそうではありませんが、9000を超えるさまざまな小道具を使用できる<my-awesome-text-input />の一般的な例を考えると、カスタムコンポーネント内にある<input />をトンなしですべて取得する必要があります。コードの。

私は個人的にv-bind="$props"使用しますが、適用したくない小道具を除外するためにそれらを除外することもできます。 このようにして、入力に一度に複数の小道具を適用できます。 実際、v-exposeは、入力などのラッパーコンポーネントの場合、これらすべてのhtml小道具を指定する必要があるため便利な場合があります。

したがって、この
https://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vue#L9
杖はv-bind="$props"またはv-bind="filteredProps"に削減されます。ここで、filteredPropsは計算されたプロパティである可能性があります。

@cristijora v-bind="someProps"も使用しています。 このソリューションの問題は、過剰なプロパティがHTML属性として追加されることです。 v-bind=が、コンポーネントによって受け入れられないすべてのプロパティを除外できれば素晴らしいと思います。 動的な<component>では、計算されたプロパティでどの小道具を除外するかがわかりません。 それは抽出することが可能ですがoptions.props使いlodash._pick 。

これはディレクティブで本当に実現可能ですか？

@posva 、これ自体はディレクティブとして機能するとは思いませんが、内部での拡散+イベントの伝播などを行うvueテンプレートエンジンの一部である可能性があります

@posvaユーザーが作成したディレクティブではないと思うので、間違った言語を使用している可能性があります。 私が言いたいのは、単なる「特別な属性」です。

@chrisvfritz APIがどのように使用されるかについて何か考えがありますか（公開するものと子に追加する方法を指定します）

これは、概念を提供/注入するために使用されているのと似ていることがわかりました。

@Austio質問を理解していないかもしれませんが、元の投稿でAPIについていくつか考えています。

ねえクリス、親で公開できるものを宣言するインジェクトを提供するために同様のものを使用し、次にそれを子で使用することについての追加の考えを意味しました。

ああ、分かった。 その必要性があるかどうかはわかりません。 情報はすでに小道具やスロットを介して渡すことができます-そして親のプライベートプロパティでさえthis.$parentでアクセスできますが、そのパターンを避けるのが最善だと思います。

@Austioあなたが考えている特定のユースケースはありますか？

@chrisvfritzそれはレンダリング関数でどのように機能しますか？

多分それはより良いだろうと思います：

• ルートノードの属性の自動継承を無効にするオプションを提供します
• たとえば、これらの属性を$attributesとして公開します（tbdに名前を付ける）
• $propsすでに示したように、v-bindを使用して好きな場所に追加します。

v-bind="$attributes"

これには、JSX /レンダリング関数で実質的に同じように機能するという追加の利点があります。

@LinusBorg私はあなたの考え方が好きです。 😄あなたのやり方ははるかに直感的です。

補足として、このAPIを導入すると、Vueの次のメジャーバージョンで属性の自動継承を完全に削除できるため、コンポーネント間の通信を両側で明示的に維持できると思います。

はい、この振る舞いを減価償却または削除することは可能です。

それが価値がある場合は、ライブラリなどの多くのコンポーネントで必要になる可能性のある変更を決定し、コミュニティ、特にUIコレクションの作成者と話し合う必要があります。

提案された機能について：この情報はcontext.data.attributesを介して機能コンポーネントですでに利用可能であるため、この機能は基本的にインスタンスコンポーネントと同じ機能を提供します。

はい、正確に。 私が念頭に置いている主な目的は、UIコンポーネントの作成者（サードパーティと内部の両方）の作業を簡単にすることです。 現在、このようなことが必要な場合がたくさんあります。

<input
  v-bind:id="id"
  v-bind:accept="accept"
  v-bind:alt="alt"
  v-bind:autocomplete="autocomplete"
  v-bind:autofocus="autofocus"
  v-bind:checked="checked"
  v-bind:dirname="dirname"
  v-bind:disabled="disabled"
  v-bind:form="form"
  v-bind:formaction="formaction"
  v-bind:formenctype="formenctype"
  v-bind:formmethod="formmethod"
  v-bind:formnovalidate="formnovalidate"
  v-bind:formtarget="formtarget"
  v-bind:list="list"
  v-bind:max="max"
  v-bind:maxlength="maxlength"
  v-bind:min="min"
  v-bind:multiple="multiple"
  v-bind:name="name"
  v-bind:pattern="pattern"
  v-bind:placeholder="placeholder"
  v-bind:readonly="readonly"
  v-bind:required="required"
  v-bind:src="src"
  v-bind:step="step"
  v-bind:type="type"
  v-bind:value="value"
  v-on:keydown="emitKeyDown"
  v-on:keypress="emitKeyPress"
  v-on:keyup="emitKeyUp"
  v-on:mouseenter="emitMouseEnter"
  v-on:mouseover="emitMouseOver"
  v-on:mousemove="emitMouseMove"
  v-on:mousedown="emitMouseDown"
  v-on:mouseup="emitMouseUp"
  v-on:click="emitClick"
  v-on:dblclick="emitDoubleClick"
  v-on:wheel="emitWheel"
  v-on:mouseleave="emitMouseLeave"
  v-on:mouseout="emitMouseOut"
  v-on:pointerlockchange="emitPointerLockChange"
  v-on:pointerlockerror="emitPointerLockError"
  v-on:blur="emitBlur"
  v-on:change="emitChange($event.target.value)"
  v-on:contextmenu="emitContextMenu"
  v-on:focus="emitFocus"
  v-on:input="emitInput($event.target.value)"
  v-on:invalid="emitInvalid"
  v-on:reset="emitReset"
  v-on:search="emitSearch"
  v-on:select="emitSelect"
  v-on:submit="emitSubmit"
>

新しい$attributesプロパティは、次のように短縮できます。

<input
  v-bind="$attributes"
  v-on:keydown="emitKeyDown"
  v-on:keypress="emitKeyPress"
  v-on:keyup="emitKeyUp"
  v-on:mouseenter="emitMouseEnter"
  v-on:mouseover="emitMouseOver"
  v-on:mousemove="emitMouseMove"
  v-on:mousedown="emitMouseDown"
  v-on:mouseup="emitMouseUp"
  v-on:click="emitClick"
  v-on:dblclick="emitDoubleClick"
  v-on:wheel="emitWheel"
  v-on:mouseleave="emitMouseLeave"
  v-on:mouseout="emitMouseOut"
  v-on:pointerlockchange="emitPointerLockChange"
  v-on:pointerlockerror="emitPointerLockError"
  v-on:blur="emitBlur"
  v-on:change="emitChange($event.target.value)"
  v-on:contextmenu="emitContextMenu"
  v-on:focus="emitFocus"
  v-on:input="emitInput($event.target.value)"
  v-on:invalid="emitInvalid"
  v-on:reset="emitReset"
  v-on:search="emitSearch"
  v-on:select="emitSelect"
  v-on:submit="emitSubmit"
>

それでも、イベントを公開する方法があればいいと思います。 たぶん、空のv-onディレクティブは、親のすべてのイベントリスナーをこの要素に転送できますか？

<input
  v-bind="$attributes"
  v-on
>

または、バンドルしたい複数の懸念事項が発生した場合は、 v-exposeようなものに戻る可能性があります。

<input v-expose>

これは、特定の機能要求ではなく、UIコンポーネントの構築を簡素化する方法についての幅広い議論に変わったので、この問題のラベルを付け直します。 🙂

私はこのトピックに遅れていますが、私にもいくつかの考えがあります。

v-bind現在のソリューションとデメリット

まず、私はすでにv-bind="propObject"機能（非常に強力）を使用していて気に入っています。 たとえば、 bootstrap-vueには、あらゆる場所（ボタン、ナビゲーション、ドロップダウンリストなど）で使用される内部リンクコンポーネントがあります。 コンポーネントはピボットしてネイティブアンカーになるのか、ルーターリンクベースのhref対toとvm.$router存在になるので、条件付きでそれぞれに渡すプロパティはかなりたくさんあります。これらのコンポーネントの。

私たちの解決策は、それらの小道具をミックスインに入れ、計算されたオブジェクトでv-bind="linkProps"を使用すること

v-expose v-bindを使用した可能性

私は個人的にv-exposeの概念が好きで、デフォルトのスロット+名前付きスロットのように機能し、修飾子を使用して名前付き属性スロットにアクセスできる可能性があります。

デフォルトの属性_ "slot" _は、常に属性をコンポーネント自体に渡します（変更なし）が、他の名前付きターゲットはコンポーネントによって指定できます。 おそらくこのようなもの：

<template>
  <my-component 
    <!-- Nothing new here -->
    v-bind="rootProps"
    <!-- This binds the `linkProps` object to the named attribute slot `link` -->
    v-bind.link="linkProps"
  />
</template>

MyComponent.vue内部：

<template>
  <div>
    <router-link v-expose="link" />
  </div>
</template>

イベントプロキシ

.nativeが驚くほど強力な修飾子であることを除いて、ここに追加するものはあまりありません。 私にとって多くの問題を解決しました。 ただし、Vue開発者にはほとんど知られていないようです（開発者をこの機能に公開することで解決されるUI libの問題がたくさんあります）。 私はウェブサイトにPRを配置して、サイトにドキュメントと検索サポートを追加し、Google検索用に最適化する可能性があります。

別の問題でAPIサーフェスについての議論から来て、私はv-exposeアイデアのファンではないことを繰り返す必要があります。 それは別の「物事の仕組み」を導入し、そこに特別な何かを実装しないとJSXでは機能しません。

Reactの人々について私が尊敬していることの1つは、スリムなAPIへの取り組みと、言語の機能を可能な限り使用することです。 その精神では、属性の小道具にすでにあるパターンを再利用することは、別の抽象化を導入するよりもはるかに優れているように思われます。

<my-input
  type="file"
  mode="dropdown"
>

<template>
  <div>
    <input v-bind="$attributes">
    <dropdown v-bind="{ ...$props, $attributes.type }"/>
  </div>
</template

ああ、あなたが今言っていることがわかります。 そして私はそれが好きです！ これは現在利用できますか？ vm.$attributesが代わりに追加されますか？

コメントを読み直します。 私は今追跡しています👍

はい、 $attributesが追加になります。

また、次のように、ルート要素に属性を適用する現在のデフォルトの動作をオフにするオプションが必要になります。
`` `html

これを行うことにした場合、これはVue 3.0のデフォルト設定になり、重大な変更が発生する可能性があります。

@LinusBorg物事のイベント側に対処することについてどう思いますか？ 同じ戦略に従うために、 $listenersプロパティを追加することもできると思いました。これは次のようになります。

{
  input: function () { /* ... */ },
  focus: function () { /* ... */ },
  // ...
}

次に、おそらくv-onは、 v-bindと同様に、オブジェクトを受け入れることができます。 だから私たちは持っているでしょう：

<input v-bind="$attributes" v-on="$listeners">

私が予測する問題の1つは、 input / changeイベントに関するものです。これは、 v-model動作が、要素の場合とコンポーネントの場合でわずかに異なるためです。 $listenersと$nativeListeners両方が必要かどうかもわかりません。 $listenersが利用可能だった場合、 .native修飾子は廃止された可能性があります。

また、 applyComponentAttrsToRootオプションに関しては、おそらくexposeRootElが適切な名前であり、 falseに設定すると、自動的に適用される属性と.nativeイベントの両方が無効になる可能性があります。転送しますか？

Vue.configを介してアプリケーション全体、および単一のコンポーネントに対してこれを無効にできると便利な場合もあります。

私は最近、 $listenersについて同様の考えを持っていました。これは、機能コンポーネントでも利用できます。

context.data.listeners

したがって、 $props 、 $attributes 、 $listenersこれは私にとっては問題ないようです。

$attributesで使用したようなv-on="{...}"オブジェクト構文を要求する＃5578もあり、これはぴったりです。

しかし、.native修飾子についてはよくわかりません。 これをコンポーネントイベントとネイティブリスナーの両方で機能させるには、APIがはるかに複雑になり、ルート要素に適用されたネイティブイベントリスナーが目的のイベントのバブリングをキャッチするため、使用に問題があります。テンプレート内の特定の要素に割り当てる必要があります。

一般に、低レベルのコンポーネントライブラリの場合、テンプレートの操作が難しくなっている場合は、レンダリング関数を使用することをお勧めします。 しかし、私は以下が価値があることに同意します：

1. 「ルート要素への属性として小道具に見つからないバインディングを自動適用する」というデフォルトの動作を無効にします（関連する問題：これはclassおよびstyleバインディングにも影響しますか？）

2. コンポーネントの外部バインディングを、必ずしもルートではない内部要素に「継承」する簡単な方法を公開します。 理想的には、テンプレートとレンダリング関数の間の一貫性があります。

ia kie like vue、シンプルなツール

v2.4でのこのPRは素晴らしいと言いたいだけです！ 👍

リリースノートから

これらを組み合わせると、次のようなコンポーネントを次のように単純化できます。

<div>
  <input v-bind="$attrs" v-on="$listeners">
</div>

これらの種類のコンポーネントはv-modelで動作するように設計されており、私が知る限り、コンポーネントをラップするv-modelはそのままでは機能しないため、良さそうに見えますが、それは完全には真実ではありません。 たとえば、ラッピングコンポーネントから入力にvモデルを転送する方法の例はありますか？
私が見つけた最も簡単な方法：
https://jsfiddle.net/60xdxh0h/2/

たぶん、テンプレートに沿って機能するコンポーネントが機能していると、より簡単になります

これらの種類のコンポーネントはv-modelで動作するように設計されており、私が知る限り、コンポーネントをラップするv-modelはそのままでは機能しません。

どうしてそんなことを考えるのか？ v-modelは、プロップとイベントリスナーの単なるシンタックスシュガーであり、どちらも$ attr / $ propsに含まれるため、簡単に渡すことができます。

子オプションの知識が必要になるのは、子がmodelデフォルトを変更した場合だけだと思いますが、それは本当です。

しかし、状況によってはそれらを読むことは可能でしょう。

確かにそれは構文上の砂糖ですが、私はそれを読むのが混乱する可能性があることを意味します

これらを組み合わせると、次のようなコンポーネントを次のように単純化できます。

実際にhttps://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vueの例に基づいている場合、同じコントロールを実現するために、リスナーを直接渡すことはできません。 （例：v-on：input = "emitInput（$ event.target.value）"を使用する必要があります）

とにかく、このPRは価値があり、良い仕事です！

@AlexandreBonaventureこれは、 v-modelがコンポーネントで動作するのと、要素で動作するのがわずかに異なるためです。 DOMイベントはコールバックにイベントオブジェクトを提供しますが、コンポーネントイベントは値を直接提供します。 その結果、 v-model機能しますが、バインドされた値はDOMのイベントオブジェクトです。 😕

v-modelがここで機能することが望ましいとあなたは正しいと思いますが、それを解決するのに最適な場所がどこにあるかはわかりません。 いくつかのアイデア：

たぶん、非可算プロパティがに加えることができる$listeners例えば（ __$listeners__: trueを助けるために、 v-onの使用を検出v-on="$listeners"次に例ではどこ。 $listenersオブジェクトがv-onに渡され、各リスナーをラップできます。

function (event) {
  listener(event.target.value)
}

欠点の1つは、データを破棄していることです。 たとえば、誰かがkeyCodeにアクセスしたい場合、彼らは運が悪いです。 ただし、 v-onのオブジェクト構文で修飾子がサポートされている場合は、 .nativeで自動折り返し動作を無効にすることで、これを修正できます。

@ yyx990803 @LinusBorg実現可能性についてどう思いますか？ 私が見逃しているエッジケースはありますか？

なるほど、あなたはrralのvモデルを参照しています。 フォーム要素、私はそれをコンポーネントで考えていました。

このPRの有無にかかわらず、とにかく小道具でそれを使用することはできません/すべきではありません。 また、高度なアプリでは、それを使用することはかなりまれです（達成可能ですが）。

@LinusBorg同じページにいることを確認したいだけです。 このテンプレートでCustomInputコンポーネントが与えられた場合：

<div>
  <input v-bind="$attrs" v-on="$listeners">
<div>

以下のコードが機能するとは思わないでしょうか？

<CustomInput v-model="myValue" />

私はそれが機能することを期待します-しかし私がalexandreを理解した方法では、彼はコンポーネントではなく要素のv-modelを参照していました-それは最終的にはローカル状態の変更でのみ機能します。

私は@chrisvfritzが彼の後者の投稿で説明したことを言おうとしてい

@LinusBorg最新リリースでこれを行う際の問題は、それが依然としてアンチパターンと見なされ、状態の変更に関する警告をトリガーすることです。

valueプロパティが文字列以外の場合に上記を機能させると非常に便利です。 たとえば、自分のライブラリからインポートした列挙型を選択オプションの値として使用しようとしているコンボコンポーネントを考えてみましょう。

<template>
    <select class="combo" v-model="value" v-on="$listeners"> 
      <option v-for="(item, key) in items" :value="item">{{key}}</option>
    </select>
</template>

<script>
export default {
    props: {
        items: {
            type: Object,
            required: true
        },

        value: {}
    }
}
</script>

これは、親のアイテムに使用するリストの1つの例です。

            execList: {
                "None": ACT_EXEC_TYPES.NONE,
                "Function": ACT_EXEC_TYPES.FUNCTION,
                "Code": ACT_EXEC_TYPES.CODE
            }

そして、私がコンボコンポーネントをどのように使用するか：

<combo :items="execList" v-model="selectedAction.execType"/>

私はこの作品を2日間作ろうとしていますが、それでも本当にイライラしています。 問題は、$ event.target.valueが常に文字列であり、 :valueはずのように評価されないことです。

@LinusBorg @AlexandreBonaventure @RobertBColton私は、この問題の将来の議論に焦点を当てることができる問題を開いたところです。