Vue: Verbesserte API für UI-Komponenten, Reduzierung von Boilerplates für die Weiterleitung von Attributen und Ereignissen

Hmm, ich weiß nichts darüber, aber für solche Komponenten könnte man JSX oder createElement , um Requisiten zu verteilen.

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

Für uns wäre das super. Wir verpacken alle Eingänge in ein Label für Styling- und Ux-Zwecke. Ich stimme zu, dass wir stattdessen auf jsx fallen könnten, aber die Vorlagen sind für alle so viel einfacher zu befolgen.

@Austio , leider ist das die Rückzahlung für Vorlagen ... warte ... vielleicht könnten wir uns eine Möglichkeit spread Requisiten in Vue-Vorlagen zu verwandeln?

Mir persönlich gefällt diese Funktion. Aber es scheint die Konsistenz des v-bind-Verhaltens zu brechen, da ich manchmal noch die Eigenschaft class für das Root-Element binden muss.

Wie wäre es also mit einem Paar von Direktiven als Getter und Setter wie:

Definieren Sie innerhalb der Komponente einen v-expose Anker:

<input v-expose="foo" />

Bei der Verwendung:

<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 , das sieht toll aus, aber das sieht wieder nach einem einfachen Spread aus und mit möglichen Problemen wie wie würden Sie @keyup.enter.prevent="myAction" ?

Sie können nicht einfach <the-component :foo="{'@keyup.enter.prevent': myAction}"></the-component> , das heißt, Sie müssen alle Modifikatoren wie enter und prevent in der Laufzeit behalten (die ein Teil des vue-template-compiler ist Geldautomat)

@nickverwirrung

das sieht nach einem einfachen Spread aus

Wir sprechen darüber, so etwas wie Spread für Template-Benutzer zu bringen

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

@ ist ein V-on Shortland, bedeutet nicht prop (v-bind).

@jkzing , im Link aus der Beschreibung gibt es auch viele v-on Bindungen

@nickmessing Ähm ... Was v-on Bindungen angeht , es ist ein anderes Thema IMO, wie Event-Bubbling. 🤔

@jkzing , das war das ganze Konzept von v-expose afaik, um alle Eigenschaften zu einem bestimmten Element in der Komponente "gehen" zu lassen

@nickmessing , Ich bin mir beim ursprünglichen Vorschlag nicht sicher, aber ich denke nicht, dass ein Ereignis-Listener als attribute .

@jkzing , wahrscheinlich nicht, aber wenn man das übliche Beispiel von <my-awesome-text-input /> bedenkt , <my-awesome-text-input /> dem Sie >9000 verschiedene Requisiten haben können, möchten Sie nur, dass sie alle zu Ihnen <input /> , das sich in Ihrer benutzerdefinierten Komponente ohne eine Tonne befindet des Codes.

Ich persönlich verwende v-bind="$props" oder Sie können diese herausfiltern, um die Requisiten auszuschließen, die Sie nicht anwenden möchten. Auf diese Weise können Sie mehrere Requisiten gleichzeitig auf eine Eingabe anwenden. In der Tat könnte v-expose nützlich sein, da Sie für Wrapper-Komponenten wie Eingaben alle diese HTML-Props angeben müssen

Also das
https://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vue#L9
kann auf v-bind="$props" oder v-bind="filteredProps" reduziert werden, wobei gefilterte Props eine berechnete Eigenschaft sein könnten

@cristijora Wir verwenden auch v-bind="someProps" . Das Problem bei dieser Lösung besteht darin, dass übermäßig viele Eigenschaften als HTML-Attribute hinzugefügt werden. Es wäre toll, wenn v-bind= alle Eigenschaften herausfiltern könnte, die von der Komponente nicht akzeptiert werden. Bei dynamischen <component> wissen wir nicht, welche Requisiten in berechneten Eigenschaften herausgefiltert werden sollen. Obwohl es möglich ist, options.props zu extrahieren und lodash._pick .

Ist das mit einer Richtlinie wirklich machbar?

@posva , ich glaube nicht, dass dies per se als Direktive funktionieren wird, aber das kann ein Teil der vue-Vorlagen-Engine sein, die so etwas wie interne Verbreitung + eine gewisse Ereignisweitergabe durchführt

@posva Keine vom Benutzer erstellte Anweisung, denke ich, daher verwende ich möglicherweise die falsche Sprache. Was ich meine, ist nur ein "besonderes Attribut".

@chrisvfritz haben Sie irgendwelche Gedanken zu einer API, wie sie verwendet werden würde ( verfügbar gemacht und wie dem Kind hinzugefügt werden soll)

Ich konnte mir vorstellen, dass dies in der Verwendung ähnlich ist, um ein Konzept bereitzustellen / zu injizieren.

@Austio Ich verstehe die Frage vielleicht nicht, aber ich

Hey Chris, meinte zusätzliche Gedanken zur Verwendung von ähnlichem, um injizieren zu können, bei dem du deklarierst, was beim Elternteil entlarvbar sein soll und dann beim Kind.

Ah ich sehe. Ich bin mir nicht sicher, ob das nötig ist. Informationen können bereits über Requisiten und Slots übergeben werden - und sogar auf private Eigenschaften des übergeordneten Elements kann mit this.$parent zugegriffen werden, obwohl ich denke, dass es am besten ist, dieses Muster zu vermeiden.

@Austio Gibt es einen bestimmten Anwendungsfall, an den Sie denken?

@chrisvfritz wie würde das in

Ich denke, vielleicht wäre es besser:

• bieten eine Option zum Deaktivieren der automatischen Vererbung von Attributen für den Root-Knoten
• Machen Sie diese Attribute zum Beispiel als $attributes verfügbar (benennen Sie tbd)
• Verwenden Sie v-bind, um sie hinzuzufügen, wo immer Sie möchten, ähnlich wie wir es bereits mit $props :

v-bind="$attributes"

Das hätte den zusätzlichen Vorteil, in JSX/Render-Funktionen praktisch identisch zu arbeiten

@LinusBorg Ich mag

Als Randbemerkung denke ich, dass mit dieser API die nächste Hauptversion von Vue die automatische Vererbung von Attributen sogar vollständig entfernen könnte, sodass die komponentenübergreifende Kommunikation auf beiden Seiten explizit bleiben könnte.

Es wäre möglich, dieses Verhalten abzuwerten oder zu beseitigen, ja.

Ob sich das lohnt, sind die eventuell erforderlichen Änderungen an vielen Komponenten in Libs etc. zu entscheiden und sollten mit der Community, insbesondere den Autoren der UI-Sammlung, besprochen werden.

A zu dem vorgeschlagenen Feature: Diese Informationen sind in funktionalen Komponenten bereits über context.data.attributes verfügbar, daher würde dieses Feature im Grunde die gleiche Funktionalität wie Instanzkomponenten bieten.

Ja genau. Der Hauptzweck, den ich im Hinterkopf habe, besteht darin, die Arbeit für Autoren von UI-Komponenten (sowohl von Drittanbietern als auch intern) zu vereinfachen. Es gibt derzeit viele Fälle, in denen so etwas notwendig ist:

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

Eine neue $attributes Eigenschaft könnte es folgendermaßen verkürzen:

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

Aber ich denke, es wäre immer noch schön, auch eine Möglichkeit zu haben, Ereignisse aufzudecken. Vielleicht könnte eine leere v-on Direktive alle Ereignis-Listener des übergeordneten Elements an dieses Element weiterleiten?

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

Oder wenn es am Ende mehrere Anliegen gibt, die wir bündeln möchten, sind wir möglicherweise wieder bei v-expose :

<input v-expose>

Dies hat sich zu einer breiteren Diskussion darüber entwickelt, wie das Erstellen von UI-Komponenten vereinfacht wird, und nicht zu einer spezifischen Funktionsanforderung, daher werde ich dieses Problem umbenennen. 🙂

Ich bin zu spät zu diesem Thema, aber ich habe auch einige Gedanken.

v-bind Aktuelle Lösung & Nachteile

Zunächst einmal benutze und liebe ich bereits die v-bind="propObject" Funktion (so mächtig). Bootstrap-vue hat beispielsweise eine interne Linkkomponente, die überall verwendet wird (Schaltflächen, Navigationselemente, Dropdown-Listen usw.). Die Komponente dreht sich zu einem nativen Anker vs. einem Router-Link basierend auf href vs. to und dem Vorhandensein von vm.$router , also gibt es ziemlich viele Eigenschaften, die bedingt an jeden übergeben werden können dieser Komponenten.

Unsere Lösung bestand darin, diese Requisiten in ein Mixin zu packen und v-bind="linkProps" mit einem berechneten Objekt zu verwenden. Das funktioniert großartig, aber es ist immer noch viel Aufwand, dieses Mixin zu _allen anderen Komponenten hinzuzufügen, die die Link-Komponente verwenden_.

v-expose Möglichkeiten mit v-bind

Ich persönlich mag das Konzept von v-expose , und vielleicht könnte es wie Standard-Slot + benannte Slots funktionieren und dann Modifikatoren verwenden, um auf die benannten Attribut-Slots zuzugreifen.

Das Standardattribut _"slot"_ würde immer Attribute an die Komponente selbst übergeben (keine Änderung), während andere benannte Ziele von der Komponente angegeben werden könnten. Vielleicht so etwas:

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

Innerhalb von MyComponent.vue :

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

Ereignis-Proxying

Ich habe hier nicht viel hinzuzufügen, außer dass .native ein erstaunlich mächtiger Modifikator ist. Hat bei mir viele Probleme gelöst. Es scheint den Vue-Entwicklern jedoch weitgehend unbekannt zu sein (ich sehe eine Menge Probleme mit der UI-Lib, die gelöst werden, indem Entwickler dieser Funktion ausgesetzt werden). Ich habe eine PR auf der Website platziert, um weitere Dokumente und Suchunterstützung auf der Website hinzuzufügen und möglicherweise für die Google-Suche zu optimieren.

Ausgehend von einem Streit über die API-Oberfläche in einer anderen Ausgabe muss ich wiederholen, dass ich kein Fan der Idee von v-expose bin. es führt eine andere "Funktionsweise der Dinge" ein und funktioniert nicht für JSX, ohne dort auch etwas Besonderes zu implementieren usw.

Eine Sache, die ich an React-Leuten respektiere, ist ihr Engagement für eine schlanke API und die bestmögliche Nutzung der Funktionen der Sprache. In diesem Sinne scheint es viel besser zu sein, ein Muster wiederzuverwenden, das wir bereits für Requisiten für Attribute haben, als eine weitere Abstraktion einzuführen.

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

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

Ahh, ich verstehe, was du jetzt sagst. Und ich mag es! Ist das aktuell verfügbar? vm.$attributes wäre stattdessen die Ergänzung?

Lesen Sie Ihre Kommentare noch einmal. Ich verfolge jetzt

Ja, $attributes wäre der Zusatz.

Außerdem bräuchten wir eine Option, um das aktuelle Standardverhalten beim Anwenden von Attributen auf das Root-Element wie folgt zu deaktivieren:
```html

Dies könnte dann eine Standardeinstellung in Vue 3.0 werden, wenn wir uns dann dazu entschließen, dies zu tun, was zu einer bahnbrechenden Änderung führt.

@LinusBorg Was $listeners Eigenschaft hinzufügen, die wie folgt aussehen könnte:

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

Dann könnte v-on vielleicht ein Objekt akzeptieren, ähnlich wie v-bind . Wir hätten also:

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

Ein Problem, das ich vorhersehe, betrifft input / change Ereignisse, da v-model für Komponenten etwas anders funktioniert als für Elemente. Ich weiß auch nicht, ob wir sowohl $listeners als auch $nativeListeners . Ich nehme an, wenn $listeners verfügbar wäre, dann wäre der Modifikator .native möglicherweise veraltet.

Auch in Bezug auf die applyComponentAttrsToRoot Option, vielleicht exposeRootEl wäre ein guter Name, das , wenn auf false , könnte beide automatisch angewandt Attribute deaktivieren und .native Veranstaltung Weiterleitung?

Es könnte auch schön sein, dies für die gesamte Anwendung über Vue.config sowie für eine einzelne Komponente deaktivieren zu können.

Ich hatte vor kurzem eine ähnliche Idee zu $listeners - es ist auch für Funktionskomponenten verfügbar über

context.data.listeners

Am Ende würden wir $props , $attributes , $listeners was für mich in Ordnung klingt.

Es gibt auch #5578, das nach der v-on="{...}" Objektsyntax fragt, wie ich es für $attributes , es würde genau hineinpassen.

Beim .native-Modifikator bin ich mir jedoch nicht sicher. Damit dies sowohl mit Komponentenereignissen als auch mit nativen Listenern funktioniert, wäre die API viel komplizierter, und die Verwendung ist fragwürdig, da ein auf das Root-Element angewendeter nativer Ereignis-Listener immer noch das gewünschte Ereignis abfangen würde, so dass es möglicherweise nicht erforderlich sein, um es einem bestimmten Element in der Vorlage zuzuordnen.

Im Allgemeinen würde ich sagen, dass für Low-Level-Komponentenbibliotheken Renderfunktionen bevorzugt werden sollten, wenn die Arbeit mit Vorlagen umständlich wird. Aber ich stimme zu, dass Folgendes wertvoll wäre:

1. Deaktivieren des Standardverhaltens von "automatische Anwendung von Bindungen, die in Requisiten nicht als Attribute auf das Stammelement gefunden werden" (verwandtes Problem: sollte dies auch class und style Bindungen betreffen?)

2. Bereitstellung einer einfacheren Möglichkeit, externe Bindungen der Komponente an ein inneres Element zu "erben", das nicht unbedingt der Stamm ist. Idealerweise mit Konsistenz zwischen Vorlagen und Renderfunktionen.

ia kie wie vue, einfache Werkzeuge

Ich möchte nur sagen, dass die PR dafür in v2.4 ausgezeichnet ist! 👍

Aus der Veröffentlichungsnotiz

Durch die Kombination dieser Elemente können wir eine solche Komponente wie folgt vereinfachen:

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

Scheint nett zu sein, aber das ist nicht ganz wahr, da diese Art von Komponenten für die Arbeit mit V-Modellen entwickelt wurden und meines Wissens V-Modell auf Wrapping-Komponente nicht funktioniert. Gibt es ein Beispiel dafür, wie man beispielsweise ein V-Modell von einer Wrapping-Komponente an eine Eingabe weiterleitet?
Der einfachste Weg, den ich gefunden habe:
https://jsfiddle.net/60xdxh0h/2/

Vielleicht wäre es einfacher, wenn die Funktionskomponente mit der Vorlage arbeitet

Diese Art von Komponenten ist für die Arbeit mit dem V-Modell konzipiert und soweit ich weiß, funktioniert das V-Modell auf der Wrapping-Komponente nicht.

Warum denkst du das? v-model ist nur Syntaxzucker für einen Prop und einen Event-Listener, beide werden in $attr/$props sein und können daher leicht weitergegeben werden.

Ich nehme an, das einzige, was die Kenntnis der untergeordneten Optionen erfordern würde, wäre, wenn das Kind die Standardeinstellungen von model ändern würde, das ist wahr.

Aber es wäre möglich, diese je nach den Umständen zu lesen.

Sicher, es ist ein syntaktischer Zucker, aber ich meine, es könnte verwirrend sein zu lesen

Durch die Kombination dieser Elemente können wir eine solche Komponente wie folgt vereinfachen:

Wenn Sie tatsächlich auf dem Beispiel https://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vue basieren, können Sie Listener nicht einfach direkt übergeben, um die gleiche Kontrolle zu erzielen. ( zB: Sie müssen v-on:input="emitInput($event.target.value)" verwenden)

Wie auch immer, diese PR ist wertvoll, gute Arbeit!

@AlexandreBonaventure Dies liegt daran, dass v-model bei Komponenten etwas anders funktioniert als bei Elementen. DOM-Ereignisse stellen ein Ereignisobjekt für Rückrufe bereit, während Komponentenereignisse direkt einen Wert bereitstellen. Das Ergebnis ist, dass v-model _funktioniert_, aber der gebundene Wert das Ereignisobjekt des DOM ist. 😕

Ich denke, Sie haben Recht, dass es wünschenswert wäre, wenn v-model hier arbeiten würde, aber ich bin mir nicht sicher, wo ich das am besten lösen könnte. Einige Ideen:

Vielleicht könnte eine nicht-zählbare Eigenschaft hinzugefügt wird $listeners (zB __$listeners__: true , um v-on erfaßt Verwendung von v-on="$listeners" . Dann in Fällen , in denen die $listeners Objekt wird an v-on , jeder Listener könnte umschlossen werden:

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

Ein Nachteil ist, dass wir jetzt Daten wegwerfen. Wenn jemand beispielsweise auf ein keyCode zugreifen möchte, hat er kein Glück. Wenn jedoch Modifikatoren für die Objektsyntax von v-on , könnten wir dies beheben, indem wir .native das automatische Umbruchverhalten deaktivieren.

@yyx990803 @LinusBorg Was halten Sie von der Machbarkeit? Irgendwelche Randfälle, die ich vermisse?

Oh, ich sehe, Sie beziehen sich auf das V-Modell auf rral. Formelemente, ich habe über Komponenten nachgedacht.

Sie können/sollten das sowieso nicht für Requisiten verwenden, mit oder ohne diese PR. Und in fortgeschrittenen Apps ist es eher ungewöhnlich, es zu verwenden (obwohl es möglich ist).

@LinusBorg Ich möchte nur sicherstellen, dass wir auf derselben Seite sind. Gegeben eine CustomInput Komponente mit dieser Vorlage:

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

Sie würden nicht erwarten, dass der folgende Code funktioniert?

<CustomInput v-model="myValue" />

Ich würde erwarten, dass es funktioniert - aber so wie ich Alexandre verstanden habe, bezog er sich auf das V-Modell des Elements, nicht auf die Komponente - das schließlich nur mit mutierenden lokalen Zuständen funktioniert.

Ich habe versucht zu sagen, was @chrisvfritz in seinem letzten Beitrag erklärt hat. (Englisch ist nicht meine Muttersprache, sorry :))

@LinusBorg Das Problem dabei in der neuesten Version ist, dass es immer noch als Anti-Muster gilt und eine Warnung vor der Mutation des Zustands auslöst.

Es ist äußerst nützlich, wenn das Obige funktioniert, wenn die value-Eigenschaft etwas anderes als eine Zeichenfolge ist. Nehmen Sie zum Beispiel eine Combo-Komponente, bei der ich versuche, aus meiner eigenen Bibliothek importierte Aufzählungen als Werte für Auswahloptionen zu verwenden:

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

Dies ist ein Beispiel für eine der Listen, die ich für Elemente im übergeordneten Element verwende:

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

Und wie verwende ich die Combo-Komponente:

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

Ich versuche seit 2 Tagen, das zum Laufen zu bringen und bin immer noch sehr frustriert. Das Problem ist, dass $event.target.value immer ein String ist und nicht ausgewertet wird, wie es in :value .

@LinusBorg @AlexandreBonaventure @RobertBColton Ich habe gerade ein Thema eröffnet, in dem wir uns auf die zukünftige Diskussion dieses Problems konzentrieren können.