Vue: [Vorschlag] Vue 2.0 - Filter bitte zurückbringen

Klarstellung eines Punktes, der ursprünglich aus dem Gitter-Chat kam: debounce ist kein Filter und war nur eine weitere der 2.0-Änderungen, über deren Verlust die Leute nicht begeistert waren.

Korrektur mit freundlicher Genehmigung von @JosephSilber : debounce ist sowohl ein Filter als auch ein v-model -Parameter.

Danke @agc93. Ich habe diesen Punkt entfernt.

Scott

Im schlimmsten Fall werden wir uns kleine Plugins einfallen lassen, um damit fertig zu werden. Über Filter gibt es https://www.npmjs.com/package/babel-plugin-pipe-operator
Das Problem ist, dass dies ohne babel-Kompilierung nicht funktioniert

Ich bin auch nicht allzu begeistert von einigen der Änderungen. Für Filter scheint es eine einfache Alternative zu geben, indem man globale Mixins registriert. Ich bin jedoch nicht sehr angetan von der Idee, alle Methodenbereiche meiner Komponenten für ultraeinfache Aufgaben wie Pluralisieren und so weiter zu verschmutzen. Ich habe jedoch noch nie Zwei-Wege-Filter verwendet.

Filter waren einfach praktisch und schön. Die beiden Dinge, die vue (bisher) immer richtig gemacht hat.

Als ich den Beitrag zu vue 2.0 las, war ich begeistert von all den neuen Möglichkeiten (insbesondere dem virtuellen Dom und dem Server-Rendering), aber ich war auch überrascht und ein wenig traurig darüber, dass die Filter weg sind.

Sie waren einer meiner Lieblingsteile von vue, nicht nur, weil sie einfach zu verwenden und zu verketten waren, sondern vor allem, weil sie leicht erweiterbar waren und eine schöne Syntax hatten, um sie direkt in der Vorlage zu verwenden. Besonders in Kombination mit v-for Loops passten sie perfekt zusammen.

Da ich denke, dass ich berechnete Eigenschaften verwenden muss, um die Filterung für jede einzelne Requisite zu ersetzen, mache ich mir Sorgen, dass ich in Zukunft viele Boilerplates schreiben werde. Während Mixins einen Teil des Problems mildern könnten, habe ich immer noch das Gefühl, dass ein Teil der Eleganz und Benutzerfreundlichkeit von vue fehlen wird.

Alle, die damit einverstanden sind, können Sie bitte einfach unter der Beschreibung auf den Daumen nach oben klicken? es ist besser, als 17.000 Leute mit +1 zu spammen. Noch besser, lassen Sie sich einige sinnvolle Anwendungsfälle einfallen.

Ich habe noch nie Zwei-Wege-Filter verwendet, aber ich würde die Filter wirklich vermissen! Ich kann (und tue es manchmal) berechnete Eigenschaften verwenden, aber in einigen einfachen Fällen ist es eine Annehmlichkeit, die den Arbeitsablauf wirklich beschleunigt.

Betrachten Sie dieses sehr einfache Beispiel

<input type="text" v-model="filter">

<ul>
    <li v-for="item in items | filterBy filter">{{ item }}</li>
</ul>

Das Obige ist so viel einfacher zu schreiben, wenn keine komplexere Filterung erforderlich ist.

Vergleichen Sie es nun mit dem Folgenden

<input type="text" v-model="filter">

<ul>
    <li v-for="item in filteredItems">{{ item }}</li>
</ul>

new Vue({
    el: 'body',

    data: {
        items: [],
        filter: ''
    },

    computed: {
        filteredItems() {
            var self = this
            return this.items.filter(function(item) {
                return item.indexOf(self.filter) > -1
            })
        }
    }
})

Ich sage nicht, dass das zweite schwer zu schreiben ist, aber wenn Sie es an vielen Stellen verwenden, werden Sie anfangen, sich zu wiederholen, und es braucht nur etwas mehr Zeit, die Sie vielleicht für einige andere, nützlichere Funktionen verwenden könnten!

So oder so werde ich ein glücklicher Vue-Benutzer bleiben und nur meine Meinung zu den veralteten Filtern teilen!

Filter sind wiederverwendbar. Ich kann eine Funktion erstellen, um meine Daten einmal zu formatieren, als Filter registrieren und einfach von allen Instanzen verwenden. Wie kann ich das in 2.0 machen?

Wie kann ich das in 2.0 machen?

• Mischen
• Separates Modul mit Methode
• Separates Modul mit berechneter Prop-Funktion

Ich habe gerade einen Kommentar zum Ankündigungsthread hinterlassen, also anstatt alles hier zu duplizieren, verlinke ich einfach darauf:

http://archive.forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/8

Ich verstehe das Gefühl vollkommen, dass dir etwas super Praktisches weggenommen wird. Aber zuerst nehmen Sie sich bitte einen Moment Zeit, um den Kommentar von @chrisvfritz im obigen Forenthread zu lesen. Um die Diskussion zu vereinfachen, kopiere ich es einfach hier:

@theotherzach Danke für deine Leidenschaft für Vue! Ich würde die Abwertung gerne etwas besser erklären, aber zuerst sollte ich mich vorstellen. Ich bin Mitglied des Vue-Kernteams, ich verwende Vue ständig für meine freiberufliche UI- und Datenvisualisierungsarbeit, und ich bin auch ein Pädagoge, der Menschen beibringt, neben anderen Webtechnologien Vue und Rails zu verwenden. Ich betreibe eine Code-Schule, also helfe ich Leuten fast _jeden Tag_, den Umgang mit diesen Tools zu lernen (und sie zusammen zu verwenden).

Ich war auch einer der großen Befürworter des Entfernens von Filtern in Vue 2.0.

Das Problem mit Filtern für Anfänger zu Vue

Ein großer Teil des Grundes, warum ich dafür war, Filter abzulehnen, war tatsächlich _für_ Anfänger. Bei der Arbeit mit Schülern ist dies ein Gespräch, das mehr als einmal auftaucht:

• Student: "Also ist ein Filter im Grunde eine Funktion?"
• Mentor: "Ja!"
• Student: "OK, also kann ich es normal mit Funktionsklammern verwenden?"
• Mentor: "Nun, nein. Es ist eine besondere Art von Funktion."
• Student: "Kann ich es an anderen Stellen verwenden? Wie in einem berechneten Wert?"
• Mentor: "Nein, Sie können es nur in Vorlagen und nur mit der speziellen Pipe-Syntax verwenden."
• Schüler: "... warum?"

Eines der großen Dinge, die Anfänger zum Stolpern bringen, sind _Ausnahmen_. Filter sind nur Funktionen, _außer_ sie erfordern eine spezielle Syntax und können nicht überall verwendet werden. Und sie verwenden eine Pipe-Syntax, die sich von der Pipe-Syntax unterscheidet, die möglicherweise in ES7 integriert ist , was bedeutet, dass es nicht lange dauern wird, bis die Leute zwei sehr ähnliche Operatoren haben, um etwas sehr Ähnliches zu tun, aber sie sind nicht _ganz_ gleich. Und nur einer davon ist tatsächlich JavaScript.

Util-Bibliotheken _sind_ nützlich, aber Vue ist keine

Im Fall von filterBy , Transformationen für Zeichenfolgen und Zahlen und anderen spezifischen Filtern, ja, sie sind in Anwendungen nützlich, in denen sie vorkommen. Util-Bibliotheken im Allgemeinen sind nützlich. Und es stehen Dutzende großartiger Dienstprogrammbibliotheken zur Auswahl, aber Vue ist keine Dienstprogrammbibliothek. Und ehrlich gesagt war keines der von uns angebotenen Dienstprogramme das Beste seiner Klasse.

Der Umgang mit Währungen, Daten oder sogar das Filtern von Arrays - das ist nicht unser Fokus. Viele Apps benötigen sie nicht, und die meisten Apps, an denen ich gearbeitet habe und die mit diesen Problemen konfrontiert sind, erfordern eine robustere Lösung, als sie Vue derzeit anbietet (oder anbieten _könnte_, ohne eine erhebliche Aufblähung und Neuerfindung des Rades einzuführen).

In meinen Apps hat Accounting.js die Währung hervorragend gehandhabt, Moment.js (wie Sie erwähnt haben) Datums- und Uhrzeitangaben, pluralize handhabt viele Pluralisierungen nicht gut, daher ist ein benutzerdefinierter berechneter Wert oft wünschenswerter, und json ist etwas mehr als JSON.stringify .

Die Vorteile berechneter Eigenschaften

Die Verwendung von berechneten Eigenschaften anstelle von Filtern bietet auch den Vorteil, dass der verarbeitete Wert auf einfache und trockene Weise _überall_ in der Komponente wiederverwendet werden kann. Ich muss dies ständig in meinen Apps tun. Die berechnete Eigenschaft verschiebt auch mehr Implementierungsdetails aus der Vorlage und hinterlässt nur eine saubere Beschreibung dessen, was die Komponente tut. Und ein Vorteil gegenüber global definierten Filtern besteht darin, dass man sich nur die Funktion für diesen Computerwert ansehen muss, um zu sehen und genau zu optimieren, wie sie funktioniert. Auf Arrays bietet das Verketten der map - und filter -Methoden von JavaScript sogar die gleiche lineare Verarbeitungsliste wie Pipes, aber auf eine noch deklarativere und leichter manipulierbare Weise.

Die Nützlichkeit von global definiertem Was auch immer

Wenn Sie eine Funktion oder irgendetwas anderes definieren müssen, auf das Sie in all Ihren Komponenten zugreifen möchten, ist Vue.prototype.whateverIWant = mySuperCoolFunction eine großartige Möglichkeit, dies zu tun. Ich persönlich habe es nie _wollte_ es zu tun. Ich habe es immer vorgezogen, eine Hilfsmethode in ein Modul zu packen und dieses Modul dort zu importieren, wo ich es brauche. Aber es ist immer noch wichtig zu beachten, dass die Registrierung von Globals - jeglicher Art - nicht erschwert wird.

Der Fall der Direktive debounce

Ich muss sagen, da bin ich wirklich bei dir! Ich habe kürzlich alle meine Vue-Projekte durchgesehen und jedes einzelne, das irgendwo ein input hatte, verwendete auch debounce . Tatsächlich hat nur eine meiner früheren Anwendungen Entprellung _nicht_ verwendet. Obwohl technisch gesehen ein Dienstprogramm – Lodash und viele andere robuste Projekte bieten Debounce-Lösungen – ist dieses Problem ziemlich universell für die UI-Entwicklung, für _jede_ Art von App. Das Schreiben Ihrer eigenen Entprellfunktion ist auch nicht trivial genug, dass ich wahrscheinlich die Implementierung von lodash für fast jedes Projekt verwenden möchte.

Es bleibt eine interne Debatte darüber, also werden wir sehen, wohin es führt. Aber ja, für mich persönlich und es scheint auch für einige andere, entfernt das Entfernen von Debounce den größten Teil der Bequemlichkeit, die v-model bietet.

Nochmals vielen Dank für Ihre Leidenschaft!

Im Ernst, wir finden es toll, wie sehr du Vue liebst, und sind wirklich froh, dass du deine Bedenken äußerst – und vor allem auf so freundliche und respektvolle Weise! Wir hören Sie. Das Kernteam besteht ausschließlich aus Designern, Frontend-Entwicklern und Datenvisualisierungsspezialisten. Wir alle verwenden Vue für unsere eigene Arbeit, die ziemlich vielfältig ist, also widmen wir uns definitiv der Verbreitung von Hundefutter, das wir selbst essen möchten. :-)

Reden ist billig, lassen Sie uns codieren, um zu sehen, ob ohne Filter, wie wir filterBy anwenden und umgekehrt:

Schreiben Sie globale reine Filterfunktionen in eine separate Datei zur Wiederverwendung von Code

//
// filters.js
//
function filterBy(list, value) {
  return list.filter(function(item) {
    return item.indexOf(value) > -1;
  });
}

function findBy(list, value) {
  return list.filter(function(item) {
    return item == value
  });
}

function reverse(value) {
  return value.split('').reverse().join('');
}

export {filterBy, reverse, findBy}

Verwenden Sie Filter in der App.vue-Vorlage

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ reverse(msg) }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in filterBy(words, userInput)">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in findBy(words, userInput)">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
import {reverse, filterBy, findBy} from './filters.js'
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
  methods : {
    reverse,
    filterBy,
    findBy,
  },
}
</script>

siehe das Ergebnis hier http://raywill.github.io/vuefilter/

Wenn ein Filter verwendet wird, würde der folgende Vue-Code dasselbe tun:

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ msg | reverse }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in words | filterBy userInput">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in words | findBy userInput">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
}

Anscheinend könnten wir mit unterstütztem Filter weniger trivialen Code schreiben.
Persönlich bevorzuge ich den vue 1.0-Weg, der das Programmieren angenehmer macht.

Was die Boilerplate betrifft - es gibt mehrere Möglichkeiten, damit umzugehen.

1. Explizit importieren/exportieren

Wie @raywill oben gezeigt. Es ist etwas ausführlicher, aber die Vorteile sind:

1. Sie müssen die Filterdokumentation von Vue nicht nachschlagen, um zu verstehen, wie es funktioniert. Es ist sehr deutlich, woher die Funktionen kommen und wie sie implementiert werden.
2. Die Funktionen selbst sind nur JavaScript. Sie können sie im Gegensatz zu integrierten Filtern, die Sie nicht berühren können, ändern / zusammenstellen, um sie an spezielle Anwendungsfälle anzupassen.
3. Sie können diese Funktionen importieren und programmgesteuert in Methoden, berechneten Eigenschaften und überall dort, wo Sie JavaScript schreiben, wiederverwenden.

2. Befestigen Sie sie an Vue.prototype

Vue.prototype.filters = {
  filterBy: ...,
  orderBy: ...
}

<ul v-for="word in filters.filterBy(words, userInput)">
    <li>{{word}}</li>
 </ul>

3. Gehen Sie funktional (für fortgeschrittene Benutzer)

computed: {
  filteredThings () {
    return this.things
       .filter(contains(this.foo))
       .sort(by(thing => thing.bar))
       .slice(0, 10)
  }
}

So sehen die Hilfsfunktionen aus:

// a function that returns a predicate function for array.filter()
function contains (value) {
  return thing => thing.indexOf(value) > -1
}

function by (getValue) {
  return (a, b) => {
    return getValue(a) > getValue(b) ? 1 : -1
  }
}

Auch hier ist eine sehr wichtige Designüberlegung, dass eingebaute Filter nützlich sein können, ihnen aber die Flexibilität von reinem JavaScript fehlt . Wenn eine integrierte Funktion nicht Ihren Anforderungen entspricht, müssen Sie entweder etwas Ähnliches neu implementieren (und beides in Ihrem endgültigen Code versenden, wo der integrierte Code zu nutzlosem, totem Code wird) oder auf Vue warten aktualisieren Sie sie und veröffentlichen Sie eine neue Version.

@yyx990803 Mir gefällt der Prototyp-Ansatz, aber was ist mit Fällen, in denen Sie mehrere Filter benötigen?

Es ist ziemlich üblich, orderBy zusammen filterBy zu verwenden

<ul v-for="word in filters.orderBy(filters.filterBy(words, userInput), column, -1)">
    <li>{{word}}</li>
 </ul>

Wie wäre es mit Fällen, in denen Sie auch limitBy hinzufügen würden?

<ul v-for="word in filters.limitBy(filters.orderBy(filters.filterBy(words, userInput), column, -1), limit)">
    <li>{{word}}</li>
 </ul>

Macht dieser Ansatz den Code weniger lesbar?

Ja, zumindest meiner Meinung nach.

Ich schätze, wir hätten Filter wie filterAndOrderBy kombinieren können, aber das fühlt sich auch nicht richtig an.

Ich bin offen für Änderungen, möchte nur einen fast so einfachen Weg finden, damit umzugehen!

Auch der Vorteil, die Filter überall verwenden zu können, ist ein wirklich guter Punkt.

Nur um anzumerken, dass die @vuejs/collaborators eine Option diskutiert haben, um ein Dienstprogrammpaket der aktuellen integrierten Filter bereitzustellen. Es gibt viele Ressourcen, die Ihnen Dienstprogramme für Ihre Codebasis zur Verfügung stellen.

Eine gute Sache beim Entfernen der Kernfilter ist, dass Sie sie jetzt selbst anpassen/implementieren können. Das gibt Ihnen viel mehr Flexibilität.

@rigor789 Vorlagenausdrücke sollten so einfach wie möglich sein. Idealerweise genau wie <div v-for="filteredData"> </div> . Dies kann eine berechnete Requisite sein, die die Logik zum Erstellen der gefilterten Daten enthalten kann. Dies ist viel besser lesbar und besser als so etwas wie:

<div v-for="item in filters.orderBy(filters.filterBy(words, userInput), column, -1)"> </div>
oder
div v-for="item in data | filterBy | orderBy " ect

Es ist viel besser wiederverwendbar als berechnete Eigenschaft zuzuweisen und kann sogar an untergeordnete Komponenten weitergegeben werden. Was wäre, wenn Sie die gefilterten Daten an zwei Stellen verwenden möchten? Es ist einfacher, einfacher, zuverlässiger und lesbarer für Vorlagen, einfache Ausdrücke zu haben, im Vergleich zu verketteten Filtern in Ausdrücken.

Für alle, die mitmachen, habe ich @chrisvfritz hier geantwortet: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

Das Folgende löst meinen Anwendungsfall von _sehr_ wenigen global verfügbaren reinen View-Hilfsfunktionen. Ich ziehe meine Bedenken bezüglich der Entfernung des Filters zurück. Verbrenne sie! 🔥 Herzlichen Glückwunsch an @chrisvfritz und @yyx990803, dass sie geändert haben !

Vue.prototype.filters = {
  filterBy: ...,
  orderBy: ...
}

<ul v-for="word in filters.filterBy(words, userInput)">
    <li>{{word}}</li>
 </ul>

Ich stimme @yyx990803 voll und ganz zu , entferne Filter und

@blake-newman Das ist ein sehr guter Punkt, ich bin an dieser Stelle größtenteils überzeugt, und wenn ich an die Lesbarkeit denke, denke ich, dass so etwas erreicht werden kann

computed: {
    filteredItems() {
        return f(this.items).filterBy(this.filter /* string or function*/)
                            .orderBy(this.field, -1)
                            .limitBy(10)
                            .apply()
    }
}

Hier ist eine kurze Beschreibung des Konzepts

Eine gute Sache beim Entfernen der Kernfilter ist, dass Sie sie jetzt selbst anpassen/implementieren können. Das gibt Ihnen viel mehr Flexibilität.

Sie konnten diese immer selbst anpassen/umsetzen.

Vue ist keine Utility-Bibliothek. Und ehrlich gesagt war keines der von uns angebotenen Dienstprogramme das Beste seiner Klasse.

Was uns Sorgen macht, ist das Entfernen der Filterfunktion in den Vorlagen. Das Entfernen der eingebauten Filter ist sehr sinnvoll – sie können leicht neu erstellt werden, indem sie als Proxy für Unterstriche/andere util-Bibliotheken verwendet werden. Dann könnte jemand sogar ein einzelnes Plugin veröffentlichen, das alle aktuellen integrierten Filter neu erstellt.

Die Verwendung von berechneten Eigenschaften anstelle von Filtern bietet auch den Vorteil, dass der verarbeitete Wert überall in der Komponente einfach und trocken wiederverwendet werden kann.

Natürlich können Sie berechnete Eigenschaften verwenden, wenn Sie sie an anderer Stelle wiederverwenden müssen. Aber wenn Sie dies nicht tun, ist ein Filter immer noch viel bequemer.

Es gibt einige andere Punkte, die ich in diesem Link gepostet habe, den ich oben geteilt habe.

Warum nicht eine Syntax für Filter unterstützen, die wie die von ES7 vorgeschlagene Syntax funktioniert? Das würde es den Menschen ermöglichen, ihre geliebten Filter weiter zu verwenden und sie mit dem in Einklang zu bringen, was die Zukunft bringen könnte. Wenn wir schließlich ES7-Pipes haben, können Sie die interne Implementierung wechseln, ohne die API zu ändern.

Sind ES7-Rohre zugelassen oder unterliegen sie vielen Änderungen?

Es kann sich theoretisch ändern, scheint aber ... stabil zu sein?
Status: mindeavour/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Ich denke, wir sind uns bezüglich des Werts von Pfeifen im Allgemeinen einig. 😃 Ein Vorteil des neuen Compilers in 2.0 ist, dass wir den generierten Render-Funktionscode durch Babel leiten können. Dies muss noch weiter untersucht werden, aber es ist nicht unvorstellbar, dass Sie, sobald |> mehr Schwung gewinnt und ein Babel-Plugin dafür entwickelt wird, Methoden wieder mit Pipes verketten könnten – _überall_ in Ihrer App. Als großer Fan von LiveScript und anderen funktionalen Sprachen erkenne ich definitiv den Wert !

Dieser Pipeline-Betreiber befindet sich noch nicht einmal in Stufe 0

@thelinuxlich Ja, ich glaube, sie warten immer noch auf einen Champion auf TC39. 😞

@rigor789 das ist eine der Alternativen, die ich auch erwähnen wollte! Die Leistungsfähigkeit von JavaScript ermöglicht es Ihnen, die Ausdruckskraft Ihrer Wahl zu erreichen, und imo ist es besser, als die Filterlogik in Vorlagen zu stecken.

@yyx990803 Wie verhält sich Vue in den folgenden Fällen, wenn der Name eines Benutzers aktualisiert wird?

<div v-for="user in users">
  <p>{{ user.name |> capitalize }}</p>
</div>

Vue.extend({
  computed: {
    displayableUsers() {
      for (user of this.users)
        user.name = capitalize(user.name);
    },
  },
});

Es scheint, als würde Ersteres nur das eine Objekt neu rendern, während Letzteres die gesamte Liste neu berechnen würde?

@rpkilby das scheint nicht das Äquivalent zu sein. Es wäre eher so:

Vue.extend({
  methods: {
    capitalize () { ... }
  }
})

<div v-for="user in users">
  <p>{{ capitalize(user.name) }}</p>
</div>

Ich mag immer noch nicht die Idee, Methoden als Filter zu verwenden (als Bauchgefühl scheint es einfach falsch zu sein, kann es aber nicht wirklich erklären). In jedem Fall haben Sie andere Methoden zur Bereitstellung von Filtern besprochen, also +1.

Nichts, was in diesem Thread vorgeschlagen wird, kommt auch nur annähernd an die Ausdruckskraft und Prägnanz von Filtern heran. Es tut einfach nicht.

Und das macht mich richtig traurig. Wie ich im Forumsthread sagte: Für mich entfernt dies einen großen Teil dessen, was Vue Vue ausmacht.

Wer mich sucht, findet mich hörbar schluchzend in der Ecke 😟

Auf keinen Fall, diese Änderung fördert eine gute Javascript-Codierung, behandeln Sie sie :)

Ich hatte gerade eine lange Diskussion mit @yyx990803 , wo ich – aus der Sicht eines Benutzers – vorgeschlagen habe, die _Syntax_-Unterstützung beizubehalten, weil es sich elegant und natürlich anfühlt. Meine Vorstellung war ungefähr so:

<li v-for="item in items | filterBy 'name' | orderBy 'title' 1">{{ item.name }}</li>
...
<script>
  ...
  methods: {
    filterBy (items, field) { return filtered; },
    orderBy (items, field, order) { return filtered; }
  }
  ...
</script>

Ich hatte den Eindruck, dass dies das Beste aus beiden Welten erreichen würde.

Am Ende bin ich jedoch davon überzeugt, dass das Entfernen von Filtern als Ganzes tatsächlich eine bessere Sache ist: Wie @thelinuxlich gerade gesagt hat, fördert es besseres JavaScript und logisches Denken. Wir führen keine Logik in Laravels Blade oder die Ansichtsebene eines anderen Frameworks ein, und wir sollten dies auch nicht in den Vorlagen von Vue tun.

Das heißt, @JosephSilber, wenn du in die andere Ecke findest du mich dort.

Für mich fühlen sich Filter sehr schön an, die Syntax ist genau so, wie eine Filtersyntax aussehen sollte.

Eine weitere attraktive Sache an Vue ist für mich, dass (einige) Batterien im Lieferumfang enthalten sind. Es wäre wirklich traurig, eines dieser Dinge zu verlieren – beides, was meiner Meinung nach Vue auszeichnet.

Beim Durchlesen des Threads scheint es, dass die meisten Bedenken bei Filtern die Tatsache waren, dass Vue Standardfilter hatte und nicht wirklich die Funktion selbst (oder doch? Ich bin mir immer noch nicht sicher).

Ich mag das Filter-Plug-in-Denken von @blake-newman und es sollte vorgefertigte Beispiele geben. Wenn andere Leute andere Filter entwickeln, sollten sie Plug-and-Play sein. Das wäre großartig. Ich stimme absolut zu, dass das Erstellen von Filtern in der Verantwortung des Benutzerlandes liegt.

Was immer noch erwünscht ist, sind die Pipe- und Chaining-Fähigkeiten und die Globalität der ursprünglichen Filterfunktion. Die Bedenken hinsichtlich der Globalität wurden von @yyx990803 abgedeckt. Wie sieht es mit der Verkettung mit dem Rohr aus? Es hilft enorm beim Lesen der Vorlagen und beim Verstehen, was als Ausgabe zu erwarten ist. Das Rohr und die Verkettung wurde oben besprochen. Kann man es noch machen? Warum ist es überhaupt schlecht? Für den Designer ist es Gold! Der Filter ist ein Designerwerkzeug, nicht das des JS-Programmierers. Also fällt das Argument, besseres JS zu schreiben, in meinem Buch von der Tafel, aber ich kann verstehen, warum es gewollt wäre. Aber als Designer möchte ich auch besseren Code schreiben, und Filter erlauben mir das wunderbar. :Lächeln:

Scott

Hier ist die Sache mit der Verkettung - Filter werden hauptsächlich für zwei Zwecke verwendet:

1. Text formatieren;
2. Verarbeitung eines Arrays.

Bei der Formatierung von Text wird in 90 % oder mehr der Fälle nur eine einzige Hilfsmethode verwendet. Das Verketten ist in diesem Fall nicht wirklich ein Problem.

Was Arrays angeht: Ich habe bereits darauf hingewiesen, dass die Array-Verarbeitung eigentlich logisch ist und in JavaScript besser geeignet ist. Mehrere verkettete Array-Filter zu haben, sieht vielleicht gut aus, wenn es einfach ist, kann aber hässlich werden, wenn Sie mehr als 1 Argument für jedes verwenden. Es ermutigt Sie auch, zu viel Logik in Ihre Vorlage zu stecken, wenn Sie es wirklich nicht sollten. Sie sind auch unflexibel (können den verarbeiteten Wert nicht einfach abrufen). Im Vergleich mit ES2015 das ursprüngliche Beispiel

<div v-for="thing in things | filterBy 'foo' | orderBy 'bar' | limitBy 5">

kann geschrieben werden als:

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

Es ist nur JavaScript, es muss keine Magie, keine alternative Syntax und keine filterspezifische API gelernt werden. Und Sie können auf den verarbeiteten Wert zugreifen (der intelligent zwischengespeichert wird). Sie können auch Zucker hinzufügen, wie in den vorherigen Kommentaren gezeigt. Außerdem sieht Ihre Vorlage sauberer aus:

<div v-for="filteredThings">

Ich weiß, dass dies wie eine praktische Sache ist, die weggenommen wird, aber ehrlich gesagt klingen die Argumente für Filter im Moment für mich so, als würde ich versuchen, die Syntax nur um der Syntax willen beizubehalten. Meiner Meinung nach braucht es mehr als nur „weil es elegant ist“, um ein Feature zu rechtfertigen – es muss einen objektiven Wert bieten. Dies war der Fall für inline-templates , aber ich sehe es nicht für Filter.

@yyx990803 - Ihr Beispiel veranschaulicht das Problem, denke ich. Auch hier bin ich nicht der beste JS-Programmierer, aber ich muss kein JS-Programmierer sein, um zu wissen, dass filteredThings nichts darüber aussagt, was es wirklich tut. Für mich ist das eine schlechte Praxis. :smile: Die Tatsache, dass die Filtermethode global ist, bedeutet auch, dass ich in Dokumenten und im Code suchen oder die Ausgabe entschlüsseln muss, um herauszufinden, was die Methode tut. Nicht wirklich elegant. Richtig?

Also, okay. wir könnten einen Methodennamen wie `filterByOrderByAndLimit' haben. Was ist mit den Argumenten?

<div v-for="filterByOrderByAndLimit(things,thing,'foo','bar',5)">

Wäre das richtig?

Wenn ja, wäre das vielleicht machbar. Trotzdem sieht es nicht gut aus.

Und jetzt möchte ich nur filterBy und OrderBy. Brauche ich dafür auch eine separate Methode? Und dann möchte ich eine Währungsformatierung hinzufügen. Eine andere Methode? Die Filterverkettung in den Vorlagen macht die Manipulation der Präsentation flexibel und sehr ausdrucksstark. Dieses Problem muss noch richtig mit Methoden angegangen werden (und mein Mangel an Wissen erlaubt mir nicht zu verstehen, dass Methoden besser sein können).

Kann das möglich sein?

<div v-for="filterBy(things, thing, 'foo').OrderBy('bar').Limit(5)">

Ich stimme zu, dass zu viel Logik in einer Vorlage vermieden werden sollte. Aber die Verkettung von Filtern und die Möglichkeit, einen Filter einfach irgendwo in die Komponenten/Vorlagen einer App einzufügen, ist ein fantastisches Konzept, und es gab einen Grund, warum Sie es von Anfang an hinzugefügt haben. Was war das für ein oder mehrere Gründe? Wenn Sie sie benennen können, dann wette ich, dass sie um Längen aufwiegen, „aber es fördert schlechte Praktiken“.

Alles, was Flexibilität zulässt, kann unsachgemäß verwendet werden, genau wie Vue selbst. Das Hauptargument für inline-template war, dass es flexibel war und Vue auf unterschiedliche Weise verwendet werden konnte. Filter sind nicht viel anders, außer dass sie Vue-intern sind und keinen Einfluss darauf haben, wie Vue extern verwendet werden kann. Das schmälert aber nicht seine Bedeutung. Denken Sie daran, dass viele Leute auch gesagt haben, dass dies ein No-Go für sie wäre, ein Upgrade durchzuführen. So wichtig ist es! :Lächeln:

Der neue Weg braucht nur die gleichen Eigenschaften wie der alte Weg.

• ankettbar
• global
• zu Vorlagen hinzufügen, um schön auszudrücken, wie die Daten in den Vorlagen manipuliert werden

(Habe ich was vergessen?)

Wenn es das alles kann, dann bin ich sicher, dass alle ziemlich zufrieden sein werden. Ich persönlich kann mir das mit Methoden (noch) nicht vorstellen.

Scott

@smolinari

1. Ich habe klar gesagt, dass Sie weniger Logik in Ihre Vorlagen einbauen sollten. Das ist meine Meinung, ob es dir gefällt oder nicht. Natürlich steht es Ihnen frei, anderer Meinung zu sein, aber ich kann Ihnen nicht helfen, wenn Sie gegen empfohlene Best Practices arbeiten wollen.
2. Gegeben (1) - Ich habe erklärt, warum Verkettung kein Problem ist, da komplexe Logik in JavaScript ausgeführt werden sollte.
3. Ich habe auch Beispiele gegeben, wie Sie global verfügbare Methoden hinzufügen können.
4. Sehen Sie sich das Beispiel von @ rigor789 zu einer benutzerdefinierten Verkettungssyntax an, die der von Ihnen gewünschten ähnelt.
5. Das Ziel des Frameworks ist es, das bereitzustellen, was meiner Meinung nach der beste Weg ist, Front-End-Anwendungen zu entwickeln, und nicht , um es allen recht zu machen. Verwenden Sie also bitte nicht "Ich werde kein Upgrade durchführen, wenn Sie mir diese Funktion nicht zurückgeben" - es funktioniert nicht.

Warum probiert ihr diese neue Alpha-Version nicht eine Woche lang aus und kommt dann mit ein paar wirklich wertvollen Kommentaren (basierend auf eurer Praxis)? Versuchen Sie vielleicht, Ihre vorhandene App zu überarbeiten, und lassen Sie uns wissen, was unmöglich war, was verbessert wurde, was schlechter wurde, damit wir besser darüber diskutieren können. Das wäre nützlich für alle, denke ich.

@yyx990803 - Ich habe 1 zugestimmt. Also sind wir uns einig. :smile: Ich stimme nur nicht zu, dass es ein guter Grund ist, etwas herauszunehmen, das so viel Liebe gewonnen hat.

Sie haben sich also im Laufe der Zeit entschieden, dass pragmatisches JS besser ist als pragmatisches HTML?

Das Argument eines No-Go für das Nicht-Upgrade ist das, was andere gesagt haben. Ich versuche nur, das zu kommunizieren und abzumildern.

Ein letztes Argument von mir. Betrachten Sie dies aus den Augen des Benutzers. Angenommen, ich habe ein System wie Laravel oder ein anderes MVC- oder MVVM-System, das Vue enthält, wodurch der Benutzer dieses Systems auch seine eigenen Komponenten erstellen kann. Der Filter, so wie er war, vereinfacht die Lernkurve und ermöglicht es den Benutzern dieses Systems, viel zu erledigen, ohne JS zu berühren. Ich bin ein Fan von Vue, weil es auch Nicht-JS-Programmierern erlaubt hat, noch viel zu erledigen. Das ist der gleiche Grund, warum ich React und JSX nicht mag. Diese Kombination wird im Laufe der Zeit eine viel kleinere Benutzerbasis als Vue haben. Ich wette Geld darauf.

Ich verstehe auch, dass die wirkliche Flexibilität in JS liegt. Verlassen Sie sich wegen der Flexibilität in Vue dennoch nicht ausschließlich auf JS. Denken Sie daran, dass nicht jeder ein Killer-JS-Programmierer ist. Tatsächlich sind die meisten Menschen nicht. Der Filter war eine gute Möglichkeit, viel für diese Leute zu erledigen, und er war ein nettes Sprungbrett für weitere JS-Manipulationen. Filter schaffen das nicht? Gehen Sie tiefer in die JS-Methoden.

In Ordnung. Genug von mir..... Ich bin fertig. Und danke fürs Zuhören auf jeden Fall. Vue ist immer noch großartig! :Lächeln:

@azamat-sharapov - guter Punkt.

Scott

Leute zu sehen, die versuchen, schlechte Praktiken innerhalb von JS zu rechtfertigen, macht mich traurig. Wirklich, Sie müssen kein Profi sein, machen Sie einfach die grundlegenden Hausaufgaben (oder ist das heutzutage nicht mehr einfach?)

Das Problem, das ich mit Filter-Inside-Methoden habe, ist die Semantik.

Ups, Filter sind wie statische Funktionen, während Methoden nicht statische Funktionen sind.

Filter vermitteln eine ganz andere Semantik als Methoden. Der größte Unterschied besteht darin, dass Filter this nicht verwenden können, Methoden jedoch schon.

@yyx990803 während die Verwendung Vue.prototype.filters funktionieren kann, aber das Ändern Vue sieht für mich nicht nach einer guten Praxis aus. Ich würde eher dafür plädieren, ein separates (globales) Objekt zu erstellen, das alle Filter enthält.

Es sieht nicht nach guter Praxis aus, weil Globals keine gute Praxis ist. Der empfohlene Ansatz ist das explizite Importieren von Hilfsmethoden. Das Anhängen an den Prototyp ist eine Problemumgehung für diejenigen, die Methoden nicht explizit importieren möchten.

Was die Semantik betrifft, so sind Filter sowieso ein geprägtes Konzept. In JavaScript würden Sie keine andere Semantik erfinden, nur um einen String in Großbuchstaben zu schreiben – Sie rufen eine Funktion auf. Und das sind sie, JavaScript-Funktionen.

Ich werde noch einen Kommentar machen, um zu versuchen, meinen persönlichen Standpunkt klarer zu machen, hauptsächlich wegen des Kommentars "versucht, schlechte Praktiken innerhalb von JS zu rechtfertigen". Das versuche ich sicherlich nicht.

Mir ist klar, dass Vue mehr als nur ein Templating-System ist, aber es ist auch ein Templating-System und ich fürchte, es versucht, sich von dieser Rolle zu entfernen, was meiner Meinung nach nicht der Fall sein sollte. Nehmen Sie also als Templating-Engine/System die Twig-Template-Engine als ein sehr erfolgreiches Beispiel dafür, was man von einem Templating-System erwarten kann. Sie haben einen Abschnitt „ Für die Vorlagendesigner “ und einen Abschnitt „ Für die Entwickler “ in ihren Dokumenten. Als Templating-System ist Twig auch für den Template-Designer leistungsfähig, da es randvoll mit Standardverhalten ist, einschließlich Filtern . Es ermöglicht Nicht-Entwicklern, eine Menge mit dem Vorlagensystem zu tun, ohne PHP direkt zu kennen. Sie müssen nur lernen, was Twig zu bieten hat und wie man es benutzt. Ich suche das auch in Vue. Ich würde auch gerne einen Abschnitt "Vue für Vorlagendesigner" in den Dokumenten sehen. :Lächeln:

Ebenfalls sehr wichtig ist die Erweiterbarkeit von Twig. Wenn etwas in der Standardversion nicht verfügbar ist, kann es hinzugefügt werden. Dann kommt der Entwickler ins Spiel. Das Schöne ist auch, dass Erweiterungen geteilt werden können, was bedeutet, dass es nur einmal gemacht werden muss.

Das andere Schöne an diesen zwei Ebenen Designer/Entwickler ist, dass Sie eine viel breitere Basis von Benutzern erhalten. Viel, viel breiter und das gilt auch für . Und wenn die Verhaltensvorgaben nicht ausreichen, lernen sie bereitwillig die zugrunde liegende Sprache. Und dann lernen sie Best Practices und den Rest.

Wenn Sie sagen, Vue kann keine Template-Engine sein, ohne JS lernen zu müssen, dann würde ich sagen, dass es seinen Marktwert erheblich senkt. Wenn Sie sagen, Sie werden die Tür offen lassen, damit andere diese Tools für die Templating-Engine als Plug-Ins erstellen können, großartig. Aber dann wird jeder für das kämpfen, was im Templating-System enthalten sein sollte. Das ist IMHO auch kontraproduktiv.

War es in Ihrem Schüler, der über Filter sprach, Beispiel Evan, jemand, der JS lernte, oder jemand, der eine Template-Engine lernte? Wenn es letzteres wäre, wette ich, dass das Gespräch anders verlaufen würde.

Jedenfalls. Ich denke immer noch, dass Vue ein erfolgreiches System ist. Ich hoffe, dass meine Gedanken andere dazu bringen, anders über die Rollen von Vue zu denken. :Lächeln:

Scott

@yyx990803 Wenn Filter ein geprägtes Konzept sind, warum wurden sie dann überhaupt geprägt?

Ich glaube, das liegt daran, dass innerhalb von <template> alle externen Variablen wie $data oder abc in this.$data und this.abc konvertiert und somit einfache js-Funktionen definiert werden außerhalb der Komponente kann nicht referenziert werden. Filter wurden eingeführt, um diese Einschränkung zu überwinden.

Diese Einschränkung besteht immer noch --- ich gehe davon aus, dass ich Recht habe - um die Einschränkung zu entfernen, müssten Entwickler this.abc explizit codieren, um auf this.abc verweisen, und auf js-Funktionen zugreifen, wie sie referenziert würden js.

Aber das wird ein zu mächtiges Feature sein, anfällig für Missbrauch und die Migration von altem Code wird ein Schmerz sein. Die aktuelle Syntax sieht für mich viel besser aus.

Ich stimme Ihnen zu, dass Filter im Grunde js-Funktionen sind und in die Komponente importiert werden sollten. Ich mag es nur nicht, dass sie an derselben Stelle wie Methoden definiert sind.

Hallo allerseits. Ich habe den ganzen Thread gelesen und das ist meine Meinung.

• Niemand würde die eingebauten Filter wie orderBy filterBy und andere vermissen
• Was jeder noch haben möchte, ist der Pipe-Operator in Vorlagen
• Das Kernteam sagt, dass die Logik in Javascript bleiben sollte, nicht in Vorlagen, außerdem gibt es ein kommendes es7-Feature mit dem Pipe-Operator.

Als kurze Zusammenfassung, was meiner Meinung nach eine gute Lösung sein könnte, bis js einen nativen Pipe-Operator implementiert , wäre, den Pipe-Operator als Plugin zu haben und die Version 2.0 so zu behalten, wie sie ist. So können Benutzer tun

Vue.use(require('vue-pipe'))

Während wir auf die neue Feature-Implementierung warten, könnte sie mit einer Warnung vor bevorstehender Verwerfung oder so etwas enthalten sein. Ich weiß, dass jeder dieses Plugin implementieren könnte, aber ich denke, es wäre besser, wenn es vom Vue-Team bereitgestellt und gepflegt würde, wäre das möglich?

Ich könnte mich irren, aber ich glaube nicht, dass Vue Plugins erlaubt, mit seinem Compiler herumzuspielen.

@azamat-sharapov Natürlich nicht. Ich dachte nur nicht, dass es mit dem Vue-Compiler durcheinander kommen würde :open_mouth:

@YerkoPalma Ich _liebe_ den Pipe-Operator absolut. Ich benutze es obsessiv in funktionalen Sprachen und kann es kaum erwarten, es in JavaScript zu haben! _Aber_ stellen Sie sich vor, Vue hätte nie Filter gehabt. Würden Sie verlangen, dass ein Frontend-Framework die JavaScript-Syntax erweitert? Das ist die Domäne von Babel oder einer Programmiersprache, die in JS kompiliert wird, kein UI-Framework. Wenn Sie es vorziehen, eine Sprache wie LiveScript zu verwenden, wie ich es oft tue, können Sie das tun. Aber das Problem liegt hier nicht bei Vue. Es liegt an JavaScript selbst und wir sind nicht hier, um das zu beheben.

Wenn wir außerdem in der Lage sind, die Ergebnisse des Renderns in 2.0, wie wir hoffen, durch Babel zu leiten, dann können Sie sogar das Nicht-TC39-getrackte Plugin verwenden, wenn Sie möchten – konsistent, überall in Ihrem JavaScript, anstatt nur in der Vorlage. Wenn Sie also nur eine Pfeife wollen, ist es wahrscheinlich, dass Sie sie haben können. Und Sie _können_ es heute in 1.x haben - seien Sie nur gewarnt, dass die Pipe, die Sie in Ihren Vorlagen verwenden würden, wahrscheinlich eine andere Priorität und ein anderes Verhalten hat als die in Ihrem Babel.

@smolinari und andere. Es gibt zwei Sätze (und Variationen davon), die ich immer wieder höre:

• "Denken Sie an die Entwickler / die Benutzerperspektive"
• "Denken Sie an Anfänger"

Beide implizieren eine Annahme - dass wir _nicht_ an diese Gruppen denken.

Ich habe dies bereits erwähnt, aber ich denke, es muss wiederholt werden. _Jeder_ im Kernteam ist entweder Designer, Frontend-Entwickler oder eine Kombination aus beidem . Wir nutzen diese Tools täglich für unsere eigene Arbeit. Wir werden auch Vue 2.0 verwenden. Glauben Sie mir, wir _denken_ daran. 😉

Was Anfänger betrifft, habe ich hier einen Fall gemacht , aber ich denke, ich werde ins Detail gehen. Ich bin Erzieher. Und ich war ein Befürworter der Eliminierung von Filtern, _denkend an Anfänger_. Ich habe persönlich Hunderten von Menschen – vielleicht sogar mehr als Tausend – beigebracht, wie man Webentwicklung praktiziert, normalerweise von Grund auf neu. Keine frühere Programmiererfahrung. Ich habe dies mit Mittelschülern, Oberschülern, Studenten, Berufstätigen und Senioren gemacht.

Aus dieser Perspektive kann ich Ihnen sagen, dass Filter zwar zunächst wie aufregende Magie erscheinen können, aber letztendlich das Lernen eines Schülers verlangsamen, indem sie für begrenzte Bequemlichkeit mehr Komplexität einführen. Wenn sie noch nie in Angular oder Vue gewesen wären und diese Konversation umgekehrt wäre – wir versuchten, sie in 2.0 _einzuführen_ – hätten wir Schwierigkeiten zu erklären, warum sie benötigt werden und wann Sie sie verwenden sollten.

Bevor in 2.0 von einer Abwertung gesprochen wurde, hatte ich Filter aus dem Lehrplan unserer Codeschule gestrichen, weil wir genug Beweise dafür gesammelt hatten, dass sie Anfängern mehr schaden als nützen. Wir möchten lieber, dass sie Erfahrungen mit vielseitigeren Vue-Funktionen wie Methoden und berechneten Eigenschaften sammeln. Wir haben sogar von der Verwendung von Filtern abgeraten, weil sie es einfacher machen, schlechte Praktiken aufzuspüren.

Hoffe, das bringt diese beiden Beschwerden ins Bett. Wir werden sehen. 😃

Aber stellen Sie sich vor, Vue hätte nie Filter gehabt. Würden Sie verlangen, dass ein Frontend-Framework die JavaScript-Syntax erweitert?

Natürlich werde ich das tun, da Filter sehr natürlich für _Vorlagen_ wie in Twig sind, die zuvor erwähnt wurden. Ich denke, dass ein Pipe-Operator so natürlich ist wie die Schnurrbart-Syntax in Templates, ich meine, Schnurrbärte sind kein HTML und kein Javascript, werdet ihr sie auch entfernen? Was ist der Unterschied mit dem Pipe-Operator?

Das Argument "denke an die Kinder" ist einfach nur dumm. Soweit ich weiß, ist Vue nicht dafür gedacht, JavaScript zu lehren, sondern für Frontend-Entwickler, um Scheiße zu erledigen. Für letzteres sind Filter super.

Wenn sie noch nie in Angular oder Vue gewesen wären und diese Konversation umgekehrt wäre – wir haben versucht, sie in 2.0 einzuführen – hätten wir Schwierigkeiten zu erklären, warum sie benötigt werden und wann Sie sie verwenden sollten.

Ich bin sehr anderer Meinung. Ich verwende seit 2005 ein Python-Framework namens Django und seine Templating-Sprache – die die Inspiration für die meisten später entstandenen Templating-Sprachen da draußen war – hatte vom ersten Tag an Filter. Nachdem ich sie über zehn Jahre lang mit Front-End-Entwicklern eingesetzt habe, weiß ich ihre Schönheit und Nützlichkeit zu schätzen. Es wäre traurig, wenn diese Syntax verschwinden würde.

(So ​​macht Django Filter: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen , bitte achte auf deinen Ton - die Argumente anderer als dumm zu bezeichnen, ist keine konstruktive Art, an einer Diskussion teilzunehmen.

Für diejenigen, die Analogien zu serverseitigen Vorlagensprachen ziehen, ist ein wichtiger Aspekt zu beachten: serverseitige Vorlagensprachen haben nicht die gleiche Flexibilität wie Vue-Vorlagen (keine berechneten Eigenschaften, begrenzte Ausdrücke). Außerdem sind sie für ganz andere Zwecke gebaut: die Ausgabe statischer Strings. Vue-Templates sind Darstellungen von interaktivem DOM – es gibt bidirektionale Bindungen, Event-Handler, Komponenten-Requisiten und mehr. Filter passen nur in einen sehr begrenzten Anwendungsfall im Vue-Kontext: Heute halte ich es für eine schlechte Idee, Filter überall zuzulassen, z. B. Filter auf v-model, v-for und v-on führen zu mehr Komplexität als Nutzen.

Eine mögliche Alternative besteht darin, Filter beizubehalten, aber nur für Textinterpolationen - dh Sie können sie nur innerhalb {{ }} s verwenden, nicht in Direktiven.

Als interessante Referenz: Angular 2 hat immer noch Filter (umbenannt in "pipes"), aber sie haben auch absichtlich die Listenfilter entfernt.

Sorry für meine Ausdrucksweise, ich will niemanden beleidigen.

Für mich _ist_ der Zweck eines Frameworks, die schwierigen Dinge zu erledigen und es für die Entwickler, die diese Tools verwenden, einfach aussehen zu lassen. Ich behaupte immer noch, dass die Syntax einfach nicht zu schlagen ist, und es wäre wieder traurig, sie verschwinden zu sehen.

Ich weiß oder verstehe nicht viel über die Mechanismen unter der Haube, aber aus Benutzersicht schlägt Praktikabilität Reinheit :)

In einer ähnlichen Notiz war es interessant zu sehen, wie viel Leidenschaft in dieser Community zu sein scheint. Für mich war Vue ein frisches und belebendes Werkzeug, vielleicht musste ich deshalb selbst an der Bemalung dieses speziellen Schuppens teilnehmen :)

Für einen anderen Datenpunkt hat Ember weder Filter noch erlaubt es Komponentenmethoden, obwohl es berechnete Eigenschaften hat.

Für den Anwendungsfall reiner Funktionen, die In-Template-Transformationen durchführen, müssen Sie einen Handlebar-Helfer / Ember-Helfer registrieren.
http://emberjs.com/api/classes/Ember.Helper.html

Lenkstangenhelfer unterscheiden sich syntaktisch von Dingen, die keine Lenkstangenhelfer sind, weshalb ich es erwähne. Das haben sie mit der Piping-Filter-Syntax gemeinsam. Handlebar-Vorlagen sind jedoch "logiklos", was bedeutet, dass sie eine spezielle Syntax für einen Funktionsaufruf innerhalb der Vorlage erfordern. Ein Problem, das Vue nicht hat.

Filter ist für Anfänger einfach, es gibt etwas Magie, wenn Sie für eine hübsche Ausgabe oder filter\ordersearch in Arrays verwenden

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}

und Leichtigkeit definieren

Vue.filter('moment', (str, format) => moment(str).format(format));

es ist einfach, übersichtlich bei Templates, für 2.x definiert man Filter im externen Modul und bekommt es in Templates

import moment from 'moment'

methods:{
   moment(date, format){
       return moment(str).format(format)
  }
}

und in Vorlage

 {{ moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss') }}

Als Vorschlag, warum nicht alte Filter in der Vorlage belassen, sondern Filter in ein separates Modul verschieben und aus dem Methodenabschnitt verwenden?

Also, wenn Sie es brauchen, tun Sie es einfach

npm install vue-utils

und verwenden Sie bestimmte Filter aus dem utils-Paket

import {moment} from 'vue-utils/date'
import {price} from 'vue-utils/numbers'

methods:{
   moment, price
}

und als gemeinsamen Filter verwenden

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}
 {{ product.price | price }}

im Ergebnis wird es in einen einfachen Funktionsaufruf übersetzt

moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss')
price(product.price)

_Notiz_
Für mich werden Filter am häufigsten zum Formatieren von Daten wie Datumsangaben, Zahlen oder Zeichenfolgen verwendet . Zum Filtern von Arrays\Objekten denke ich, dass es besser ist, berechnete und Funktionen aus dem gemeinsamen Vue-Modul zu verwenden:

import _ from 'vue-utils/array'

computed:{
   ordersTable(){
         return _(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

Leistungen:
Anfänger können alte Filter verwenden, aber in berechneten und hübschen Funktionen in ihren Vorlagen verwenden, um die Datenausgabe zu formatieren, und Programmierer können eigene Funktionsmodule dafür schreiben und die Verwendung vereinfachen.

_Warum separates Modul?_
Ich denke, es ist nicht notwendig, im Kern von Vue zu sein, aber Vue muss einige Dienstprogramme für den Entwickler-Template-Designer haben, also brauchen Sie nicht immer Lodash, Moment oder sonst, installieren Sie einfach Dienstprogramme von npm und lassen Sie es einfach verwenden, aber speichern Sie die alte Aufrufsyntax für Vorlagen.
Aber ein wichtiger Gedanke muss für Filter gemacht werden, es muss reine Funktionen geben, wie Getter in Vuex.

Es ist einfach zu unterstützen, einfach zu verwenden und zu erweitern, und es hat einen guten Blick auf Vorlagen.

Was Sie brauchen, ist ein klarer Upgrade-Pfad und der Wunsch zu lernen, wie Sie Ihren Javascript-Code modularisieren können.

@thelinuxlich Wir sprechen über Filter.

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}

nur Syntaxzucker für

{{ moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss') }}

Aber Filter komplett ausschließen für Anfänger in Vue\javascript ist schlecht. Warum Laravel-Community wie Vue? Weil es einfach und leistungsstark ist.

Wenn wir Filter vollständig entfernen, müssen Sie eine Alternative für _"Für die Vorlagendesigner"_ angeben, Sie müssen nicht wissen, wie Sie das Array sortieren oder filtern, Sie müssen nur das Codeformularbeispiel eingeben und das Ergebnis erhalten.

Programmierer müssen wissen, wie Javascript-Code _modularisiert_ wird, aber wer es für kleine Dinge verwendet, muss es nicht wissen.

Wenn wir über _"Für die Vorlagendesigner"_ sprechen, kann man einfach setzen

<script src="vue-utils.js"></script>

und Inside-Code-Nutzung

Vue.use(VueUtils)

computed:{
   ordersTable(){
         return this.utils.array(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

Aus Beispielen und stolz auf sich selbst, es ist nicht nötig, js zu kennen, um Arrays zu filtern und zu sortieren, viele Leute wollen einige Dinge tun, aber es gibt schwer zu verstehenden Code wie

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

Also keine Notwendigkeit, komplizierte Dinge für diese Art von Leuten zu machen, wenn wir dafür eine einfache Lösung bieten können und es gut für Entwickler ist.

Eine mögliche Alternative besteht darin, Filter beizubehalten, aber nur für Textinterpolationen - dh Sie können sie nur innerhalb von {{ }}s verwenden, nicht in Direktiven.

Ich denke, das könnte ein sehr guter Kompromiss sein. Es wird zwar nicht jeden zufriedenstellen, aber es ist alles, wofür ich jemals Filter verwendet habe, und ich finde es eigentlich seltsam, dass sie derzeit mehr als das können.

Es würde eine bequeme Textformatierung ermöglichen, wenn Sie Filter verwenden und die Komplexität reduzieren möchten, indem Sie Zwei-Wege-Filter effektiv entfernen.

Meiner Meinung nach gibt Ihr Momentjs-Filterbeispiel bereits zu viel Logik an die Vorlagen weiter.

Im Ernst, Sie sollten all diese "Pipe Love" in das Spec-Repository leiten, bis sie TC39 erreicht :)

Mir gefällt, was sowohl @yyx990803 als auch @VitaliyLavrenko vorgeschlagen haben. Das könnte ein guter Mittelweg sein.

Scott

Ich mag den Vorschlag von

@thelinuxlich

Was gibt es Besseres zum Lesen?

<div v-for="thing in things | filterBy 'foo' | orderBy 'bar' | limitBy 5">

oder

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

Denken Sie als Entwickler und fragen Sie jemanden, der kein Javascript kennt.

Was mich betrifft, für _Nicht-Entwickler_ besser so etwas:

Vue.use(VueUtils)

computed:{
   ordersTable(){
         return this.utils.array(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

Es ist mittel und wird wie Vue-Ressource, nur Common Lib, verwendet.

Über Pipe, ich es ist Syntaxzucker

Sache in Sachen | filterBy 'foo' | orderBy 'bar' | limitBy 5

Pro

thing in limitBy(orderBy(filterBy(things, 'foo'), 'bar'), 5)

Welche Leichtigkeit zu lesen?

Wenn Sie Daten an 2 Diff-Vorlagen übergeben müssen, speichern Sie 2 oder 3 Änderungen für eine Daten?

Wenn es so etwas wie:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

I'ts abstrakte Situation, aber wenn es in einer oder zwei Vorlagen verwendet wird? Sie benötigen Lagerdaten für 10 oder 100 Objekte? Speicherauslastung erhöhen? Ja, wir können die Hilfsmethode verwenden und sie in der Vorlage verwenden, aber für _"Für die Vorlagendesigner"_, die weit weg von Javascript sind, ist etwas wie Titel | besser padLeft 10 und es sollte in Funktionsaufruf übersetzt werden, es ist einfach und funktional.

Denken Sie an unterschiedliche Leute, Entwickler können es auf unterschiedliche Weise vereinfachen, aber andere Leute möchten es einfach machen.

Ich sage es noch einmal, zu viel Logik in Vorlagen ist ein Anti-Muster. Anstatt eine bestimmte DSL (Filter) lernen zu müssen, sollten Sie Javascript lernen.

@thelinuxlich Verwenden Sie einfach JSX und wir erhalten React mit 2-Wege-Bindung und einigen anderen Dingen.

Aber mit Vue bekommen wir Leute, die kein Javascript kennen, aber mit Google etwas tun können, und wenn Sie Pipe nicht mögen, verwenden Sie es nicht. Wir können einfach etwas hinzufügen wie

Vue.config.pipeFuncCall = true

Und Sie können es ein- und ausschalten, aber für manche Leute ist es einfach.

_Ich sage es noch einmal, nicht nur JS-Entwickler können Vue verwenden, es ist die stärkste Seite von Vue._

Standardmäßige allgemeine Filter müssen vorhanden sein, aber es ist besser, sie in einer separaten Bibliothek zu haben und sie einfach zu vue hinzuzufügen und zu verwenden.

Oder möchten Sie, dass Vue so etwas wie ASM ist und nur gute Entwickler es verwenden können?

Leute, ich denke, die Entscheidung des Vue-Kernteams wurde sehr gut erklärt. Können wir nicht immer wieder dasselbe wiederholen und nur mit etwas Neuem, Wertvollem kommentieren, wenn überhaupt?

Wenn es Teil der Vue-Kernprinzipien ist, für Nicht-JS-Entwickler einfacher zu sein, auch wenn es den Sprachprinzipien schadet, dann werde ich Ihnen zustimmen, aber wahrscheinlich ist es nicht der Fall.

Wie ich bereits sagte, bin ich meistens damit einverstanden, dass Filter veraltet sind, ich werde sie wegen ihrer Bequemlichkeit sicherlich vermissen, aber ich bin mehr als sicher, dass ein sehr ähnliches Filtersystem als Plugin eingeführt werden kann.

Ich habe etwas früher ein Proof-of-Concept-Beispiel gegeben, das sowohl in berechneten Requisiten als auch inline verwendet werden könnte

<ul>
    <li v-for="item in f(items).filterBy(foo).orderBy(bar).limitBy(5).apply()">
        {{ item.foo }}
    </li>
</ul>

Andererseits bin ich mir sicher, wenn jemand die Pfeife haben möchte, dass es mit so etwas geht

<ul>
    <li v-for="item in p(items, 'filterBy foo | orderBy bar | limitBy 5')">
        {{ item.foo }}
    </li>
</ul>

Oder vielleicht, wenn es einen Hook geben würde, der es Plugins erlaubt, Ausdrücke zu parsen und sie so zu verarbeiten, wie sie wollen, könnte das auch ein möglicher Weg sein, aber das hängt nur davon ab, wie komplex es ist, es zu implementieren, und welche Auswirkungen es haben würde auf den Rahmen (Leistung/Größe), und ob @yyx990803 tatsächlich in diese Richtung gehen möchte oder nicht!

Ich denke, wenn wir elegante Alternativen bekommen, die einfach zu bedienen sind (Plugins oder etwas im Kern), werden wir uns ziemlich schnell daran gewöhnen.

@ rigor789 zum Filtern von Arrays und Sortieren usw. Verwenden Sie besser berechnet, es ist viel sauberer. Aber ich denke, dass es ein Problem gibt, Daten im Diff-Format anzuzeigen:

Wenn wir das Feld created_at haben und es in der Vorlage als dd.mm.YYYY oder in Links darstellen müssen

<a href="dd">dd</a>.<a href="mm">mm</a>.<a href="YYYY">YYYY</a>

Für diese Filter, die jetzt gut verwendet werden, welche Alternative können wir von 2.x bekommen?

Vorerst nur verwenden

 {{ date(created_at, 'dd') }}

und definieren Sie die Datumsmethode, aber es macht die Vorlage schmutzig, wenn Sie zusätzliche 3 Felder speichern, kostet es Speicher, und wenn es 100-200 Objekte sind, wird es schwer.

Hier die endgültige Entscheidung:

1. Filter werden unterstützt, aber nur innerhalb von Textinterpolationen. Dies beschränkt sie auf Textformatierungszwecke, während andere Logik in JavaScript erzwungen wird.
2. Vue 2.0 wird ohne eingebaute Filter ausgeliefert. Die Community kann bei Bedarf ihre eigenen Filterpakete erstellen.
3. Die Filtersyntax wird geändert, um Funktionsaufrufsyntax für Argumente anstelle von Leerzeichen zu verwenden. Dies bringt es mehr in Einklang mit JavaScript und anderen gängigen Templating-Sprachen (Jinja2, swig, twig...):

html {{ date | formatDate('YY-MM-DD') }}

Danke, dass du zugehört hast, Evan. Das macht Vue großartig. Es hat einen großartigen Anführer. :Lächeln:

Scott

@yyx990803 & @chrisvfritz

Eine Sache, die in dieser Diskussion begraben zu sein scheint, sind Zwei-Wege-Filter. Zwei-Wege-Filter sind diejenigen, die am schwierigsten mit anderen vorgeschlagenen Lösungen zu replizieren sind.

1. Betrachten Sie dieses einfache Beispiel , das ich in diesem Forumsthread gepostet habe. Die Verwendung berechneter Eigenschaften dafür hätte zwei Hauptnachteile:
   
   
   
   1. Sie müssen für jeden Wert eine neue berechnete Eigenschaft erstellen, was zu einer Menge Boilerplate-Code führt.
   
   
   2. Erschwerend kommt hinzu, dass berechnete Eigenschaften nicht einmal verschachtelt werden können. Wenn Sie ein komplexeres Objektdiagramm haben, müssen sich alle Ihre berechneten Eigenschaften auf der obersten Ebene befinden. Sie würden mit langen, ausführlichen Eigenschaftsnamen enden, die mehr kognitive Überlastung erfordern, um ständig nachzuverfolgen, welche berechnete Eigenschaft welchen verschachtelten Wert verfolgt.
   
   

Diesen Anwendungsfall als „trivial“ oder „weniger kompliziert“ abzutun, ist kontraproduktiv. Ich habe dies sowohl für mittlere als auch für große Anwendungen verwendet. Es hat Wunder gewirkt! Die Demo ist notwendigerweise einfach, aber die Technik ist solide.

1. Dies wird weiter verwechselt, wenn es um ein Array in v-for geht, wie in diesem Beispiel (wieder absichtlich einfach). Wenn Sie über ein Array iterieren, finden Sie keinen Rückgriff auf berechnete Eigenschaften. Die einzige Möglichkeit, dies zu umgehen, besteht darin, für jedes Element im Array eine separate Komponente zu haben und noch mehr Boilerplate hinzuzufügen.

Vergleichen Sie dieses Beispiel mit Filtern:

``` js
Importieren Sie die Währung aus dem 'Einige-Währungs-Filter';
Produkte aus 'Produkte-Stub' importieren;

neuer Vue({
el: document.body,
Daten: { Produkte },
Filter: { Währung },
});
```

Zu einem ohne Filter:

``` js
Importieren Sie die Währung aus dem 'Einige-Währungs-Filter';
Produkte aus 'Produkte-Stub' importieren;

neuer Vue({
el: document.body,
Daten: { Produkte },
Komponenten: {
Produkt: {
Requisiten: ['Produkt'],
berechnet: {
Preis: {
werden() {
return currency.read(this.product.price);
},
set(wert) {
this.product.price = currency.write(value)
}
},
Versand: {
werden() {
return currency.read(this.product.shipping);
},
set(wert) {
this.product.shipping = Währung.Schreiben (Wert)
}
},
Handhabung: {
werden() {
return currency.read(this.product.handling);
},
set(wert) {
this.product.handling = währung.write(value)
}
},
Rabatt: {
werden() {
return currency.read(this.product.discount);
},
set(wert) {
this.product.discount = währung.write(value)
}
}
}
}
}
});
```

Ich weiß, welche der oben genannten ich schreiben möchte.

_{(Dies könnte vielleicht ein wenig aufgeräumt werden, indem berechnete Eigenschaftsfabriken erstellt werden, aber der Punkt bleibt, dass diese weitaus ausführlicher sind als nötig.)}

Da das Kernteam standhaft gegen die Filter-Pipe-Syntax zu sein scheint, wäre es möglich, einen filter -Parameter für die v-model -Direktive einzuführen?

Mit einem filter -Parameter können wir die erste elegante Version des obigen JS beibehalten und einfach die Vorlage umschreiben, um den Parameter anstelle der Magic-Pipe-Syntax zu verwenden:

<tr v-for="product in products">
  <td><input type="text" filter="currency" v-model="product.price"></td>
  <td><input type="text" filter="currency" v-model="product.shipping"></td>
  <td><input type="text" filter="currency" v-model="product.handling"></td>
  <td><input type="text" filter="currency" v-model="product.discount"></td>
</tr>

Dies würde die richtige Balance finden, keine magische Syntax zu haben und gleichzeitig die Möglichkeit zu behalten, Eingaben ohne viel Textbausteine ​​einfach hin und her zu konvertieren.

Vielen Dank dass Sie darüber nachdenken.

Ich habe Ihr Beispiel umgeschrieben, um Ihren Filter als benutzerdefinierte Direktive einzubinden: jsfiddle .
Obwohl nicht so prägnant wie ein Filter, ist es bei weitem nicht so schmerzhaft, wie ich es mir vorgestellt habe. Und es hat mich nicht viel Zeit gekostet, die Teile aus Dingen zusammenzusetzen, die uns allen bereits zur Verfügung stehen.

@Nirazul wurde bereits vorgeschlagen , dedizierte Anweisungen für jeden Filter zu erstellen. Es ist einfach absurd, eine neue Anweisung erstellen zu müssen, die die gesamte v-model -Funktionalität für jeden Filtertyp, den Sie in Ihrer App verwenden, neu implementiert.

Darüber hinaus funktioniert Ihre Direktive nicht einmal vollständig wie Filter. Wenn Sie das Feld nach dem Ändern des Werts unkenntlich machen, wird es nicht neu formatiert. Darüber hinaus macht v-model viel mehr als Sie in dieser Direktive tun.

Die Richtlinie kann natürlich durch weitere Funktionen und Korrekturen ergänzt werden, aber der Punkt bleibt: Dies sind alles Pflaster auf etwas, das von Anfang an wirklich einfach sein sollte.

Ich habe in diesem Thread keinen Vorschlag gesehen, der benutzerdefinierte Direktiven erwähnt. Würden Sie mich bitte auf diesen Kommentar hinweisen?

Wie Sie sich vorstellen können, habe ich es nicht geschrieben und getestet, damit Sie es in Ihrer App verwenden können. Ich wollte nur zeigen, was derzeit alternativ möglich ist. Wenn dies so einfach möglich ist, ist vielleicht Platz für ein Plugin, um den Prozess noch mehr zu automatisieren.
Es ist offensichtlich, dass dieser schnell geschriebenen Richtlinie die volle Funktionalität von v-model fehlt. Vielleicht würde eine benutzerdefinierte Filterdirektive in Kombination mit Parametern und/oder Modifikatoren ausreichen, um Filter zu ersetzen.

Bleiben wir konstruktiv, denn ich habe versucht, Ihr Problem zu lösen. Es ist immer einfacher, auf eine Lösung einzuschwören, anstatt einen Beitrag zu leisten und voranzukommen.

@JosephSilber , du musst dich entspannen. "absurd" ist ein starkes Wort.

Hallo, ist das Entfernen des Filters motiviert durch das Reduzieren von Template-Cluttering oder hat es ernsthafte Auswirkungen?
die technische Umsetzung von 2.0? Wenn es sich um ein früheres Problem mit visuellen Effekten handelt, wie wäre es, wenn Sie dies zulassen
Filter wie jetzt (aber mit dem neuen Javascript-Formular)
aber nur auf einen pro Ausdruck beschränken, wie v-for="i of list | orderBy('key')", (nicht mehr als ein Pipe-Zeichen)
Dies könnte die Filterverarbeitung in 2.0 einfacher und vorhersehbarer und visuell am wenigsten überladen machen.
Da es eine Filteranalyse für {{}} geben wird, wäre es sinnvoll, sie in anderen Ausdrücken zuzulassen.
dies würde alle bestehenden Anwendungsfälle/Funktionen (wie Zwei-Wege-Filterung, Element innerhalb von v-for) berücksichtigen.
Bestehende Verwendungen von mehr als einem Filter könnten von Eigentümern leicht zu einem zusammengeführt/aufgerüstet werden.

@tomsmithgroup Was Sie vorgeschlagen haben (und mehr als das), wurde entschieden , in 2.0 unterstützt zu bleiben.

@yyx990803 & @chrisvfritz würden gerne Ihre Meinung zu Zwei-Wege-Filtern hören.

@JosephSilber Also mit der berechneten Eigenschaftsfabrik, auf die Sie

import currenciesFactory from 'some-computed-currencies-factory'
import products from 'products-stub'

new Vue({
  el: 'body',
  data: { products },
  components: {
    product: {
      props: ['product'],
      computed: currenciesFactory(['price', 'shipping', 'handling', 'discount'])
    }
  }
})

Obwohl ich persönlich keine Fabrik für dieses Beispiel erstellen würde, da jede dieser Eigenschaften tatsächlich separate Anliegen sind, die im Moment nur gleich _scheinen_. Wenn Sie Filter entfernen, wird deutlicher, wie komplex diese eine Komponente war. Das ist, was Sie als Boilerplate sehen.

Und das ist ein wichtiger Grund, warum Komponenten _existieren_. Komplexität in überschaubare Anliegen zu unterteilen. Wenn ich mir eine Komponente anschaue, muss alles, was sie tut, problemlos in mein Arbeitsgedächtnis passen, sonst wird die Entwicklung viel langsamer und fehleranfälliger. Das Verstecken von Komplexität hinter der Syntax von Filtern beseitigt diese Komplexität nicht.

Um dies zu demonstrieren, schauen wir uns an, was passiert, wenn das Problem auf sich ändernde Anforderungen in der realen Welt trifft: Angenommen, Sie entscheiden, dass der Rabatt nicht größer sein darf als der Preis + Versand + Handhabung. Oder die Handhabung sollte den Betrag X nicht überschreiten. Oder das Rabattfeld sollte ein Prozentsatz statt einer Währung sein. Oder wenn die Summe einen bestimmten Betrag überschreitet, soll automatisch ein Mindestrabatt gewährt werden.

Sie könnten versucht sein, den Filter mit zusätzlichen Optionen und bedingter Logik komplexer zu gestalten. Wenn Sie die API und die interne Logik des Filters aktualisieren, müssen Sie jetzt darüber nachdenken, wie sich Ihre Änderungen auf alles andere auswirken könnten, das den Filter verwendet – möglicherweise sogar außerhalb der aktuellen Komponente, wenn es sich um einen gemeinsam genutzten Filter handelt. Jetzt befinden Sie sich also in einer Situation, in der das Vornehmen von Änderungen an Ihrer App entmutigend wird. Und das alles, weil ein gemeinsam genutzter Zweifilter es Ihnen ermöglicht hat, den internen Komponentenstatus nach außerhalb der Komponente zu delegieren, Komponentengrenzen zu verletzen, die Kopplung zu erhöhen und die Komplexität zu verbergen, an die Sie immer noch denken müssen, wenn Sie an der Komponente arbeiten.

Indem Sie Dinge in mehrere, individuell weniger komplexe Komponenten mit separat definierten berechneten Eigenschaften oder gebundenen Requisiten aufteilen, aktualisieren Sie häufig eine Zeile, um sie an eine sich ändernde Anforderung anzupassen. Keine zusätzlichen Optionen oder Bedingungen. Kein Refactoring, um der Skalierungskomplexität gerecht zu werden. Sie müssen an nichts außerhalb der Komponente _oder sogar außerhalb dieser einzelnen Eigenschaft_ denken. Ihre Anwendung war von Anfang an und bleibt einfach zu überdenken und zu aktualisieren.

Ich denke, was Filter in diesem Fall zunächst verführerisch macht, ist, dass sie ein leicht zu erreichendes Heilmittel gegen Duplizierung sind. Aber Duplizierung ist kein Boilerplate, wenn es zufällig ist (dh der Code ist gerade jetzt zufällig derselbe, bevor die realen Probleme unvermeidlich anfangen zu rollen).

Und ich kann es nicht besser ausdrücken als Sandi Metz:

Vervielfältigung ist viel billiger als die falsche Abstraktion

@chrisvfritz Filter haben absolut nichts mit geschäftlichen Anforderungen zu tun. Filter formatieren lediglich die Daten. Das ist es. Sie manipulieren es in keiner Weise, Gestalt oder Gestalt. filter="currency" ist konzeptionell dasselbe wie der Parameter number . Geschäftsanforderungen sollten natürlich niemals in den Filtern behandelt werden.

Angenommen, Sie entscheiden, dass der Rabatt nicht größer sein darf als der Preis + Versand + Handhabung. Oder die Handhabung sollte den Betrag X nicht überschreiten.

Dann würden Sie ein geeignetes Validierungsmodul verwenden, à la vue-validator . Der Währungsfilter bleibt trotzdem bestehen und zeigt einfach den zugrunde liegenden Wert an.

das Rabattfeld sollte ein Prozentsatz sein, statt einer Währung.

Dann ist sein Typ offensichtlich keine Währung mehr. Nicht anders, als wenn Sie type="text" gegen type="email" austauschen, wenn sich die Anforderungen an den Benutzernamen ändern. Oder sogar, wenn Sie den Parameter number entfernen, wenn ein Feld keine Zahl mehr ist.

Wenn die Summe einen bestimmten Betrag überschreitet, sollte automatisch ein Mindestrabatt angewendet werden.

Auch hier wird das Minimum angewendet, aber der Währungsfilter bleibt bestehen. Sie möchten es immer noch als Währung anzeigen.

Wenn Sie die API und die interne Logik des Filters aktualisieren, müssen Sie jetzt darüber nachdenken, wie sich Ihre Änderungen auf alles andere auswirken könnten, was den Filter verbraucht

Nein. Sie fügen _nie_ irgendeine Logik oder einen Zustand in den Filter selbst ein. Der Filter ist eine idempotente Funktion ausschließlich zum Formatieren von Werten. Idealerweise sollte es nicht einmal im Kontext der VM ausgeführt werden ; es sollte keine this haben, aus denen zusätzliche Daten abgerufen werden können.

Vervielfältigung ist viel billiger als die falsche Abstraktion

... wenn Sie, wie Sie sagten, Code abstrahieren, der gerade zufällig derselbe ist. Filter hingegen sind einfache idempotente Funktionen, die einen Wert formatieren. Sie sind überhaupt keine Abstraktion.

tl;dr -Filter sind keine Abstraktion und ersetzen keine expliziten Geschäftsanforderungen. Filter haben nie eine interne Logik und sollten es auch nie. Sie ähneln konzeptionell dem HTML-Attribut type und dem Parameter number v-model $ .

Zwei-Wege-Filter ist sicherlich eine Abstraktion. Das aktuelle Verhalten von Zwei-Wege-Filtern auf v-model verbirgt viel Magie im Inneren - insbesondere ermöglicht es, dass der DOM-Wert der Eingabe vorübergehend nicht mit dem zugrunde liegenden Modell synchronisiert ist, und "synchronisiert" sie nur, wenn Sie dies tun das Feld verwischen. Übrigens, @JosephSilber, dieses Verhalten wurde speziell aufgrund Ihrer Anfrage implementiert, daher kann ich verstehen, warum Sie sich so sehr dafür

Das größte Problem, das ich bei Zwei-Wege-Filtern sehe, ist jedoch, dass die zugrunde liegende Logik eine Black Box ist und der Benutzer keine Möglichkeit hat, sie weiter anzupassen, außer Feature-Anfragen zu stellen. Für mich ist es die bessere Option, die richtigen Bausteine ​​​​zur Verfügung zu stellen, um ein solches Verhalten selbst umzusetzen. Und lassen Sie mich Ihnen zeigen, wie das in 2.0 möglich ist:

https://jsfiddle.net/yyx990803/5bnu6xb6/

Hier haben wir eine CustomInput Basiskomponente, die das „Out-of-sync-until-blur“-Verhalten aktueller Zwei-Wege-Filter implementiert. Aufgrund der Änderungen in 2.0 können Sie v-model direkt für benutzerdefinierte Komponenten verwenden, solange die Komponente eine value Prop akzeptiert und input Ereignisse ausgibt. Darüber hinaus formatiert es auch den Wert von change Ereignissen, was derzeit mit Zwei-Wege-Filtern nicht möglich ist . Sie können diese Komponente weiter optimieren, um jedes gewünschte Verhalten zu erhalten, ohne an die Implementierung von Zwei-Wege-Filtern durch das Framework gebunden zu sein.

Die Basiskomponente implementiert die Analyse-/Formatierungslogik nicht – Sie erweitern sie mit den Methoden parse und format , um benutzerdefinierte Eingabekomponenten zu erhalten, die auf bestimmte Anwendungsfälle zugeschnitten sind. In diesem Fall eine CurrencyInput Komponente.

Die Basiskomponente ist komplexer als Zwei-Wege-Filter, weil wir das vorherige magische Verhalten jetzt selbst implementieren. Sie müssen diese Komponente jedoch nur einmal definieren. Im Gegenzug erhalten Sie die volle Kontrolle darüber, wie es sich verhalten soll, falls Sie es später ändern möchten. Ich glaube, das ist ein würdiger Kompromiss.

Dies ist ein Beispiel dafür, wie wir mehr in Komponenten denken sollten, da es sich um eine einheitliche Abstraktion für die Wiederverwendbarkeit handelt, die Ihnen die größte Kontrolle gibt. Siehe auch das 2.0- Beispiel select2 - zuvor war dies in 1.0 als Direktive implementiert, aber jetzt ist es eine Komponente mit derselben v-model Schnittstelle.

Für mich ist es die bessere Option, die richtigen Bausteine ​​​​zur Verfügung zu stellen, um ein solches Verhalten selbst umzusetzen.

Das ist großartig und definitiv das, was Vue braucht, aber ich hätte es gerne gelesen

Für mich ist es die bessere Option, die richtigen Bausteine ​​bereitzustellen, um mit Vue zu beginnen und Vue auch selbst mit neuem Filterverhalten zu erweitern.

Mit anderen Worten, könnte die Währungseingabekomponente zusammen mit einer Reihe anderer Standardfilterkomponenten nicht Teil von Vue sein? Denn jeder benutzt irgendwann Währungen, oder? Warum es anderen überlassen, immer wieder die gleiche Arbeit zu erledigen? Die Währungsformatierung ist Standard genug, um sie zu einem Teil von Vues eigener Toolbag für Filterkomponenten zu machen, und sie sind ein großartiges grundlegendes Beispiel für andere, um zu lernen, wie sie ihre eigenen Filterkomponenten erstellen können.

Und.....nur eines fehlt dem Beispiel als fertige Währungseingabekomponente und das ist ein i18n-Feature, was meiner Meinung nach auch Vue mitbringen sollte. Die Formatierung der Währungszahlen sollte sich abhängig vom ausgewählten Gebietsschema der Person (des Betrachters) ändern. Ich meine Gebietsschemadaten, dh . "DE_de", um die Währung und andere Zahlen wie in diesem Locale Explorer (der aus einem Standard stammt) zu formatieren. Fügen Sie das in Vue hinzu und Sie haben ein großartiges Komponentensystem zur Währungs-/Zahlenformatierung, das direkt in Vue integriert ist, das die Tausenden von anderen Entwicklern, die Vue verwenden, nicht selbst erstellen müssen, sondern direkt verwenden können, wenn sie Vue erhalten . Dies macht Vue zu einem leistungsstarken Templating-System!

Wenn die Verwendung dieser "i18n-Formatierungskomponente" nicht verkettbar als Filter wie in 1.0 verwendet werden kann, sollte sie einsteckbar sein. Das wäre auch in Ordnung. Das macht Aurelia und das macht auch Twig mit seinen Erweiterungen . Die Währungseingabekomponente könnte immer noch <currency-input> sein.

Dieser i18n und andere Standard-Vorlagenfilter müssen wirklich etwas sein, das andere nicht ständig reproduzieren müssen, wenn sie es nicht müssen. Wenn Sie mir zeigen, wie man ein solches Plug-in erstellt, würde ich sogar das i18n-Plug-in für Sie erstellen. Das interessiert mich total! :smile:

Scott

Denn jeder benutzt irgendwann Währungen, oder?

Nicht wirklich, nein. Ich zum Beispiel habe es nie wirklich benutzt :) Dasselbe würde für alle anderen eingebauten Filter gelten – einige von ihnen sind für einige von uns nützlich, während die anderen einfach nutzlos sind. Da wir gerade bei diesem Thema sind, wollte ich meistens einen eingebauten Filter verwenden, aber am Ende habe ich sowieso meine eigene Version geschrieben und den Code der eingebauten Version tot gerendert.

ein i18n-Feature, das meiner Meinung nach auch Vue beinhalten sollte.

Dies ist wiederum sehr umstritten. Eine umfassende i18n-Unterstützung kann ziemlich komplex sein und gehört meiner Meinung nach nicht zu Vue, insbesondere wenn die meisten Benutzer sie sowieso nicht benötigen.

Nun möchte ich Folgendes ansprechen: Jedes Mal, wenn wir versuchen, einen Vergleich zwischen Vue und einem anderen Template/Framework anzustellen, gibt es eine wichtige Sache zu beachten: Im Gegensatz zu Django/Laravel/Twig ist Vue im Wesentlichen eine Client-Bibliothek und somit muss so leicht wie möglich sein. Es wäre sinnvoller, es einfach genug zu halten – natürlich unter Beibehaltung aller _Kern_-Funktionen – anstatt „Features“ und „Utilitys“ hinzuzufügen, nur um der sogenannten „Nützlichkeit“ oder „Eleganz“ willen. Wenn Sie etwas anderes als die Kernfunktionen wünschen, wäre es besser, ein Plugin zu verwenden oder sogar Ihr eigenes zu entwickeln. Nehmen Sie dies als Beispiel: Ist i18n/currency für ein häufig gesehenes SPA wichtiger als ein Router oder ein State Manager? Ich glaube nicht. Und doch gehören vue-router und vuex nicht in Vue, sondern haben eigene Repositories. Mit anderen Worten, Vue ist progressiv .

Wenn Sie mir zeigen, wie man ein solches Plug-in erstellt, würde ich sogar das i18n-Plug-in für Sie erstellen. Das ganze interessiert mich so sehr!

Ich halte dies für einen vernünftigeren Ansatz und danke Ihnen für Ihr Interesse :)

Wenn in einigen Bereichen viel i18n verwendet werden muss)) Ich denke, ich kann in den Code gehen und ein paar Namen einiger Dinge manuell ändern, der Schönheit halber.
Zum Beispiel: Vor ein paar Stunden brauchte ich butstrap.datepikker - ich verbinde mich nicht, i18n, obwohl es eine solche Möglichkeit gibt. Schnell 60 Sekunden. "Manuell" ersetzte die Namen der Wochentage und Monate, und alles - ok! ))

@phanan - Ihre Argumentation ist der Grund, warum ich "Plugins" erwähnt habe. Ich stimme zu, nicht jeder wird die Währungs- oder i18n-Funktionalität wollen und diejenigen, die dies nicht tun, können ihre App leicht halten, aber als Templating-System glaube ich (und das ist sehr meine persönliche Meinung), dass Vue auch solche Standardfunktionen zur Verfügung haben sollte auch. Noch wichtiger und meine Sorge ist, dass nicht jeder die i18n- oder Währungsfilter-Komponentenräder neu erfinden muss. Mit anderen Worten, genauso wie Vue-Router und Vuex verfügbare Ergänzungen zu Vue sind, könnte es auch eine gute Anzahl von Standardfiltern wie Währung und i18n sein.

Oh, und interessanterweise scheint Angular i18n eingebaut zu haben.

https://docs.angularjs.org/guide/i18n

Angular unterstützt i18n/l10n für Datums-, Zahlen- und Währungsfilter.

Ember und React scheinen den Weg „Lass die Entwicklerwelt es selbst machen“ gegangen zu sein.
Interessantes Video.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Vielleicht braucht Vue nur eine Integration zu FormatJS? VueIntl? :Lächeln:

Edit: So einfach kann es doch nicht sein, oder? https://github.com/learningequality/vue-intl/blob/master/index.js

Scott

Angular hat anscheinend i18n eingebaut.

Angular wird auch mit ng-router geliefert, der, wie ich gehört habe, von der ng-community zugunsten von ui-router gemieden wird.

Wenn das Angular-Team nun ng-router durch ui-router ersetzt, führt dies zu bahnbrechenden Änderungen und Schmerzen.

wenn sie versuchen, den ng-router zu verbessern, verschwenden sie ihre zeit, da es bereits eine bessere lösung (ui-router) gibt.

Wenn Vue anfing, i18n, Währung usw. in seinem Kern zu unterstützen, wird die gleiche Situation auch mit Vue passieren.

Ich finde die eingebauten Filter praktisch, aber in dieser Angelegenheit stimme ich dem vuejs-Team zu.

Dann sind wir uns alle einig, dass die Filter nicht im Vue-Kern enthalten sind. Ich bin eigentlich auch ein Fan der Komponentisierung. Aber könnte Vue die Filter nicht auch als Kern-Plugins anbieten? Wie Vuex und Vue-Router?

Scott

Aber könnte Vue die Filter nicht auch als Kern-Plugins anbieten? Wie Vuex und Vue-Router?

Genau das hat @blake-newman vorhin geteilt .

Hallo: Die endgültige Entscheidungsseite gab an, dass nur Filter für Text erlaubt sind
Anzeige {{}} (V-Text)
nicht für andere Ausdrücke wie v-for="item of list | sortBy"
Oder habe ich das falsch verstanden?
Was ich meinte, war, Filter wie in 1.0 zu haben, aber nur einen Filter einzuschränken
pro Ausdruck

Am Sonntag, den 1. Mai 2016 um 22:24 Uhr schrieb Phan An [email protected] :

@tomsmithgroup https://github.com/tomsmithgroup Was Sie vorgeschlagen haben
(und mehr als das) sind entschieden
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 an
werden in 2.0 weiterhin unterstützt.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@yyx990803 Darf ich aus Ihrer Antwort schließen, dass Zwei-Wege-Filter in 2.0 nicht unterstützt werden?

@fnlctrl das ist richtig. Bauen Sie einfach Ihre eigenen Komponenten.

Ich werde ein wenig vom Thema abschweifen: Sind diese Zwei-Wege-Filter wirklich so nützlich in der Produktion?
Ich meine, ist es wirklich in Ordnung, Benutzer etwas in eine Eingabe eingeben zu lassen und sie dann neu zu formatieren, nachdem sie unkenntlich gemacht wurde?
Mein Business-Team verlangt von unseren Eingaben immer, dass sie sich so verhalten : Sie können einfach nichts falsch eingeben. Sogar jetzt mit Vue verwenden wir jquery.inputmask für diesen Zweck, da die sofortige Zwei-Wege-Änderung veraltet ist (das vermisse ich wirklich ...)
Ich meine, gibt es wirklich ein Problem mit diesen Zwei-Wege-Filtern oder denken die Leute nur darüber nach? :)

@fullfs Zwei-Wege-Filter werden in unserer Produktions-App (viele <input> s) der Einfachheit halber ausgiebig verwendet, aber wie ich es jetzt sehe, warum die Werte in Echtzeit filtern, anstatt sie nur einmal zu filtern, bevor sie es sind POST-ed an den Server? Es wird einige Zeit dauern, den Code umzugestalten, aber ich denke, ich werde sie nicht vermissen :D

Wenn Sie eine optimistische Aktualisierung der Benutzeroberfläche wünschen (was meiner Meinung nach heute die Norm ist, insbesondere für Mobilgeräte), möchten Sie, dass die Eingabe praktisch zum Zeitpunkt der Eingabe richtig formatiert ist.

Scott

2-Wege-Filter sind wirklich schön in vue. Sie können jederzeit Ihre eigenen kundenspezifischen Komponenten bauen, mit oder ohne verfügbare Filter, aber das braucht Zeit. Die Bibliothek sollte Flexibilität bieten, aber auch eine schnellere und bequemere Möglichkeit, Dinge zu erledigen. Das Einbeziehen von 2-Wege-Filtern würde die Leute nicht davon abhalten, ihre eigenen Komponenten zu bauen, wenn es sein muss, aber es würde eine schnellere Entwicklung ermöglichen, wenn die vorhandene Funktionalität den Anforderungen entspricht, was meistens der Fall ist. Es ist immer ein Kompromiss zwischen API-Oberfläche und Komfort. Das Gleichgewicht muss gefunden werden, und Vue hatte bereits ein großartiges. Filter loszuwerden scheint ein Schritt zurück vom richtigen Gleichgewichtspunkt zu sein. Die Bibliothek wird kleiner, aber die Codebasis und Boilerplate aller Projekte, die sie verwenden, wird größer.

Wenn Filter wirklich veraltet sein sollen, wäre es vielleicht gut, eine Alternative bereitzustellen, mit der Sie auf einfache Weise einen Parser und einen Formatierer für v-Modell-Direktiven angeben können. Mit Filtern können Sie nur diesen Teil des Beispiels @yyx990803 schreiben:

const CurrencyInput = CustomInput.extend({
  methods: {
    parse(val) {
      var number = +val.replace(/[^\d.]/g, '')
      return isNaN(number) ? 0 : number
    },
    format(val) {
      return '$' + Number(val).toFixed(2)
    }
  }
})

Ohne 2-Wege-Filter muss man auch schreiben

const CustomInput = Vue.extend({
  template: `
    <input type="text"
      @focus="onFocus"
      @blur="onBlur"
      @input="onInput"
      @change="setDisplayValue">
  `,
  props: ['value'],
  watch: {
    value() {
      if (!this.focused) {
        this.setDisplayValue()
      }
    }
  },
  ready() {
    this.setDisplayValue()
  },
  methods: {
    onInput() {
      this.$emit('input', {
        target: {
          value: this.parse(this.$el.value)
        }
      })
    },
    onFocus() {
      this.focused = true
    },
    onBlur() {
      this.focused = false
      this.setDisplayValue()
    },
    setDisplayValue() {
      this.$el.value = this.format(this.value)
    }
  }
})

Also mehr Flexibilität, aber auch mehr Code für das gleiche Ergebnis.

@aristidesfl - Filter sind nicht veraltet. Wir haben den Kampf teilweise gewonnen. LOL! Sie werden darauf beschränkt sein, nur in Textinterpolationen verwendet zu werden. Siehe hier: https://github.com/vuejs/vue/issues/2873

Scott

Danke @smolinari . Ich bezog mich jedoch insbesondere auf 2-Wege-Filter.

bitte komm zurück! Wir brauchen es, ich stimme allem zu, was Sie gesagt haben. aber es ist so einfach, wir sind faule Benutzer, wir wollen nur einen faulen, einfachen Weg. genau wie Keep-Alive.

Möglicherweise sollte es eine Möglichkeit geben, benutzerdefinierte V-Modell-Modifikatoren hinzuzufügen (http://rc.vuejs.org/guide/forms.html#Modifiers)

Sie wirken wie Zwei-Wege-Filter.

@ecmel stimmte zu. Dies ist der richtige Weg.

Öffne dann ein Feature-Request-Problem :)

@ecmel Eine ähnliche Idee, obwohl als Typmodifikatoren beschrieben, wurde hier diskutiert.

@rpkilby Diese Diskussion ist ebenfalls geschlossen, vielleicht sollten wir eine neue für benutzerdefinierte V-Modell-Modifikatoren eröffnen.

Kann das nicht mehr:

<span :title="item.Modified | date('dd-mmmm-yyyy H:MM:ss')">{{item.Modified | date('dd-mmmm-yyyy')}}</span>

Das Beschränken von Filtern auf {{ }} scheint seltsam, es kommt oft vor, dass Sie einen Filter in einer Attributbindung verwenden möchten (kein Prop übergeben), und wir können {{ }} nicht mehr in Attributen verwenden !

@LinusBorg Geöffnet https://github.com/vuejs/vue/issues/3666

Das Beschränken von Filtern auf {{ }} scheint seltsam, es kommt oft vor, dass Sie einen Filter in einer Attributbindung verwenden möchten (kein Prop übergeben), und wir können {{ }} nicht mehr in Attributen verwenden !

Sie wurden entfernt, weil sie leicht durch berechnete Eigenschaften und Methoden ersetzt werden können, während sie selbst eine eingeschränktere API und keine Möglichkeit zum Zwischenspeichern von Ergebnissen haben.

So:

• eine API weniger
• Verwenden Sie dieselben Methoden in der Vorlage und im JS-Code, ohne dass Sie das Filterverhalten für die Verwendung im App-Code duplizieren müssen.
• berechnete Requisiten können zwischengespeichert werden
• mehr Flexibilität, weil es nur JS ist

Pseudocode voraus:

<!-- method, suitable in v-if  -->
<span :title=" date(item.Modified, 'dd-mmmm-yyyy H:MM:ss')>

<!-- computed prop, more suitable for single values -->
<span :title="formattedModified">
<script>
computed: {
  formattedModified () { return date(this.item.Modified, 'dd-mmmm-yyyy H:MM:ss') }
}
</script>

Entschuldigung, ich bin nur "neu".
Aber von Angular 1 zu kommen, ohne Filter zu haben, fühlt sich wirklich seltsam und kontraintuitiv an, warum sollte es besser sein, jeden Entwickler seinen eigenen Satz von Filtern entwickeln zu lassen und die berechneten Einträge selbst zu setzen usw. besser, als sie einbauen zu lassen?
Und was jetzt als bewährte Methode gilt, um ein wirklich großes Array nach Objekten im Element zu filtern. Bei eckig war dies nur eine Codezeile. Es war möglich, ein Array nach einer Sucheingabe zu filtern, und es würde all die Magie tun, die die Funktion eines Frameworks sein sollte.

Und was jetzt als Best Practice gilt, um ein wirklich großes Array zu filtern

Was ist ein wirklich großes Array? Theoretisch würde eine berechnete Eigenschaft auch zum Filtern gut tun.

https://jsfiddle.net/sat25z51/3/

warum wäre es besser, wenn jeder Entwickler seine eigenen Filter entwickelt und die berechneten Einträge selbst setzt usw., anstatt sie einzubauen?

Früher dachte ich genauso (und warum ich den Thread gestartet habe), aber seit ich gelernt habe, dass es im Grunde ein Kinderspiel ist, diese Art von Filtern selbst zu erstellen, und dass es sooo viele Dinge gibt, die sich jeder Entwickler wünschen könnte Als Filter (oder berechnete Eigenschaft) habe ich festgestellt, dass es keine allzu große Sache ist, keine Filter eingebaut zu haben.

Scott

In meinem Fall entspricht dies > 10.000 Zeilen in JSON, die von einer Firebase-Datenbank bereitgestellt werden.
Ich verstehe, warum Sie vielleicht so denken und sich entscheiden, das Feature fallen zu lassen, dennoch ist es ein ziemlich zusätzlicher Aufwand für Entwickler.

Ich habe die Geige gegabelt, um mit meiner Datenstruktur übereinzustimmen:
https://jsfiddle.net/nw5yhLwv/
Also muss ich für die Suche eine Zeichenfolge in meinem Objekt von Hand codieren?

Ich verstehe deine Frage nicht. Verzeihung. Die Geige sieht aus wie die, die ich gepostet habe.

Scott

Berechnet vs. Filter

Filter sind möglicherweise schlecht für die Leistung, da sie für jedes Rendering berechnet werden (genau wie Methoden) und berechnete Eigenschaften kinderleicht sind und nur bei Bedarf neu berechnet werden, da sonst die Ergebnisse zwischengespeichert werden, was bedeutet, dass Vue fliegen kann.

Oh. und wir haben beides. 😄

Scott

Hey, ich habe ein bisschen herumgespielt und jetzt verstehe ich es, es ist ein großartiges Konzept! 😄

Ich werde diesen Thread jetzt schließen, da die Diskussion darüber längst beendet ist - Vue 2.0 ist seit ein paar Monaten draußen, und die Kritik am Wegfall von Filtern hat sich weitgehend gelegt.

Weitere Diskussionen in diesem Thread sind nicht zielführend. Wenn Sie einen neuen Blickwinkel auf das Thema sehen, das Ihrer Meinung nach diskutiert werden muss, öffnen Sie bitte ein neues Thema.