Vue: 2.0 Änderungen

Ich habe gerade gesehen, dass bestimmte Funktionen nur im Standalone- Build verfügbar sein werden. Bedeutet das, dass sich diese und die NPM- Version deutlich unterscheiden?

@rekateka 2.0 Standalone-Build bedeutet (Compiler + Laufzeit). Der Standardexport des NPM-Pakets ist nur zur Laufzeit, da Sie bei der Installation von NPM wahrscheinlich die Vorlagen mit einem Build-Tool vorkompilieren.

Danke, @yyx990803. Ich habe noch ein paar Fragen zum Compiler und anderen Funktionen, aber dafür habe ich das Forum genutzt .

Gibt es besorgniserregende Änderungen an Dokumenten, die ich zufällig überprüfen sollte? Gute Arbeit! Mach weiter so, Mann. Sie definieren Webentwicklung neu. Danke schön!

Kann ich this.arg meiner Direktive bekommen?

Ich sehe, dass vnode.data.directives arg , aber wenn ich zwei oder mehr Direktiven habe, kann ich die index nicht kennen.

<!-- show @ 0, img @ 1-->
<img v-show="true" v-img:200*200="imgSrc">

<!-- img @ 0, show @ 1-->
<img v-img:200*200="imgSrc" v-show="true">

Soll ich forEach ? Danke schön!

@banricho guter Punkt, das wurde übersehen! Siehe aktualisierte Signatur der Direktivenfunktion.

Erstmal sorry, denn ich bin mir nicht ganz sicher, ob ich dieses Problem hier stellen könnte, und ich habe ein wenig Anforderungen dazu sagen wollen.
Die Voraussetzung ist, dass ich hoffe, dass ich die Verwendung meiner Komponente so gestalten kann

<carousel>
  <img src="..." alt="..." desc="..." is="argument">
  <img src="..." alt="..." desc="..." is="argument">
</carousel>

Ich hoffe, die Kinder können als Argumente dienen, nicht nur in den Attributen einschränken
Im Moment kann ich eine Komponente erstellen, die Verwendung wie

<carousel items="[{}, {}, {}]"></carousel>

Aber ich denke, es ist nicht ganz gut, ich hoffe, es kann wie das sein, das ich zuvor in React- Coverflow erstellt habe

@andyyou - diese Frage wird wahrscheinlich am besten im Forum gestellt, da es sich weder um ein Problem noch um einen klaren Vorschlag noch um eine echte Hilfe zu diesem Problem handelt.

http://forum.vuejs.org/

Wenn Sie in Ihrem Forenthread feststellen, dass Ihre Anforderungen mit Vue nicht erfüllt werden können, können Sie hier eine neue Ausgabe eröffnen.

Scott

@smolinari Danke

"Aber für komplexere Fälle wird empfohlen, mit Vuex eine dedizierte Statusverwaltungsschicht einzuführen." Dies scheint zu implizieren, dass der Zustand über Ereignisse verwendet werden sollte. Ich sehe sie als völlig getrennt - ein Ereignis ist ein Moment, während sich der Zustand nicht ändert. Man könnte sagen, man könnte den Zustand beobachten, aber auch das vermittelt keinen bestimmten Moment, sondern immer dann, wenn sich etwas ändert. Mich interessiert die Bedeutung dieser Empfehlung.

@jrenton Im Allgemeinen können wir das Ereignissystem einfach als Komponente A betrachten, die Komponente B anweist , etwas anderes zu tun.
Im ersten Fall können wir die Zustandsverwaltung (Verwaltung eines gemeinsamen Zustands für A und B) verwenden, anstatt das Ereignissystem zu verwenden, damit A B anweist, den Zustand zu ändern.
Für den zweiten Fall denke ich, dass er mit dem 'Event Bus'-Ansatz ziemlich gut gehandhabt werden kann.

@jrenton anstelle einer Suppe von Komponenten, die miteinander sprechen, schlägt Vuex einen einzigen Kanal für Komponenten vor, um "Intentionen" mit Aktionen auszudrücken und "Fakten" mit Mutationen aufzuzeichnen.

Ich verwende Twig zusammen mit Vue.

Bis jetzt (vue 1.0) habe ich Daten wie folgt an meine Komponenten übergeben:

<my-component data="{{ DATA }}"><my-component>

(Beachten Sie, dass {{ und }} Zweig-Tags sind - für vue habe ich benutzerdefinierte Trennzeichen ${ und } )

Wenn ich die Dinge richtig verstehe, sollte ich es in Vue 2.0 so machen:

<my-component :data=" '{{ DATA }}' "></my-component>
Rechts?

@gholol nein es ist nur

<my-component :data="{{ DATA }}"></my-component>

Eigentlich scheint es, als ob Ihre alte Verwendung überhaupt nicht funktionieren sollte.

Naja hat gut geklappt...

Wie gesagt, die Daten stammen von der Twig-Templating-Engine. Jetzt in Vue 2.0 funktioniert es nicht. Ich habe versucht, es wie Sie sagten (ohne einzelne Apostrophe) zu übergeben, aber die Dateneigenschaft wird undefiniert.

Fehler: SyntaxError: fehlt } nach der Eigenschaftsliste

BEARBEITEN: Es funktioniert, ich habe vergessen zu erwähnen, dass die DATA-Variable eine Zeichenfolge ist

@jrenton Meine Idee und Motivation ist ziemlich einfach, anscheinend mag Vue React nicht, das uns dazu zwingt, JSX zu verwenden. Wir können viele template auswählen.

Ich hoffe, ich kann die Syntax der Kinderelemente als Parameter (Argumente) verwenden. Übergeben Sie Argumente an die übergeordneten Elemente, da wir in einigen Vorlagensprachen wie slim wenn Sie ein bisschen viele Attribute haben oder sagen, dass der Name des Attr ziemlich lang ist, angeben müssen alle Dinge in einer Zeile. Es ist einfacher, Code aus einer Zeile mit mehr als 80 Zeichen zu erstellen.

@ yyx990803 Lust auf Abenteuer heute , wie viel Mühe sehen wollte einfache Interpolation zu verwenden , um einige 1,0 bis 2.0a wandern würde es dauern, leider , da es nicht möglich ist , mehr, wie würde ich mich über und etwas tun , einfach wie <input type="text" name="account[categories][{{ category.id }}]"> in 2,0?

ES6-Inline-Vorlagen funktionieren in Bindungsausdrücken:

<input type="text" :name="`account[categories][${ category.id }]`">

https://jsfiddle.net/Linusborg/cm4v75xh/

Wenn das der einzige Weg ist, dies mit 2.0 zum Laufen zu bringen, dann habe ich nichts dagegen zu sagen, dass dies eine Regression in der schönen Syntax ist, an die wir uns gewöhnt haben – ja, ich weiß, das ist nur ES2015.

Ich gehe davon aus, dass die Interpolation aus Leistungsgründen entfernt wurde? Ich hoffe nur, dass es die hässlichere Syntax wert ist.

@oskarkrawczyk Ich name="account[categories][fruits]" möchten, da Ihr Ausdruck dies darstellen würde.

Die 2.0-Version (und tatsächlich die richtige 1.0) wird :name=" 'account[categories][' + category.id + ']' " .

@simplesmiler Verstanden. Ich glaube, {{ }} mich nur ein bisschen verwöhnt.

@yyx990803 kann ich eine Komponente wie

    render () {
        return this.$createElement('div', { staticClass: 'list-container' }, this.list)
    },
    data () {
         return {
               list: []
         }
    },
    method: {
         a () {
               this.list.push(this.$createElement('myComponent', {}))    
         }
    }

Wie kann ich wenige Werte für ein Attribut binden, die vom Ausdruck abhängen? Beispielsweise:

new Vue({
  el:'body',
  data:{
    flag: true
  }
})

<input type="text" v-bind:placeholder="{test: flag, test2: !flag}" />

Ich erwarte das nächste Ergebnis:

<input type="text" placeholder="test" />
<!-- or -->
<input type="text" placeholder="test2" />

@nervgh das ist nicht der richtige Ort, um diese Frage zu stellen.
Verwenden Sie den ternären Ausdruck v-bind:placeholder="flag ? 'test' : 'test2'" .

@simplesmiler , danke für deine Antwort. Ich versuche zu sagen, dass _Object-Syntax_ in diesen Fällen nützlich sein wird, aber es funktioniert nicht wie ich es erwarte.

Die @nervgh- Objektsyntax gilt nur für Attribute, die eine Liste von Zeichenfolgen annehmen. Von den nativen Attributen ist das einzige solche Attribut class , und für die Komponenten gibt es keine Möglichkeit, von der untergeordneten Seite zu erkennen, ob Sie eine Liste von Strings oder ein richtiges Objekt senden wollten.

Betreff: .once und .sync sind veraltet.

Durchbricht das nicht wirklich gängige Designmuster?

Ich kann mir nicht vorstellen, wie Sie ohne diese einfache Komponenten für den Umgang mit Formularfeldern haben könnten.

Ich habe einfache Komponenten für verschiedene Formularfeldtypen, z. B. hier meine "Textbox"-Komponentenvorlage:

<label>{{type.caption}}:<input type="text" v-model="data"></label>

...und auch eine komplexere Komponente für Listen, die eine Benutzeroberfläche zum Hinzufügen und Entfernen von Elementen aus Arrays in der Datenstruktur bietet

Dann verwende ich diese Komponenten zB so:

<div v-for="field in type.fields">
    <component :data.sync="data[field.name]" :is="field.ctype" :type="field">

Hinweis: Alle diese Komponenten haben zwei Requisiten: data und type . data ist der Knoten in der zu bearbeitenden Datenstruktur, für den die Komponente verantwortlich ist und eine Benutzeroberfläche zum Bearbeiten bereitstellt, und type ist der Knoten in der (massiven, statischen) Datenstruktur, die die Typen enthält /Felder-Hierarchie.

Wie kann so etwas ohne .sync funktionieren?

Es scheint mir, dass es die Dinge sehr komplizieren würde, eine Art Messaging-System zwischen diesen Komponenten zu erstellen, bei dem die Unterkomponenten dem übergeordneten Element irgendwie mitteilen können, um welche Unterkomponente es sich handelt, und das übergeordnete Element kann dann herausfinden, welcher Teil seiner Daten ist Struktur zu ändern.

Ich hoffe wirklich, dass ich etwas übersehe.... denn es sieht so aus, als ob Sie sagen, dass die Verwendung von Komponenten zum Erstellen von Editoren für Teile Ihrer Datenstruktur ein Anti-Muster ist. Was? Bisher habe ich Vue nur dafür verwendet. Ich vermute, Sie denken, dass das Entfernen dieser Funktion die Leute ermutigen wird, saubereren Code zu schreiben. Vielleicht wird es auf einige Leute diesen Effekt haben, aber viele Leute werden viel schlimmeren Code schreiben, um diese Einschränkung zu umgehen. Das Ändern des Status ist die einzige nützliche Sache, die Computer tun. Bitte machen Sie dies weiterhin einfacher.

@JasonWoof v-model in 2.0 kann mit benutzerdefinierten Komponenten arbeiten. Die Komponente muss lediglich:

1. enthülle eine Requisite namens value
2. ein input Ereignis ausgeben, wenn der Wert mit dem übergeordneten Element synchronisiert werden muss, z. B. this.$emit('input', value)

Siehe Beispiel .

@yyx990803 Danke für die Erklärung und den Link. Jetzt bleibe ich einfach hängen:

Warum .sync entfernen?

Ich sehe keinen Vorteil, nur Nachteile. Das von Ihnen verlinkte Beispiel zeigt, dass Sie dasselbe mit :selected.sync oder v-model . Nachteile sehe ich nur bei der v-model Methode:

1. Es erfordert einen erheblichen Boiler-Plate auf der Unterkomponentenseite, ist komplizierter, mehr zu erlernen usw.
2. Sie können nur einen Wert mit V-Modell übergeben, aber Sie können mehrere .sync Requisiten haben

Ich sehe nicht, wie der Wechsel zum V-Modell etwas klarer / sauberer macht. In beiden Fällen ist der einzige Hinweis in der Elternkomponente, dass die Kindkomponente den Elternstatus leicht ändern kann, die Syntax der Requisite in der Vorlage. Ich würde sogar argumentieren, dass .sync klarer ist.

Die andere Sache ist, dass, wenn Sie Objekte/Arrays/usw. als Requisiten übergeben, diese von der untergeordneten Komponente aus veränderbar sind. In diesem Fall können Sie Programmierer also nicht davor schützen, den Zustand der untergeordneten Komponenten zu ändern (was meiner Meinung nach sehr häufig ist.) Es scheint mir, als würden Sie einen Stolperstein einführen, indem Sie das entfernen, was es so macht Das Übergeben von Zeichenfolgenwerten funktioniert genauso wie das Übergeben von Objektwerten. .sync macht meinen Code einfacher und konsistenter, indem meine "Daten"-Requisiten immer von der untergeordneten Seite aus beschreibbar sind, unabhängig vom Datentyp.

Ich bin neu bei Vue.js (vor 3 Tagen), aber von dem, was ich bisher gesehen habe, ist Vue.js hauptsächlich aus zwei Gründen wertvoll:

1. einfache Dom-Manipulation mit Vorlagen
2. automatische Weitergabe von Wert-/Datenänderungen, einschließlich Auslösen von Vorlagenänderungen

Zumindest habe ich das bisher herausgefunden.

Es scheint mir, dass das Entfernen von .sync es schwierig macht, Vue.js dazu zu bringen, das zweite konsequent auszuführen.

@JasonWoof, weil explizite vs. implizite Nebenwirkungen außerhalb des eigenen Bereichs der Komponenten den Unterschied in der langfristigen Wartbarkeit

... und obwohl man argumentieren könnte, dass die Leute einfach lernen sollten, wann sie .sync nicht verwenden sollten, sind unsere bisherigen Erfahrungen anders. Leute neigen dazu, sich zu sehr darauf zu verlassen und Code zu erstellen, den sie später kaum debuggen können.

Dies ist also eine Designentscheidung, um die Leute von Anfang an dazu zu zwingen, es richtig zu machen.

ein Beispiel:

• Wir synchronisieren einen Wert name zwischen einem Elternteil und einem Kind. Alles ist gut.
• wir entscheiden _'hey, wenn sich dieser Wert ändert, müssen wir etwas in den Eltern machen!'_
• Also erstellen wir eine watch Funktion. Schön!
• Später stellen wir fest, dass der Wächter zu schießen scheint, wenn wir es nicht wollen. Aber wir können nicht wirklich sagen, warum, weil wir console.log() nirgendwo hinstellen können, um das Verhalten zu verfolgen.
• Nach langem Nachdenken stellen wir fest, dass wir _wirklich_ nur wollen, dass _etwas_ passiert, wenn der Wert im Elternteil geändert wird, nicht im Kind oder "Großelternteil".
• Jetzt versuchen wir einen Weg zu finden, diese Szenarien in der watch Funktion irgendwie zu differenzieren.
• Nur um zu erkennen, dass dies eine einfache Sache sehr kompliziert macht
• und am Ende sagt uns jemand, dass wir die Synchronisierung entfernen sollen, also werfen wir alles weg und verwenden eine Einweg-Prop und ein ausgegebenes Ereignis, um die Situation zu handhaben - der Code wird einfacher und expliziter, sodass es einfach ist, darüber nachzudenken, wie und wenn Daten fließen und es einfacher wird, sie zu debuggen. Der Fehler ist schnell gefunden und wir können weitermachen.

...und das wird noch verrückter, wenn Sie mehr als eine Ebene tief synchronisieren.

Dies ist ein (Anti-)Muster, das wir immer wieder in den Foren und im gitter-Chat gesehen haben.

Das Entfernen von .sync zwingt die Leute, von Anfang an klaren, expliziten und wartbaren Code zu schreiben, weil ihr Code die meiste Zeit für .sync nicht einfach genug bleibt.

OK. Danke für die Erklärung.

Es ist gut zu hören, welches Problem Sie lösen möchten.

Ich bezweifle jedoch ernsthaft, dass dies helfen wird ... Machen Sie es so, dass die Leute nicht so leicht die Muster brechen können, die Sie mögen, und die Leute werden viel schlimmere Dinge tun, um die Einschränkungen zu umgehen.

Das erinnert mich stark an Abstraktion. Abstraktionen bringen uns in so viele Schwierigkeiten. Sie machen Code schwer zu lesen, schwer zu debuggen usw... Aber Sie können dies nicht beheben, indem Sie die Möglichkeit nehmen, Abstraktionen zu machen... das ist so ziemlich das, was Programmieren möglich/nützlich macht. Die Lösung hierfür liegt nicht auf der Sprach- oder Rahmenebene, sondern im Lehren, Beraten, Lernen. Wir ermutigen die Menschen, die Dinge nicht zu abstrakt zu machen.

Für mich hört sich das so an, als ob Sie von einer solchen Designphilosophie sprechen. In vielen Fällen ist es eine großartige Philosophie, die Sie beim Codieren im Hinterkopf behalten sollten. Aber wenn es als Einschränkung auferlegt wird und der Programmierer denkt, dass diese Einschränkung sie davon abhält, das zu tun, was sie tun muss, dann wird sie sie umgehen, was zu all den Problemen führt, die Sie vermeiden wollten und noch schlimmer.

Die Leute werden nicht aufhören zu versuchen, den Elternzustand der Kinder zu mutieren. Sie können die Leute nicht zwingen, das nicht zu tun.

Ihre Sache mit v-model ist kompliziert genug, dass ich dieses Problem umgehen würde, indem ich das übergeordnete Objekt/Array und einen Schlüssel übergebe, damit das Kind es ändern kann.

Ich denke, dieser letzte kleine Hit ist der Kern dessen, was ich zu vermitteln versuche: Ich sehe (persönlich) das Fehlen von .sync als Problem und werde es umgehen oder Ihr Framework nicht verwenden. Ich wette, viele Leute werden den gleichen Ansatz haben.

Das ist vielleicht selbstverständlich, aber es macht mich ein bisschen wütend, wenn Leute versuchen, mir Designphilosophien aufzuzwingen. Ich würde viel lieber Dinge bauen, die schrecklich schief gehen und lernen, das nicht noch einmal zu tun, als Systeme zu verwenden, die absichtlich die Macht vorenthalten, aus Angst, dass ich sie schlecht gebrauchen könnte.

PS Sorry, ich kann mir nicht helfen, noch ein Kommentar, dann lasse ich euch in Ruhe. Die meisten Programmierer schreiben Code, den sie nicht debuggen können. Das passiert jedem Programmierer in jeder Sprache mit jedem Framework. So werden Programmierer zu besseren Programmierern: Sie machen Fehler, sie machen Code, den sie nicht reparieren können, sie lernen, Dinge in Zukunft anders zu schreiben. Bitte verdummen Sie Ihr Framework nicht für alle, um es so zu machen, dass Programmierer, die sich in die Ecke abstrahieren, ihre Sachen ein bisschen verwirrender/komplexer machen können, bevor es so durcheinander wird, dass sie es nicht debuggen können.

@JasonWoof es hat nichts mit "Verdummen" zu tun und Benutzer vor üblichen Fallstricken zu bewahren / eine bessere Wartbarkeit zu gewährleisten, ist per Definition Teil der Aufgabe eines Frameworks. Wir trafen die Entscheidung auf der Grundlage von Erfahrungen aus erster Hand beim Design, der Nutzung des Frameworks selbst und der Beobachtung des Benutzerverhaltens in verschiedenen Anwendungsfällen. Wenn es sich um ein Anti-Muster handelt, werden wir die Benutzer davon abhalten, es zu verwenden, und eine Anleitung zur idiomatischen Lösung geben. Es steht Ihnen frei, dem aufgrund Ihrer persönlichen Meinung zu widersprechen, aber ich finde Ihre Argumente wenig überzeugend.

Die Leute werden nicht aufhören zu versuchen, den Elternzustand der Kinder zu mutieren. Sie können die Leute nicht zwingen, das nicht zu tun.

Sicher. Und wir werden sie _nicht_ "zwingen", weil es einige Randfälle geben kann, in denen dies noch notwendig sein könnte. So können Sie immer noch Zugriff auf this.$parent , können Sie passieren $data durch eine Stütze usw., aber ganz offen damit nicht viel mehr convient sein , dass $emit ein Ereignis ing die meisten der Zeit, also werden sie nicht so attraktiv sein wie .sync Zucker.

Auch $parent et.al. sind nicht Teil des offiziellen Leitfadens, daher arbeiten Benutzer, die sie verwenden, aktiv an empfohlenen Best Practices - was ihnen freisteht, aber wir fördern dieses Verhalten nicht.

Folglich sollte das Framework kein ähnliches Verhalten fördern, indem es „magischen“ syntaktischen Zucker wie .sync bereitstellt, wenn wir der Meinung sind, dass eine solche Funktion in den meisten Szenarien missbraucht wird und den Best Practices widerspricht, die das Framework zu etablieren versucht.

Hat Youda eine chinesische Version? .

Wie sieht die Kompatibilität für vue-router aus?

@roblav96

Es sind einige Änderungen erforderlich, um kompatibel zu sein. Wir hoffen, den Router besser in Vue integrieren zu können.

@blake-newman

Können wir auf vue-cli eine Boilerplate-Vorlage zusammenstellen? Ich scheine nichts davon zum Laufen zu bekommen

@roblav96

Es gibt derzeit einige, es sind einige Änderungen am vue-loader erforderlich, um ihn kompatibel zu machen. Derzeit sollte 2.0 nur für Experimente verwendet werden, bis alle weiteren Abhängigkeiten für groß angelegte Anwendungen aktualisiert sind.

Gibt es eine ETA für die Beta/Release-Kandidaten?

@Evertt Alpha ist diese Woche fällig. Beta wird folgen mit fertiger Dokumentation und vielleicht mehr Unterstützung von Kern-Erweiterungsbibliotheken (Vue-Router usw.). Release Candidate, wenn Beta erfolgreich ist.

@blake-newman vielen Dank für diese schnelle, prägnante und vollständige Antwort. Das sind die besten. :-D

Irgendein Workaround für replace: false in vue 2.0?

Hallo, ist JSX bereits verwendbar?

@reohjs - Nein, und ich persönlich würde das als echten Rückschritt für Vue ansehen, wenn es JSX unterstützen würde.

Scott

@reohjs In Evans Stream letzte Nacht erwähnte er, dass es mit einem Plugin erstellt werden könnte. Ich bin froh, dass es nicht im Kern enthalten ist, aber ein JSX-Plugin klingt nach einer großartigen Idee.

Ich bin froh, dass es nicht im Kern ist

👍 👍 👍 👍

Ja, sollte ein Plugin sein. Wie man sieht, haben Vorlagen jedoch viele Vorteile für Standardkomponenten.

Die JSX-Kompilierung sollte mit diesem Plugin einfach zu erreichen sein: https://babeljs.io/docs/plugins/transform-react-jsx/

Ich denke, die Funktion _h wäre der Ersatz für React.createElement

Wie wäre es mit der Bereitstellung einer Schnittstelle zum Erstellen benutzerdefinierter V-Modell-Modifikatoren, um 2-Wege-Filter zu ersetzen? Es scheint, dass sie bereits verwendet werden, um Benutzereingaben zu analysieren (zum Beispiel v-model.trim ). Wenn die Analyse/Formatierung einfach und unabhängig von einer bestimmten Dateneigenschaft ist, würde die Verwendung eines Modifikators eine Wiederverwendung der Analyse/Formatierung mit viel weniger Boilerplate ermöglichen, als wenn eine berechnete Eigenschaft für jede einzelne Dateneigenschaft festgelegt oder eine neue Komponente für jede erstellt würde Eingabetyp, auf den die Analyse/Formatierung angewendet werden soll.

Hallo, ich arbeite derzeit an einem Plugin zur Unterstützung von gettext in Vue.js 1.0 und ich habe eine Direktive, die vm.$interpolate .

Ich frage mich, wie ich meinen Code nach 2.0 migrieren kann, da:

• vm.$interpolate wird eingestellt
• Anweisungen haben keine Instanzen mehr in 2.0

Oder gibt es einen besseren Ansatz als eine Richtlinie?

import languages from 'src/plugins/translate/languages'
import translateUtils from 'src/plugins/translate/utils'

const translateDirective = {
  terminal: true,
  params: ['translateN', 'translatePlural'],
  paramWatchers: {
    translateN: function () {
      this.translate()
    },
  },
  isPlural: function () {
    return 'translateN' in this.params && 'translatePlural' in this.params
  },
  bind: function () {
    this.boundTranslate = this.translate.bind(this)
    this.msgid = this.el.innerHTML.trim()
    this.translate()
    languages.eventEmitter.on(languages.languageChangedEventName, this.boundTranslate)
  },
  unbind: function () {
    languages.eventEmitter.removeListener(languages.languageChangedEventName, this.boundTranslate)
  },
  translate: function () {
    let n = this.isPlural() ? parseInt(this.params.translateN) : 1
    let translation = translateUtils.getTranslation(this.msgid, n)
    this.el.innerHTML = this.vm.$interpolate(translation)
  },
}

export default translateDirective

Nur ein paar kurze Worte, da ich neu bei Vue bin, nur um zu sagen, dass ich mich über die Reduzierung der API im Allgemeinen oder die Helfer _unter der Haube_ freue. JavaScript ist bereits sehr mächtig, und mit berechneten Eigenschaften und anderen reaktiven Funktionen des Frameworks kann fast alles erreicht werden.

Hut ab für diese _nächste_ Version! 🎆

@kemar Ich bin mit

{{ $translate('some.Key.path') }}

Wurde die Möglichkeit zum Registrieren von Assets mit Array-Syntax aus 2.0 entfernt? Ich arbeite nicht an Alpha, frage mich nur, ob es beabsichtigt ist oder nicht.
dh:

components: [compA, compB, compC]

Ich weiß, dass ES6 eine Abkürzung hat, die ähnlich aussieht, aber es gibt einige Szenarien, in denen die Array-Syntax nützlich war.

Ich sehe, Sie erwähnen rendering to native interfaces on mobile mit weex und ich habe mich gefragt, wie einfach es wäre, Vue und

Etwas mehr in der Art von Nativescript für Vue wäre entweder Weex, das Sie erwähnt haben, oder Quasar .

Scott

Wenn dispatch oder broadcast wie informiert eine generische untergeordnete Komponente ihre übergeordneten Komponenten über ein Ereignis/eine Änderung? Dies scheint nicht in das Muster eines globalen Busses oder Vuex zu passen. Der Anwendungsfall, den wir jetzt verwenden, ist ein Bereichsschieberegler für Suchfilter. Die Bereichsschieberegler-Komponente ist generisch und ein untergeordnetes Element mehrerer verschiedener Suchfilter. Wir verwenden derzeit dispatch wenn ein Bereichsschieberegler das Verschieben beendet hat, dann weiß das übergeordnete Element, dass eine Suche basierend auf der Änderung ausgelöst wird.

@jrenton Inline-Listener <child @some-event="parentHandler">

Tolle Arbeit Jungs.

Aus meiner Sicht sagen alle Änderungen, dass der beste Ansatz darin besteht, Ihren Komponentenbaum nur auf der Grundlage eines "One-Way-Flow" zu erstellen, der viel einfacher und einfacher zu debuggen und zu warten ist.

Ohne dies wäre Ihre Datenwahrheit umgekehrt proportional dazu, wie weit Sie von der obersten Komponente entfernt sind.

Möchte nur sagen:

render (h) {
    return (
    <div>
      {this.things.map(thing => <Thing thing={thing}></Thing>)}
   </div>
 );

Macht mich glücklich

Ist zu erwarten, dass dieser Liste vor der Veröffentlichung von 2.0 weitere hinzugefügt werden? Nur neugierig, da das Thema noch offen ist.

@zephraph Ja, wir aktualisieren die Liste ständig, während wir Aktualisierungen an der API vornehmen. 😃 Bisher nichts Großes, aber gelegentliche bahnbrechende Änderungen gegenüber früheren Alphas.

Ich habe einen Fall, in dem ich in der Vergangenheit das Ereignis-Dispatching verwendet habe und bei dem ich bei vuex feststecke: Die Elternkomponente hat eine Liste von untergeordneten Komponenten und das Kind hat ein Ereignis gesendet, als sich sein Wert änderte, sodass das Elternteil etwas tun konnte wie eine Reaktion auf diese Veränderung.
Jetzt habe ich versucht, ein Array der untergeordneten Werte im vuex-Speicher zu haben. Die Sache ist die, woher die untergeordnete Komponente im Getter und in der Aktion weiß, welches Element dieses Arrays sie aktualisieren muss. Soweit ich sehe, bietet vuex keine Funktionalität, um eine Mutation eines Werts dynamisch zu erhalten oder auszulösen, oder liege ich da falsch?
Was wäre der beste Weg, diesen Fall ohne Event-Dispatching zu behandeln?

Wenn $broadcast entfernt wird, wie würden Sie einem direkten Kind sagen, dass es etwas tun soll, wenn eine bestimmte Sache passiert? Dies wäre ein Szenario, in dem sich keine Daten tatsächlich geändert haben, sodass reaktive Requisiten nicht zu passen scheinen.

Ich könnte eine Requisite verwenden und einen Zeitstempel oder einige zufällige Daten weitergeben und diese Requisite im Kind beobachten, aber das scheint seltsam. Ein globaler Ereignisbus würde die Generierung eindeutiger IDs erfordern, sodass das Kind nur auf Ereignisse seines Elternteils reagiert und nicht auf irgendeine andere Instanz der Elternkomponente.

Es gibt $emit in einem Kind, das ein Elternteil mit einem Inline-Listener anhören kann, gibt es etwas umgekehrt?

Ich könnte eine Instanz eines Emitters über eine Requisite weitergeben, dann emmiter.on im Kind, klingt das schrecklich?

@gwildu- Aktionen können Argumente annehmen, sodass Sie die Element-ID zusammen mit der Aktion übergeben können. Und anstatt die Artikelkomponente dazu zu bringen, den entsprechenden Artikel aus dem Geschäft zu holen, rufen Sie die Liste im übergeordneten Element ab und übergeben Artikeldaten mit einer Requisite an die Artikelkomponente.

// Vuex store
state: {
  items: [],
},
mutations: {
  ITEM_REMOVED: function(state, id) {
    var io = state.items.findIndex(item => item.id === id);
    state.items.splice(io, 1);
  },
},

// within the parent component
vuex: {
  getters: {
    items: state => state.items,
  },
  actions: {
    removeItem(store, id) {
      store.dispatch('ITEM_REMOVED', id);
    },
  },
},

<!-- within the parent template -->
<item v-for="item in item"
  :item-data="item.data"
  @removed="removeItem(item.id)"
>
</item>

<!-- within the child template -->
<button @click="$emit('removed')">Remove</button>

Wenn Ihre Artikel keine lokal eindeutige ID haben, können Sie eine generieren, wenn der Artikel erstellt oder von der API empfangen wird. Dafür ist

@fergaldoyle Da die Eltern immer wissen, dass es sich um Kinder handelt, können Sie v-ref:some-child auf das Kind setzen, um die Referenz auf die VM des Kindes zu erhalten, und dann entweder $emit darauf legen oder einfach eine Methode direkt aufrufen mit this.$refs.someChild.<methodName>(...) .

Allerdings würde ich in diesem Fall dazu raten, die Architektur zu überdenken, da Ereignisse, die nach unten fließen, es sehr schwer machen, über die Komponente nachzudenken.

Ich habe mit vuejs 2 herumgespielt und ist mir bei Snabbdom aufgefallen, wenn du bestanden hast

h('div', {style: {color: '#000'}}, [
  h('h1', 'Headline'),
  h('p', 'A paragraph'),
]);

Zur Renderfunktion bekommst du

<div style="color:#000;"><h1>Headline</h1><p>A paragraph</p></div>

Aber in Vuejs bekommst du

<div style="color:#000;"><h1></h1><p></p></div>

Gibt es eine Möglichkeit, den Textinhalt (innerhalb von <h1> ) zu ändern?

@dubcanada warum nicht einfach als Kinder weitergeben?

Stimmt, das würde Sinn machen. Danke

Hallo. Ich habe eine Frage zum Übergangssystem in Vue 2.0 oder besser gesagt einen Vorschlag, weil ich es nicht in den Plänen für Vue 2.0 sehe. In Vue 1.0 musste ich oft erkennen, wann ein Übergang/eine Animation, die ich eingerichtet habe, enden würde. Jetzt mache ich dies mit setTimeout, aber das ist sehr hackig und hässlich, da sind wir uns alle einig. Meine Frage ist also, wird es in Vue 2.0 eine Möglichkeit geben, das Ende des CSS-Übergangs zu erkennen, wenn wir den Übergang in Kombination mit v-show/v-if verwenden, möglicherweise über ein Ereignis?

<my-comp v-show="isVisible" @transition-end="onTransitionEnd" transition></my-comp>

Ich würde mich sehr freuen, so etwas in der nächsten Vue-Version zu sehen :)

@sqal kannst du das mit Übergangs-Hooks machen: https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

@dubcanada wird in der nächsten Version unterstützt (Daten beim Erstellen des Elements weglassen)

Danke @fergaldoyle und @simplesmiler für deinen Hinweis zum

Mir war nicht bewusst, dass die Eltern Ereignisse mithören können, die vom Kind ausgesendet wurden. Dann ist es natürlich sinnvoller, sich dieses nicht sprudelnde Ereignis anzuhören.

Hallo zusammen. Ein bisschen Hintergrund: Wir arbeiten mit webgl und ich möchte einige Interfaces auf einer 3D-Oberfläche machen. Dies bedeutet, dass wir eine Schnittstelle beispielsweise auf eine Leinwand rendern und dann den Inhalt der Leinwand in eine Textur konvertieren müssen.

Ich habe mit Angular, React und Vue gearbeitet und für mich macht Vue einfach am meisten Sinn! Beim Lesen über React bin ich auf das Projekt React-Canvas gestoßen. Das Interessante daran ist, dass sie das virtuelle DOM nicht in echte DOM-Knoten umwandeln, sondern es auf eine Leinwand zeichnen.

Da Vue 2.0 auch ein virtuelles DOM verwendet, habe ich mich gefragt, ob so etwas auch möglich ist?

Hallo,

Nur einige Erläuterungen zum Entfernen von .sync und wie ein generischer Workflow für die Handhabung von Requisiten auf einer generischen Komponente aussehen könnte.

also, von
<component :value.sync="some.value"></component>
zu
<component :value="some.value" @update="updateSomeValue"></component>

Was ist die empfohlene Methode, um die Requisite value verfolgen?
Im einfachsten Fall scheint es so zu sein

props: ['value'],
computed: {
    _value: {
        get(){
            return this.value;
        },
        set(newVal) {
            this.$emit('update', newVal);
            return newVal;
        }
    }
}

Dies hängt jedoch sicherlich davon ab, dass die übergeordnete Komponente diesen Wert an die Requisite zurückgibt, sodass die Komponente, wenn sie ihn erneut erhält, die neueste Änderung widerspiegelt ...

Bedeutet das, dass wir jetzt so etwas tun müssen:

props: ['value'],
data() {
    return {
        _val: this.value
    }
},
watch: {
    value(newVal) {
        this._val = newVal;
    }
},
computed: {
    _value: {
        get(){
            return this._val;
        },
        set(newVal) {
            this._val = newVal
            this.$emit('update', newVal);
        }
    }
}

Dies scheint eine Menge Boilerplate zu sein, um das Übergeben (und Ändern) eines Werts zu handhaben, das übergeordnete Element zu benachrichtigen, dass sich der Wert geändert hat, und die Änderung intern zu verfolgen, falls die Änderung nicht vom übergeordneten Element weitergegeben wird.

Oder fehlt mir hier ein bisschen Vue-Magie-Reaktivität?

Es besteht auch die Möglichkeit, dass dies ziemlich kompliziert werden kann, wenn viele Requisiten zu handhaben sind.
Ich könnte mir fast vorstellen, eine Wrapper-Komponente auszuarbeiten, bei der Kinder auf this.$parent.value zugreifen, um direkt zu mutieren, und die Wrapper-Komponente nur die Requisiten/Berechnungen/Uhren behandelt

@Towerful was genau meinst du mit "Wert verfolgen"? Und warum möchten Sie den Setter-Stil ( this._value = newValue ) anstelle des expliziten this.$emit('value-updated', newValue) ?

Die Macht des unidirektionalen Ablaufs besteht darin, dass der Elternteil entscheiden kann, die vom Kind angeforderte Änderung nicht zu übernehmen, oder das Kind als "in Wartestellung" markieren und die Änderung später anwenden können (zB nach Rücksprache mit dem Server).

Wenn @simplesmiler eine berechnete Eigenschaft verwendet, können Sie sie an die Vorlage binden, nicht v-model .
Und wenn Setter und Getter an einer Stelle enthalten sind, können Sie die Funktionalität leicht sehen, wenn der Wert aktualisiert wird, im Gegensatz zu verschiedenen Möglichkeiten, auf den Wert zuzugreifen und den Wert innerhalb der Komponente zu mutieren und im gesamten Code verstreut zu haben.
Wenn Sie innerhalb eines Modells den expliziten Weg verwenden und keine Setter verwenden, scheint es, als ob das methods Objekt mit Methoden vom Typ updateValue für die Vorlage überladen wird, im Gegensatz zu tatsächlichen Methoden.

Ich denke, es trifft zu, wenn der Benutzer eine Option in einer Komponente auswählt und die Komponente sich auf diesen Wert verlässt, um anzuzeigen, was ausgewählt ist.
Sie verlassen sich darauf, dass die übergeordnete Komponente dies an die Komponente zurückgibt, damit sie dies tun kann.
Es sei denn, Sie lösen die Aktualisierung der Komponentenanzeige manuell aus, wenn der Benutzer eine Option auswählt. Was sich von Vues Reaktivität zu entfernen scheint.
Wenn Sie also einen internen Wert haben, der nachverfolgt, was es sein sollte, lassen Sie die Vorlage darauf reagieren. Verwenden Sie Setter/Getter, um die Eigenschaft zu umschließen, um interne Änderungen zu verfolgen und externe Ereignisse auszulösen, und eine Überwachung der Eigenschaft, um den internen Wert zu aktualisieren, wenn er extern geändert wird.

Vielleicht fällt es mir nur schwer, mich mit der neuen Vorgehensweise zurechtzufinden.

@Towerful - Du bist nicht der einzige ....

Scott

@Towerful :

Mir scheint, dass das, was Sie beschreiben, im Wesentlichen Komponenten sind, die sich wie Eingaben mit einem v-model verhalten: Der Benutzer ändert einen Wert in der Benutzeroberfläche, und Sie möchten, dass sich diese Änderung sofort in den gebundenen Daten widerspiegelt.

Für diese Arten von Komponenten können Sie v-model für Komponenten in 2.0 verwenden:

<my-input v-model="myValue">

// in my-input.vue
<input :value="value" @change="$emit('input', $event.target.value)">

export default {
  props: ['value']  //special prop received from v-model
}

Dies macht die Schnittstelle zu echten <input> Elementen und zu benutzerdefinierten Eingabekomponenten im Wesentlichen identisch und eine bidirektionale Bindung.

Bei komplexeren Komponenten, die mehrere Requisiten erhalten (und keine einfachen benutzerdefinierten Eingaben, sondern abstrakter sind), raten wir davon ab, .sync da es in den meisten Situationen schwierig wird, darüber nachzudenken.

Der Elternteil sollte entscheiden, was mit einem Wert zu tun ist, den es vom Kind erhält, seine Daten sollten nicht implizit geändert werden, wie es .sync tut.

Können Sie ein Beispiel liefern, das mit dem obigen v-Modell-Ansatz _nicht_ lösbar ist und trotzdem von der Verwendung von .sync profitiert? Das ist vielleicht eine bessere Diskussionsgrundlage als abstrakte Theorie.

Oh, wie habe ich das verpasst?! Es ist definitiv im OP vorhanden, und vor einigen Kommentaren gibt es sogar eine Diskussion darüber! Jetzt komme ich mir ein bisschen dumm vor.
Könnte der ursprüngliche Beitrag aktualisiert werden, um etwas klarer zu machen, dass v-model für eine Komponente verwendet werden kann?
@LinusBorg Ich kann mir keinen Fall v-model für eine Komponente nicht funktionieren würde. Ich habe diesen Teil im ursprünglichen Beitrag übersehen.
Selbst bei komplizierten Objektkomponenten wäre es nur eine Frage der Verschachtelung von Komponenten. Und dies verstärkt einzelne Verantwortungskomponenten.
Es macht viel mehr Sinn :)

@Towerful

Re: Verwenden von v-model . Die Sache ist, v-model ist (in gewisser Weise) synchron, während der komponentenübergreifende Datenfluss aufgrund der Watcher-Warteschlange ( demo ) von Natur aus asynchron ist. Ich habe gesehen, wie das viele Leute verwirrt hat. Einseitiger Fluss macht nur deutlicher, dass Requisiten nicht synchron sind und zwingt Sie, sich nicht darauf zu verlassen, dass sie synchron sind (dies ist das, was Sie versuchen, sich zurechtzufinden).

Re: überladene Methoden. Für einfache Fälle können Sie immer @value-updated="value = $arguments[0]" tun. Für komplizierte Fälle ist es gut, eine Methode zu haben, mit der Sie den Zustand anpassen können, um ihn konsistent zu halten (zB Updates manuell auslösen). Segway zum nächsten Punkt.

Re: Weg von der Reaktivität. Ich stimme dieser Aussage nicht zu. In einfachen Fällen brauchen Sie keine Magie, um das Kind dazu zu bringen, den um value-updated="value = $arguments[0]" aktualisierten

In komplizierten Fällen müssten Sie mit .sync Requisiten watch , aber explizites watch ist nicht wirklich ein Teil der Reaktivität. Es ist eine Notluke, bei der Sie Ihre manuellen Updates auslösen, die nicht als berechnet ausgedrückt werden können. Und es ist kein gutes, weil es nicht synchron auf Änderungen reagieren kann, wie es berechnet wird. Aus diesem Grund können Sie feststellen, dass Ihre Datenaktualisierungen watch starker Verwendung von nextTick gestolpert sind, wissen Sie, wovon ich rede.

Jetzt bietet der -updated Handler eine bessere Escape-Schraffur, die es ermöglicht, die komplizierten Modelländerungen synchron (oder gleichzeitig asynchron) anzuwenden, nachdem das Kind die Absicht ausgedrückt hat, und stellt sicher, dass das Kind beim nächsten Tick aktualisierte Werte erhält (oder nicht). inkonsistenten Zustand erhalten).

@yyx990803 Könnten wir eine Möglichkeit implementieren, auf $

Fühlt sich vuejs-artig an, etwas in der Art (ein 'an' oder 'hören'):

Vue.component('cart', {
  template: "#cart-template",
  data () {
    return {quantity : 0 }
  },
  watch: {
    'quantity': function (quantity, oldQuantity) {
      console.log('quantity changed from %s to %s', oldQuantity, quantity)

      bus.$emit('cart.quantity-changed', quantity)
    }
  }
});

new Vue({
  el: '.container',
  data : function () {
    return {
      quantity: 0
    };
  },
  on: {
    'cart.quantity-changed': function (newQuantity) {
      console.log('quantity change emitted');

      Vue.set(self, 'quantity', newQuantity);
    }
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

Dies würde sich im Grunde automatisch an den globalen Bus anschließen.

Ereignisbusse sind kein Muster, das wir fördern möchten - es ist nur in einigen Randfällen nützlich. Im Allgemeinen wird ein Speichermuster wie vuex bevorzugt.

Eine API zu implementieren, die die Nutzung eines Busses erleichtert und sich "offiziell unterstützt" anfühlt, wäre das falsche Signal.

Wenn Sie in Ihrem Beispiel die Menge in einem Lager lagern, auf das beide Komponenten zugreifen, sind keine Ereignisse erforderlich. Die berechnete Eigenschaft in der Komponente container würde automatisch aktualisiert.

Einfacher Beispielcode ohne eine echte Store-Lösung wie vuex zu verwenden:

var store = {
  cart: {
    quantity: 0
  }
}
Vue.component('cart', {
  template: "#cart-template",
  data () {
    return store.cart
  },
});

new Vue({
  el: '.container',
  data : function () {
    return store.cart;
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

Ich würde sagen, die allgemeine Idee von vue2 besteht darin, es schwieriger zu machen, sich selbst zu erschießen
im Fuß.

Am So, 3. Juli 2016 um 11:24 Uhr, Thorsten Lünborg [email protected]
schrieb:

Event Busse sind kein Muster, das wir fördern wollen - es ist nur
nützlich einige Randfälle. Im Allgemeinen wird ein Speichermuster wie vuex bevorzugt.

Implementierung einer API, die die Nutzung eines Busses erleichtert und sich "offiziell" anfühlt
unterstützt" wäre das falsche Signal.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/2873#issuecomment -230158828 oder stumm
der Faden
https://github.com/notifications/unsubscribe/AACoukCpCgYlDbVej_w_h4NEhQ-imYHBks5qR9QwgaJpZM4IedHC
.

@kharysharpe $emit s sollen mit v-on auf der untergeordneten Instanz abgehört werden. Dies hat auch den zusätzlichen Vorteil, dass Sie auf den ursprünglichen Kontext der Verwendung der Instanz zugreifen können:

<list-item v-for="(item, index) in items"
  :title="item.title"
  @remove="items.splice(index, 1)"
>
</list-item>

Gibt es ein Datum für den Release 2.0? Ich bin ziemlich gespannt auf die Veränderungen. Glückwunsch!
Ich überlege, Vue 2.0 + Redux zu verwenden.

@Sendoushi Noch kein Datum für die endgültige Veröffentlichung, aber die Beta kann innerhalb einer Woche erscheinen. 😄 Vuex 2.0 wird auch parallel entwickelt und wird nicht nur eine viel einfachere API als aktuelles vuex bieten, sondern sich auch viel besser in das Vue-Ökosystem integrieren als Redux.

Parallel dazu wird auch Vuex 2.0 entwickelt, das nicht nur eine viel einfachere API als das aktuelle vuex bietet, sondern sich auch viel besser in das Vue-Ökosystem integrieren lässt als Redux.

@chrisvfritz Das ist fantastisch zu hören! Ich hatte immer das Gefühl, dass die aktuelle API etwas übertrieben und unnötig kompliziert ist. Am Ende musste ich Dinge wie diese tun, um dies zu kompensieren:

const mutations = {
  LOGIN (state) { state.loggedIn = true },
  LOGOUT (state) { state.loggedIn = false }
}

export const types = Object.keys(mutations)

// For now we dynamically generate all the actions like this.
// It's rare when anything more complicated is needed, but there
// is an example here:
// http://vuex.vuejs.org/en/actions.html
export const actions = types.reduce((o, el) => {
  var action = S(el.toLowerCase()).camelize().s
  o[action] = ({dispatch}, ...args) => dispatch(el, ...args)
  return o
}, {})

Wie sieht es mit der Roadmap von vue 2 und vuex 2 aus. Ist geplant, sie zusammen oder nacheinander zu veröffentlichen und wie sieht es mit der Kompatibilität der verschiedenen Versionen aus?

In Bezug auf die obige Frage, wie ist der Status beim Vue-Router - wird er bald Vue 2-Unterstützung erhalten oder müssen Vue 2-Tests ohne den Router durchgeführt werden?

@gwildu Sie werden wahrscheinlich etwas zusammen veröffentlicht und Vuex 2.0 wird nur Vue 2.0 unterstützen. Vuex vor Version 2.0 wird weiterhin unterstützt, bis Vue 1.x nicht mehr unterstützt wird.

@Uninen Vue Router wird als nächstes, vor der Veröffentlichung von Vue 2.0, etwas Liebe erhalten.

Danke für die Info @chrisvfritz :)

@chrisvfritz @Uninen Korrektur: Vuex 2.0 funktioniert auch für Vue 1.x.

Die nächste Hauptversion von vue-router wird nur Vue 2.x unterstützen.

Nur Runtime-Build: Da der Compiler nicht enthalten ist, müssen Sie entweder Vorlagen in einem Kompilierungsschritt vorkompilieren oder manuell geschriebene Renderfunktionen erstellen.

Gibt / wird es eine Möglichkeit geben, Vorlagen vorzukompilieren, ohne vueify/vue-loader und .vue Dateien zu verwenden? Wenn nicht, wäre es eine gute Idee, ein Babel-Plugin zu haben, um template: Eigenschaften in render Funktionen in Komponenten umzuwandeln?

Können die veralteten Funktionen nach dem Upgrade auf 2.0 weiterhin verwendet werden. Können Sie zuerst auf 2.0 aktualisieren und dann die veralteten Funktionen langsam ändern?

Wird es möglich sein, eine Terminalkomponente zu erstellen, nachdem elementDirective weg ist?

Wie gesagt:

v-model kümmert sich nicht mehr um den anfänglichen Inline-Wert. Die Vue-Instanzdaten werden immer als Quelle der Wahrheit behandelt.

Berücksichtige das

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value" />
  <label :for="_uid"><slot></slot></label>
</child-component>

Wie kann ich mit Kontrollkästchen mit Arrays zwischen benutzerdefinierten Komponenten umgehen?

_Aktualisiert 1:_
Gelöst. Übertragen Sie prop type="checkbox" an die untergeordnete Komponente in der übergeordneten Komponente.

<parent-component>
  <child-component type="checkbox" v-model="parentModel" value="apple"  />
  <child-component type="checkbox" v-model="parentModel" value="orange" />
  <child-component type="checkbox" v-model="parentModel" value="banana" />
</parent-component>

Dann können Sie den Inline-Wert über {props: [ 'value' ]} .
Geben Sie ein change Ereignis an die übergeordnete Komponente aus, um mitzuteilen, dass sich der Wert geändert hat.

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value"
    @change="$emit('change', $event)"
  />
  <label :for="_uid"><slot></slot></label>
</child-component>

Dies liegt daran, dass der Compiler die v-model -Direktive gemäß ihrer type kompiliert. Und der Compiler generiert die checked Requisite und bindet ein change Ereignis daran.

_Aktualisiert 2:_
Der updated Lebenszyklus-Hook wird jedoch nicht ausgelöst, da v-model das checked Attribut direkt ändert (das bedeutet, dass Sie kein change Ereignis erhalten können einer nativen HTML-Checkbox-Komponente, indem Sie den Wert von v-model ).
Also, @yyx990803 , können Sie ein change Ereignis auslösen, nachdem sich v-model geändert hat?

@YunSun-CN Die einzige Möglichkeit, Ihr Problem zu umgehen, bestand darin, eine für den Wert spezifische Eigenschaft ala val hinzuzufügen und damit den tatsächlichen Wert festzulegen und dann einfach Änderungen an der Eingabe des V-Modells auszugeben ' Veranstaltung.

@johnleider Ich habe eine benutzerdefinierte Anweisung geschrieben, um zu simulieren, was v-model tut.
Übrigens, Sie sollten Modelle auf strikte Weise generieren und nicht nur type prop prüfen, sondern auch den tagNamen des Elements prüfen. Andernfalls kann eine andere benutzerdefinierte Komponente mit type prop ihr Standardmodellverhalten überschreiben.

Hallo. Kennen wir ein Release-Datum?

@thanosalexander Wir haben uns noch nicht für einen Termin entschieden, nein. Wir haben gerade mit 2.0.0-bet.2 einige wichtige Änderungen am Transition-System eingeführt, die gründlich getestet werden müssen. Es wird also meiner Meinung nach noch ein paar Wochen dauern, bis wir über eine Veröffentlichung nachdenken können.

ok..ich mach das dann ..ich denke der Schritt zum Stall wird nicht zu groß sein! Danke schön

Was ist mit den Dokumenten? Einer der Gründe, warum Vue frühzeitig übernommen wurde, war die Dokumentation und es ist der einzige Grund, warum ich jetzt mit v2 zurückgehalten werde. Ich habe das Problem bei der Nachverfolgung von Dokumenten gesehen, sehe aber nicht, dass es bald fertig wird. Wahrscheinlich ignoriere ich so viel, was unter der Haube passiert, Grund warum die Frage gestellt wird :)

Gibt es Pläne, den Übergangsmodus außerhalb des Komponentenwechsels in 2.0 zu implementieren?
https://github.com/vuejs/Discussion/issues/156

@miljan-aleksic Docs wird fertig sein, wenn 2.0 offiziell veröffentlicht wird. Wir sind noch in der Beta-Phase. ;)

Bis dahin können Sie den Fortschritt auf Dokumentation folgen hier (oder sogar beitragen)

@aristidesfl Schon fertig. 🎉

@miljan-aleksic Zusätzlich zu dem, was @LinusBorg erwähnt hat, ist der Großteil des neuen Handbuchs bereits vollständig und Sie können hier sogar die Quelle lesen, wenn Sie möchten. Beachten Sie jedoch , dass es zum Betaversion zu berücksichtigen.2 , bedeutende Peer-Reviews stehen noch aus und es gibt einige andere kleinere API-Änderungen, die in Erwägung gezogen werden. Wenn Sie also nicht helfen möchten, Tippfehler zu beheben und Erklärungen zu verbessern, würde ich empfehlen, zu warten, bis wir offiziell veröffentlichen (vielleicht in der RC-Phase).

Wir sind uns auch einig, dass die hervorragende Dokumentation ein wesentlicher Bestandteil von Vue ist. Sogar Dan Abramov vom React-Team liebt unsere Dokumente. 😄 Deshalb ist es eines meiner persönlichen Ziele, dass die 2.0 Docs _noch besser_ werden. Inzwischen aber...

Für alle, die sich frühzeitig mit 2.0 vertraut machen möchten, empfehle ich die Feature-Unit-Tests als aktuellste verfügbare Ressource.

Dies ist eine meiner wichtigsten Ressourcen beim Schreiben von Dokumentationen, und sie sind im Allgemeinen gut lesbar, wenn Sie mit Jasmine vertraut sind.

Danke @chrisvfritz , sehr nützliche Informationen. Ich werde den neuen Dokumenten eine Chance geben, unter Berücksichtigung der WIP und bei Bedarf Feedback. Es ist Zeit, ernsthaft mit Vue 2.0 zu beginnen ;)

createElement in der Render-Funktion, die on verwendet, scheint keine Arrays zu verarbeiten (wie es snabbdom tut). Gibt es eine Möglichkeit, Daten an die aufgerufenen Funktionen zu übergeben?

Zum Beispiel in Snabbdom kann ich verwenden

{on:{click: [function, dataToPass]}}

Und function erhält dataToPass als erstes Argument. Aber dies scheint in vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function fehlerhaft zu sein. Gibt es eine Möglichkeit, Daten und das Ereignis mit dem Element on from create zu übergeben?

@dubcanada die Ereignisbehandlung in Vue 2.0 unterscheidet sich von der von snabbdom - Sie müssen die Funktion selbst einrichten. Die Array-Syntax fügt einfach mehrere Handler an dasselbe Ereignis an.

Ich versuche, den Inhalt der Slots als String zu erhalten, anstatt sie zu rendern. Bei Standardknoten gibt es einen einfachen Workaround, aber bei Vnodes habe ich keinen Weg gefunden. Gibt es dafür einen Workaround?

@miljan-aleksic Versuchen Sie es zu rendern, rufen Sie den Inhalt des Elements mit innerHTML und verstecken Sie das Element dann mit display: none in CSS.

Danke für die Hilfe. Wenn ich es rendere, würde die endgültige Ausgabe anders aussehen. Ich erstelle eine Komponente, die ihren untergeordneten Inhalt mit einem pre Tag umschließt und den HTML-Code codiert.

Rendern Sie in diesem Fall die Ausgabe in einem anderen Element als das Original.

Ich möchte jedoch darauf hinweisen, dass Templating nicht Ihre Art sein sollte, Ihren Inhalt zu schreiben. Es sollte die Art sein, zu beschreiben, _wie_ der Inhalt geschrieben wird, und nicht der Inhalt selbst. Ich würde empfehlen, den Text als String in JS zu speichern (oder als Ressource an anderer Stelle in Ihrem Projekt, _besonders_ wenn es sich um eine Benutzereingabe handelt) und ihn dann als Requisite an das Kind weiterzugeben, was die Dinge tausendmal machen sollte sowieso einfacher.

Du hast recht @Kingdaro , das Beste ist, Konzepte nicht zu vermischen und es einfach zu halten. Es war jedoch schön, die Syntax hochglänzend zu haben :)

Bei Verwendung der v-on Direktive ist die Variable $arguments nicht mehr verfügbar. Ich sehe hier keinen Hinweis auf diese Änderung. Ist ein Fehler oder eine fehlende Referenz?

@ miljan-aleksic verwenden Sie einfach arguments .

Muss ein PHP-Entwickler sein (wie ich) ... Ich weiß, wie Sie sich fühlen. LOL!

Scott

@yyx990803 , @smolinari Ich bin ... und jetzt ein verlegener, haha. Ich habe mir selbst eingeredet, dass ich das schon versucht habe... anscheinend ist es mir nicht gut genug gelungen. Es funktioniert, danke und entschuldige, dass du deine Zeit verschwendest.

Ich wollte gerade ein Ticket zu einem anderen "Problem" eröffnen, bin mir aber nicht mehr sicher, ob es das ist... Bei Verwendung von ref die registrierte Komponente oder das registrierte Element nicht sofort verfügbar, daher würde so etwas nicht funktionieren.

<button ref="button"...></button>
<foo :connect="$refs.button"></foo>

Zur Zeit, in der Foo gerendert wird, ist $refs.button noch undefiniert. In Vue 1 funktioniert wie erwartet. Was fehlt mir diesmal?

Sie vermissen, dass Sie keine DOM-Elemente oder Komponenteninstanzen als Requisiten übergeben sollten...

Warum ist das eine schlechte Idee? Nehmen wir an, ich habe eine Dropdown-Komponente, die ich mit einem Button (dem Auslöser) verbinden möchte. Beide sind unabhängige Komponenten und anstatt sie durch eine Abfrage zu verbinden, übergebe ich die Referenz direkt.

@miljan-aleksic es ist noch besser, sie über den Zustand zu verbinden:

• Der geöffnete/geschlossene Zustand wird in ihrem gemeinsamen Elternteil beibehalten
• die Eltern übergeben den Zustand als Requisite an das Dropdown-Menü
• die Eltern hören auf das Ereignis der Schaltfläche, um den Status umzuschalten

Auf diese Weise sind Dropdown und Schaltfläche vollständig entkoppelt, die Schaltfläche kann wiederverwendet werden, um andere Arten von Komponenten zu steuern, und die Dropdown-Liste kann von anderen Arten von Eingabekomponenten gesteuert werden.

Es ist nicht einfach, alte Gewohnheiten loszuwerden. Soll ich jQuery die Schuld geben oder hauptsächlich mich? :D

Ihr Ansatz, Evan, ist richtig. Ich werde diesen Weg gehen, auch wenn dies bedeutet, dass die Dropdown-Integration mühsamer wäre. Da die übergeordnete Komponente wissen müsste, wie die verschiedenen Ereignisse zu hören sind, nicht nur das Öffnen, sondern auch das Schließen des Dropdown-Menüs, wenn von außen geklickt wird, aber nicht das Dropdown-Menü selbst usw. Viele Ereignisse und Problemumgehungen, die das Dropdown-Menü löste.

Da die übergeordnete Komponente wissen müsste, wie die verschiedenen Ereignisse zu hören sind, nicht nur das Öffnen, sondern auch das Schließen des Dropdown-Menüs, wenn von außen geklickt wird, aber nicht das Dropdown-Menü selbst usw. Viele Ereignisse und Problemumgehungen, die das Dropdown-Menü löste.

Kann es noch? Sie können addEventListener('body', ... ) von der Dropdown-Komponente aus ausführen, um externe Klicks usw. zu registrieren.

Yep Yep. Zeit, einige Komponenten zu überarbeiten :) Vielen Dank an alle! Tolle Gemeinschaft.

Wie wendet man v-model auf eine Komponente mit createElement ? Ich habe mir den generierten Code mit dem Template-Compiler angeschaut und ... es ist viel Code. Ich habe die dortige Dokumentation über Direktiven nicht ganz verstanden.

Standardmäßig extrahiert eine Direktive zur Kompilierzeit die Direktive und die Direktive ist zur Laufzeit nicht vorhanden. Wenn die Direktive auch von einer Laufzeitdefinition behandelt werden soll, geben Sie in der Transformationsfunktion true zurück.

@blocka Sie haben keinen Zugriff auf eingebaute Direktiven, wenn Sie die Funktion render verwenden. Sie müssen die entsprechende Logik selbst handhaben. Zum Beispiel ist v-if nur ein ternärer Ausdruck, v-for ist ein array.map() Ausdruck... und v-model (auf einem normalen <input> Element ) wird in eine value Bindung und einen input Ereignis-Listener übersetzt.

@yyx990803 das habe ich mir gedacht. Ich werde das wahrscheinlich mit einem HOC handhaben (ich übergebe bereits Bedingungen auf die gleiche Weise (obwohl ich darüber nachdenke, dies zu verwenden ).

Bei vue 1 gab es zwei erklärte Vorteile von vuex gegenüber redux.

1. Die Leistung ist besser, da vuex den Zustand mutiert, was am besten mit vue funktioniert (das Ersetzen des alten Zustands hatte eine Leistung, die einer "schmutzigen Überprüfung" entspricht).
2. Vuex ist sich "bewusster", dass es sich um eine Vue-Anwendung handelt

Reduziert die Verwendung des virtuellen Doms einige oder alle von 1?

@blocka es mildert einiges davon, aber die Gesamtleistung wird immer noch viel besser sein als bei Redux.

Was sich in 2.0 geändert hat, ist die Granularität der Reaktivität. Machen wir einen Vergleich:

• In Vue 1.x ist die Reaktivität sehr feinkörnig. Jede Direktive und jede Textbindung hat einen entsprechenden Watcher. Dies führt zu fein abgestuften Aktualisierungen, wenn sich Daten ändern, jedoch auf Kosten eines höheren Overheads für die Abhängigkeitsverfolgung beim anfänglichen Rendern und einer etwas höheren Speicherauslastung.
• Bei Redux hat die Reaktivität keinerlei Granularität. Wenn sich etwas ändert, muss die gesamte App neu gerendert werden. In React führt die Redux-Bindung einige Optimierungen an verbundenen Containern durch, aber der Benutzer muss noch umfassend shouldComponentUpdate implementieren, um eine bessere Leistung zu erzielen.
• In Vue 2.0 hat die Reaktivität eine mittlere Granularität. Jede Komponente verfügt über einen entsprechenden Watcher, der die Abhängigkeiten dieser Komponente verfolgt. Wenn sich Daten ändern, müssen nur Komponenten, die von der Änderung abhängig sind, ihr virtuelles DOM neu rendern. Dies ist im Wesentlichen das beste Szenario für React, aber Sie müssen in Vue 2.0 nichts tun, um dies zu erreichen.

Im Allgemeinen sehen Sie mit 2.0 (im Vergleich zu 1.x)

• etwas langsamere (aber immer noch sehr schnelle) Updates für kleine Datenänderungen
• Anständig schnellere Updates für mittlere bis große Datenänderungen
• deutlich schnelleres anfängliches Rendern

Hallo,
Übergänge mit animierter.css funktionieren nicht.

<transition enterClass="fadeIn" leaveClass="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

Hat jemand eine Idee?

Ihre Requisitennamen sind falsch.

camelCase vs kebap-case gilt auch in 2.0.

<transition enter-class="fadeIn" leave-class="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

@LinusBorg Tut mir leid, das habe ich schon versucht. Hier habe ich eine kleine Geige. Mit CSS-Übergängen und dem Namensschild funktioniert es gut.
https://jsfiddle.net/z0nyfba0/

Wenn v-model für eine Komponente verwendet wird, hat die Komponente dann Sichtbarkeit für alle Modifikatoren, die mit v-model ?

zB wenn ich eine Komponente habe, die ein input Ereignis ausgibt, hängt es davon ab, wann dieses Ereignis ausgegeben wird, ob der lazy Modifizierer verwendet wird oder nicht.

@fergaldoyle Ich habe ein wenig damit gespielt und ich denke, Sie können keine V-Modell-Modifikatoren für benutzerdefinierte Elemente verwenden, da Sie das Eingabeereignis manuell ausgeben müssen. Wenn Sie faules Verhalten erreichen möchten, müssen Sie das Ereignis change an die Eingabe binden, z. B. https://jsfiddle.net/cynhtLty/1/

@calebboyd

https://jsfiddle.net/Linusborg/z0nyfba0/1/

1. Sie müssen enter-active-class und leave-active-class
2. Sie müssen class="animated" auf das Element <router-view> .

@fergaldoyle Gemäß den 1.0-Dokumenten denke ich, dass das V-Modell mit lazy nur auf change anstelle von input reagieren würde. Sie können dies verwenden, um das Verhalten zu ändern, und input oder change ausgeben, um unterschiedliche Ergebnisse zu erhalten, je nachdem, ob lazy angegeben ist oder nicht.

Ich habe mir beim Herumspielen mit einem einfachen v-for Beispiel am Kopf gekratzt. Aus irgendeinem Grund funktioniert die value Bindung nicht für select Elemente in 2.0: https://jsfiddle.net/972eL5fL/

Außerdem sollte in den Dokumenten wahrscheinlich beachtet werden, dass v-for-Bereiche wie "i in 10" bei 1 beginnen statt bei 0 wie in 1.0.

@lauritzen

Ich habe mir zum Beispiel am Kopf gekratzt, während ich mit einem einfachen V herumgespielt habe. Aus irgendeinem Grund funktioniert die Wertbindung für ausgewählte Elemente in 2.0 nicht: https://jsfiddle.net/972eL5fL/

Bei mir scheint es wie erwartet zu funktionieren, was funktioniert bei dir nicht?

Mitteilung des öffentlichen Dienstes

Wir empfehlen Ihnen, Support-Fragen im Forum oder auf gitter zu stellen .

Dieses Problem sollte Diskussionen über die neue API vorbehalten bleiben. Wenn wir hier den Support für diverse Fragen übernehmen, läuft dieser aus dem Ruder.

Danke schön.

Warum ist vm.$get veraltet?
Warum nicht stattdessen Vue.get?
Es ist sehr nützlich, um berechnete Ausdrücke wie diese auszuwerten
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

@iagafonov Es gibt nicht viele Szenarien, in denen dies nützlich ist, daher sollte es nicht Teil des Kerns sein.

Wenn Sie die Funktionalität für eines der wenigen Szenarien benötigen, können Sie mit Hilfe von zB lodash ganz einfach ein ähnliches Verhalten hinzufügen:

import get from 'lodash/get';
Vue.prototype.$get = get

//in any component
var value = this.$get(this.someObject,'some.path.to.value')

(Natürlich können Sie es auch als "Klassenmethode" als Vue.get() hinzufügen - oder einfach lokal importieren, wo Sie es brauchen - Ihrer Wahl)

@LinusBorg. Zunächst einmal verwende ich kein Lodash oder ähnliches.
Zweitens ist die Lodash-Implementierung langsam, da sie während der Laufzeit versucht, tief in die Ausdrucksstruktur einzudringen. vue entspricht der neuen angegebenen Funktion (von parseExpression), die an den Geltungsbereich gebunden ist.
Es ist kein trivialer Teil, es ist sehr schwierig, dies wieder zu implementieren.
Natürlich $get Kompilierungsfunktion jedes Mal ). Wäre schön, wenn parseExpression zum Beispiel Teil der API in Vue.util ist.

@iagafonov this.$get auch den Pfad zur Laufzeit analysieren und den Wert dynamisch abrufen. Andernfalls erhalten Sie eine Fehlermeldung, wenn der Pfad nicht existiert. Auch der Leistungsunterschied wird in den meisten Fällen vernachlässigbar sein. Wenn Sie Lodash nicht wollen, gibt es viele andere Bibliotheken zum Abrufen von Pfaden. Es ist einfach nicht mehr Teil von Vues Anliegen.

Welche Alternativen gibt es zu den mittlerweile veralteten param-Attributen?

sprichst du von params in einer richtlinie? Dann können Sie alle gebundenen Attribute im vnode-Objekt finden

<button v-test="123" color="red" type="button">click me</button>

bind (el, binding, vnode) {
 // vnode.data.attrs -> { color: 'red' }
}

@sqal , ist das eine Antwort auf meine Frage? Wenn ja, spreche ich von Parameterattributen wie Lazy, Number und Debounce. Zum Beispiel konnte ich vor 2.0 dies <input type="text" v-model="msg" number> tun (Zahl ist hier ein Param-Attribut). Wie kann ich die gleichen Ergebnisse erzielen, ohne das param-Attribut zu verwenden?

@p-adams es wird im Beitrag erwähnt - sie sind jetzt Modifikatoren <input v-model.number="msg">

Ich finde in Vue 2.0, wenn sich die Requisiten ändern, wird die Render-Funktion immer aufgerufen, daher frage ich mich, ob 2.0 shouldComponentUpdate , um zu entscheiden, ob es erneut gerendert wird.

@yyx990803 Okay, ich sehe es jetzt im Beitrag The lazy and number params are now modifiers .

@HeChenTao Evan hat dies hier ein wenig erklärt https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

@HeChenTao Die Renderfunktion wird nicht "immer" aufgerufen, nur wenn es erforderlich ist:

• Vue benötigt wegen seiner Reaktivität kein shouldComponentUpdate .
• Wenn reaktive Daten, die in einer Komponente verwendet werden, geändert werden, löst dies die Render-Funktion, vdom Diffing usw. aus.
• Wenn sich jedoch keine dieser Daten ändert, ist keine Aktualisierung erforderlich und die Renderfunktion wird _nicht_ aufgerufen.

Das gleiche kann man in Reaction mit mobx machen. Ich bin mir ziemlich sicher, dass Sie shouldComponentUpdate nicht implementieren müssen. Wie vue besteht mobx jedoch auf einem veränderlichen Zustand. Wenn Sie sich aus irgendeinem Grund für das Konzept des unveränderlichen Zustands entschieden haben. Reagieren Sie in diesem Fall mit shouldComponentUpdate .

Bedeutet das, dass wenn jemand auf einem unveränderlichen Zustand besteht, vue nicht gut passt?

Das Kontextargument der Funktionskomponenten hat children plus slots . Ich finde es ein bisschen verwirrend zu wissen, dass children() und slots().default genau gleich sind. Ich frage mich, was der richtige Ansatz ist. Wahrscheinlich ist "Kinder" als Slots faul, aber warum sollte man trotzdem zwei verschiedene Wege unterstützen, um das gleiche Verhalten zu erreichen?

Funktionale Komponenten sind nur Funktionen und haben daher keine Kinder. IMHO, Kinder sollten veraltet sein und Slots einfach als nicht faul halten.

@blocka Sie können reaktive Daten in React mit mobx implementieren, wahr. Aber Reaktivität ist der Kern der Vue-Funktionalität. Wenn das also nicht so ist, ist diese Person auf der falschen Seite.

@miljan-aleksic children ist roh (Sie erhalten jeden Knoten, egal in welchen Slot sie gehen sollen), slots wird basierend auf slot Namen von eingehenden Kindern aufgelöst.

Danke @yyx990803. Vielleicht würden weitere Details dazu in den Dokumenten Verwirrung vermeiden, @chrisvfritz.

@ miljan-aleksic Ich füge eine Notiz hinzu. 👍

In Bezug auf Filter scheint die Verwendung einer berechneten Eigenschaft einfach genug zu sein, aber wie ist der Fall der Verwendung eines Filters mit einem V-Modell zu handhaben. Wenn man eine Namensliste durch Eingabe in das Eingabefeld filtern möchte, wie geht das in 2.0?

Denken Sie daran, Vue warnen zu lassen, wenn ein Datenfeld / eine berechnete Eigenschaft nicht in einer Vorlage verwendet wird? Ich kann mir vorstellen, dass es hier einige Einschränkungen gibt, aber es wäre sehr hilfreich zu wissen, wo ich es mir leisten könnte, einige nutzlose Ladenimporte herauszuziehen, wo sie nicht benötigt werden.

@yyx990803 , was halten Sie davon, den Verweis $context auf den Komponentenprototyp zu setzen? Das gleiche wie bei $parent oder $root Ich habe oft auf den Kontext zugegriffen, der derzeit nur über das $vnode Objekt verfügbar ist.

Tatsächlich scheint dies kein zuverlässiger Weg zu sein, um auf den Kontext zuzugreifen. Wie ist zu tun?

@miljan-aleksic Können Sie die Anwendungsfälle teilen, in denen Sie häufig auf den Kontext zugreifen?

@Kingdaro Kannst du dafür ein Problem eröffnen? Klingt gut, wenn es machbar ist.

@p-adams Sie können immer noch eine berechnete Eigenschaft mit Array.prototype.filter .

@chrisvfritz , im Grunde für Workarounds, um zum Beispiel Variablen in den Kontext zu setzen, den das Kind erwartet. Oder um einen Verweis auf die Komponente früher zu setzen, als Vue selbst tut.

Ich stimme zu, dass dies nicht allen gemeinsam ist, aber es sollte zumindest eine zuverlässige Möglichkeit geben, innerhalb der Komponente darauf zuzugreifen. Der $vnode ist erst vorhanden, wenn die Komponente bei der Verwendung von Vorlagen gemountet wird (zumindest mein bisheriges Fazit).

Ich würde mich zufrieden geben zu wissen, wie man auf die richtige Weise darauf zugreifen kann.

Eine andere Situation, in der $context nützlich wäre, ist die Wiederverwendung einer Komponente als Stamm einer anderen Komponente.

<template>
  <Foo>
    <child/>
  </Foo>
</template>
<script>
{ name: 'Bar' ... }
</script>

Im Beispiel würde child.$parent die Komponente Foo anstelle von Bar zurückgeben, was richtig ist, aber wenn Eltern und Kind voneinander abhängig sind, könnte eine direkte Kommunikation zwischen ihnen über den Kontext erfolgen.

@miljan-aleksic Das überlasse ich @yyx990803. Ich würde sagen, dass das Erreichen von $context genau wie bei $parent wahrscheinlich in 99,9% der Fälle der falsche Weg sein wird und ich denke, dass ich es wahrscheinlich nie verwenden würde.

Ich habe eine Situation mit v-show und Übergängen. In diesem Szenario gibt es ein Modal, das standardmäßig im CSS 'display: none' lautet. In Kombination mit v-show würde es nie angezeigt, da die Direktive die display-Eigenschaft entfernt, die CSS-Eigenschaften bleiben dann bestehen. Ich kann das CSS (Projektanforderungen) nicht ändern und ich kann keine benutzerdefinierte Anweisung verwenden, da Vue-Übergänge anscheinend speziell darauf angewiesen sind.

Ich denke jetzt, dass eine Direktive, die direkt nach v-show auswertet, die display-Eigenschaft auf block setzen könnte. Das muss man ausprobieren, aber trotzdem könnte es eine gute Idee sein, v-show einen Modifikator hinzuzufügen, damit die Anzeige auf Block oder Inline-Block eingestellt werden kann. Nur ein Gedanke.

@chrisvfritz , es wird erwartet, dass für funktionale Komponenten die übergeordnete Referenz nicht die unmittelbare übergeordnete Komponente ist, in der sie als Slots verwendet werden, sondern stattdessen die

Die Kompilierung der Vorlage schlägt fehl, wenn sie "<" (und möglicherweise andere html-sensitive Zeichen) in 2.0.0-beta7 enthält

https://jsfiddle.net/x0r59ur1/

Dies funktionierte in 1.0.26.

Das Escapezeichen von "<" mit "<" löst das Problem.

@GlurG Es wird erwartet, dass "<" richtig entkommt.

@yyx990803 , wenn ich Übergänge für eine Liste von Komponenten desselben Typs verwenden und ihren Zustand

Nehmen wir an, eine Tab-Komponente und deren Elemente übergehen. Ich finde keinen Weg :(

<tabs>
  <transition>
    <tabs-item>Content 1</tabs-item>
    <tabs-item>Content 2</tabs-item>
    <tabs-item>Content 3</tabs-item>
  <transition>
</tabs>

@miljan-aleksic <transition> ist nur für einzelne Elemente. Sie benötigen <transition-group> für mehrere Artikel.

@ yyx990803 , habe das auch versucht, sehe aber immer noch nicht, wie man es erreicht. Transition-Group funktioniert durch Hinzufügen/Entfernen von Elementen, aber dabei würden die Komponenten erneut initialisiert und verlieren den Zustand. Abgesehen davon, dass ein Tab nur eine Komponente gleichzeitig anzeigen soll, ist es nicht gerade eine Liste :)

@yyx990803 , @LinusBorg Ich schätze die Hilfe, aber die Lösung ist nicht offensichtlich. Ich weiß, wie die Übergänge angewendet werden, was ich nicht herausfinden kann, ist, wie man die geänderten Komponenten keep-alive kann.

Ich habe aus Gründen der Übersichtlichkeit ein neues Problem mit einem jsfiddle-Beispiel erstellt, wie die Komponenten jedes Mal erstellt werden.

@yyx990803 , vielen Dank für die Verbesserung der Keep-Alive-Funktion, jetzt funktioniert sie wie erwartet.

Sie verändern buchstäblich mein Leben, mit Ihren Produkten und Ihrer Arbeitsmoral bin ich in der Lage, Produkte zu lernen, zu bauen und zu liefern, die ich lange Zeit in Bereitschaft hatte. Mit Ihrem „Keep it simple“-Ansatz steht Hightech jedem zur Verfügung, der genutzt und darauf aufgebaut werden kann. Für all das und mehr bin ich ewig dankbar.

@ Miljan-Aleksic Es gibt eine Patreon Kampagne wink wink.

Weißt du was @phanan , du hast vollkommen recht. Ich habe angefangen, Evan persönlich zu unterstützen, und sobald die Produkte des Unternehmens Ergebnisse zeigen, wird die Unterstützung spürbarer.

Der Lebenszyklus-Hook ready wird zugunsten von mounted ; aber laut Changelog gibt es keine Garantie, dass die Komponente gerendert wird, bevor mount aufgerufen wird. Dies führt zu sporadischen Fehlern, wenn ich bestimmte jquery-Komponenten (wie selectize) initialisieren möchte, nachdem die Komponente initialisiert wurde. Welchen Lifecycle-Hook sollte ich stattdessen verwenden? Kann der "bereite" Hook wie folgt emuliert werden:

function mounted() {
  Vue.nextTick(() => {
    //...
  });
}

@GlurG Ja, das wird funktionieren. Und das war übrigens bei ready'() in 1.0 in vielen Fällen auch nöthig.

Gibt es einen Grund, warum es trotzdem keinen Hook dafür geben kann? ich habe auch
darüber hinweg ... sogar in 1.0, und auf Dinge wie Looping mit raf to zurückgegriffen
Überprüfen Sie, ob es im Dom usw.
Am 10.08.2016, 18:26 Uhr, "Thorsten Lünborg" [email protected]
schrieb:

@GlurG https://github.com/GlurG Ja, das wird funktionieren. Und nebenbei,
das war bei ready'() in 1.0 in vielen Fällen auch nötig.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/2873#issuecomment -238903012 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AACounAoI8p65soUUrbdaiwteDXKgMGJks5qee25gaJpZM4IedHC
.

Bei der Verwendung der Renderfunktionen werden die Kerndirektiven ignoriert, was sinnvoll ist. Aber einige sind mit einfachem js nicht so einfach zu reproduzieren, wie das v-model das Workarounds für IE9 bietet und wahrscheinlich andere Randprobleme löst.

Es lässt Sie überdenken, stattdessen eine Vorlage zu verwenden, aber das ist in einigen Situationen nicht möglich oder die beste Option. Die Dokumentation könnte definitiv mehr Anleitungen zu diesem Thema bieten und außerdem könnte es eine gute Idee sein, einige Helfer bei der Arbeit mit Renderfunktionen zu haben, die helfen würden, diese häufigen Situationen zu lösen und niemandem eine Vorlage entgehen lassen.

@miljan-aleksic Entschuldigung, ich habe meinen Kommentar gelöscht, weil ich bemerkt habe, dass er nur für V-Show oder benutzerdefinierte Direktiven funktioniert, und ja, wie Sie im Falle des V-Modells sagten, ist es erforderlich, Eingabe-/Änderungslistener hinzuzufügen und unsere Daten manuell zu aktualisieren

soll der neue activated Hook aufgerufen werden, wenn eine Route gefeuert wird, die ein router-view aktiviert/mountet? Ich sehe dieses Verhalten derzeit nicht.

@wprater nein, es bezieht sich ausschließlich auf <keep-alive> und sonst nichts.

@ yyx990803 Ich verpacke meine Router-Ansicht in ein Keep-Alive, aber ich scheine keinen Haken zu finden, wenn ich zur vorherigen Ansicht zurückkehre. mounted noch activated werden aufgerufen. Ich muss sicher sein, dass der Dom gerendert wird.

@wprater Bitte vermeiden Sie es, diesen Thread für nicht verwandte Fragen zu verwenden. Wenn ein Fehler auftritt, Dateiproblem im entsprechenden Repository mit Reproduktion.

Unterstützt Vue JSX den Object Spread Operator? Ich habe es probiert aber es funktioniert nicht.

Es tut es und @yyx990803 hat sich viel Mühe gegeben, damit es funktioniert.

Ich mache das <Component {...{ props } }></Component> und es funktioniert wie dokumentiert.

@blocka Danke! Ich dachte, der Eigenschaftsname props nicht erforderlich 😂

@yyx990803
components Optionen unterstützen keinen Array-Typ, aber es funktioniert in 1.x.

z.B

var Parent = Vue.extend({
  name: 'parent',
  template: '<div><slot></slot></div>'
})

var Child = Vue.extend({
  name: 'child',
  template: '<span>hello</span>'
})

new Vue({
  el: '#app',

  components: [
    Parent,
    Child
  ],

  replace: false,

  template: '<parent><child></child></parent>'
})

Es ist ein Fehler?

@QingWei-Li Sie werden einfach nicht mehr unterstützt, da es nie eine offiziell dokumentierte Funktion war. Der Grund dafür ist, dass Sie mit ES2015 einfach components: { Parent, Child } schreiben können.

nur ein kleiner vorschlag,
Gibt es eine Chance für die normale Array-Iteration verwenden wir v-foreach und für den Bereich verwenden wir v-for .

was für Benutzer, die von PHP kommen, sinnvoller ist und sogar mit .each in JQ oder foreach in JS übereinstimmt

@ctf0 Wir befinden uns im RC-Stadium, die API wird sich nicht mehr ändern. Und wir werden auch keine alternative Syntax einführen, um dasselbe zu tun.

Ich glaube nicht, dass der mentale Overhead von v-for="item in items" signifikant genug ist, um dies zu rechtfertigen.

Mit dieser neuen Version würde ich diesen Fall behandeln.

Ich habe eine Kalenderkomponente (von semantic ui), die eine klassische Texteingabe verwendet und das Datum in einem menschlichen Format anzeigt (wie zum Beispiel "10. Juli 2016"). Mit v1.0 habe ich einen Zwei-Wege-Filter verwendet, um diese Zeichenfolge in ein richtiges Datum zu konvertieren, sodass meine Objektdaten direkt zum Senden bereit waren. Aber da Filter im v-Modell nicht mehr funktionieren, wie könnte ich das gleiche jetzt in v2.0 tun?

Danke

@shadowRR wäre es möglich, Code zu sehen?

@p-adams Klar. Bitte schön.

Zuerst mein Filter, der auf meinem V-Modell für meine Kalendereingabe verwendet wird. Sein einziger Zweck besteht darin, bei einer Wertänderung einen richtigen Datumstyp in meine Daten zu schreiben (Postgres-Datum).

Vue.filter( 'formatDate', {
        read( date ) {
            return date;
        },
        write( date ) {
            if( !date ) return null;
            return moment( date, 'D MMMM YYYY' ).format( 'YYYY-MM-DD' );
        }
    } );

Und ich würde es so für meine Komponente verwenden (die Eingabe hat ein Kalendersystem, das mein Datum im menschenlesbaren Format zurückgibt)

<div class="required field">
        <label>Start date</label>
         <div class="ui calendar">
                 <div class="ui input left icon">
                      <i class="calendar icon"></i>
                      <input v-model="section.start | formatDate" type="text">
                 </div>
         </div>
</div>

Ich würde empfehlen, den Beitrag von @yyx990803 hier zu lesen: https://github.com/vuejs/vue/issues/2756, wo er Zwei-Wege-Filter auf v-model diskutiert. Außerdem ist es möglicherweise besser, Fragen wie diese hier zu stellen: http://forum.vuejs.org/

Ich habe den Beitrag verpasst, von dem du sprichst, werde das sehen, danke ;)

Hallo,
Ich habe einige Zweifel an neuen Lifecycle-Hooks.
Wenn ich einen Ereignishandler beim Mounten registrieren und ihn vor dem Unmounten aufheben möchte, wie soll ich ihn zum Laufen bringen? Fügen Sie Prüfungen und Logiken in erstellten und vorher erstellten Hooks hinzu.
In Vue 1.x würde ich angehängte und abgenommene Haken verwenden.
Aber in 2.0 gibt es einen Mount-Hook, aber keinen Unmount-Hook. Fühlt sich etwas nicht korrespondierend an.
Gibt es einen Grund, warum kein Unmount-Haken bereitgestellt wird?

@f15gdsy mounted entspricht destroyed . Es gibt keine attached / detatched Gegenstücke in 2.0 - Sie müssen die In-Dom-Prüfung selbst durchführen. Wenn es bei Ihren Events nicht um In-Dom/Off-Dom geht, dann sind mounted und beforeDestroy die geeigneten Orte dafür.

Bei Verwendung auf einer benutzerdefinierten Komponente lauscht v-on jetzt nur auf benutzerdefinierte Ereignisse $, die von dieser Komponente ausgegeben werden. (hört nicht mehr auf DOM-Ereignisse)

Ich habe hier vielleicht ein paar Beiträge übersehen, aber was ist die Designentscheidung dahinter?
Es würde das Binden einfacher Klickereignisse an Komponenten sehr ausführlich machen.

1.0:

<foo @click="bar"></foo>

2.0:

<div @click=bar>
  <foo></foo>
<div>

@fnlctrl , verwende den nativen Modifikator: @click.native="bar" .

@miljan-aleksic Vielen Dank! Ich denke, dieser Modifikator sollte in dieser Ausgabe zu Directives -> v-on -> modifiers hinzugefügt werden

Könnte ich Koa (1.x oder 2.x) als Server verwenden? Gibt es ein Problem bei vue-server-renderer mit Koa?

@yyx990803

import Vue from 'vue'

Vue.component('expanding', {
  functional: true,
  render (createElement, { children }) {
    const data = {
      props: {
        name: 'expanding',
      },
      on: {
        beforeEnter ($el) {
          $el.classList.add('collapse')
          console.log('beforeEnter')
        },
        enter ($el) {
          $el.classList.remove('collapse')
          $el.classList.add('collapsing')
          $el.style.height = `${$el.scrollHeight}px`
          console.log('enter')
        },
        afterEnter ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse', 'in')
          console.log('afterEnter')
        },
        beforeLeave ($el) {
          $el.classList.add('collapsing')
          $el.classList.remove('collapse', 'in')
          $el.style.height = 0
          console.log('beforeLeave')
        },
        leave ($el) {
          console.log('leave')
        },
        afterLeave ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse')
          $el.style.display = 'none'
          console.log('afterLeave')
        }
      }
    }
    return createElement('transition', data, children)
  }
})

        <a href="#" :aria-expanded="showItem ? 'true' : 'false'" @click="showItem = !showItem">
          <span class="icon is-small"><i class="fa fa-table"></i></span>
          Tables
          <span class="icon is-small is-angle"><i class="fa fa-angle-down"></i></span>
        </a>
        <expanding appear="true">
          <ul v-show="showItem">
            <li>
              <router-link to="/tables/basic">Basic</router-link>
            </li>
            <li>
              <router-link to="/tables/handsontable">Handsontable</router-link>
            </li>
          </ul>
        </expanding>

Warum nicht den Enter-Hook aufrufen?

@fundon Du solltest die Frage in den Foren oder im Gitter-Chat stellen

Sperre diesen Thread, weil:

1. Wir befinden uns jetzt im API-Freeze in RC, daher wird dieses Dokument nicht mehr aktualisiert.
2. Zu viele Leute verwenden dies als allgemeinen FAQ-Thread, wofür er nicht gedacht ist.

Wenn Sie einen Fehler haben, öffnen Sie bitte ein separates Problem gemäß dem Leitfaden zur Fehlerberichterstellung. Wenn Sie eine Frage haben, verwenden Sie bitte das Forum oder gitter.

Update : Eine definitivere und detailliertere Liste der Änderungen in 2.0 finden Sie im neuen Migrationsleitfaden .