Vue: [Suggestion] Vue 2.0 - Ramenez les filtres s'il vous plait

Clarification d'un point qui provenait à l'origine du chat Gitter : debounce n'est pas un filtre, et n'était qu'un autre des changements 2.0 que les gens n'étaient pas ravis de perdre.

Correction avec l'aimable autorisation de @JosephSilber : debounce est à la fois un filtre et un paramètre v-model .

Merci @agc93. J'ai supprimé ce point.

Scott

Dans le pire des cas, nous proposerons de minuscules plugins pour gérer cela. À propos des filtres, il y a https://www.npmjs.com/package/babel-plugin-pipe-operator
Le problème est que cela ne fonctionnera pas sans compilation babel

Je ne suis pas trop content de certains des changements non plus. Pour les filtres, il semble y avoir une alternative simple en enregistrant des mixins globaux . Cependant, je n'aime pas trop l'idée de polluer toutes les portées de méthodes de mes composants pour des tâches ultra-simples comme la pluralisation, etc. Cependant, je n'ai jamais utilisé de filtres bidirectionnels.

Les filtres étaient simplement pratiques et beaux. Les deux choses que vue a toujours bien fait (jusqu'à présent).

Quand j'ai lu le post sur vue 2.0, j'ai été ravi de toutes les nouvelles possibilités (en particulier le dom virtuel et le rendu du serveur), mais j'ai aussi été surpris et un peu triste que les filtres aient disparu.

C'était l'une de mes parties préférées de vue, non seulement parce qu'elles étaient facilement utilisables et chaînées, mais surtout parce qu'elles étaient facilement extensibles et avaient une belle syntaxe pour les utiliser directement dans le modèle. Surtout en combinaison avec des boucles v-for , elles correspondaient parfaitement.

En pensant que je devrai utiliser des propriétés calculées pour remplacer le filtrage de chaque accessoire que je veux, je crains d'écrire beaucoup de passe-partout à l'avenir. Bien que les mixins puissent atténuer une partie du problème, j'ai toujours l'impression qu'une partie de l'élégance et de la facilité d'utilisation de vue va manquer.

Tous ceux qui sont d'accord avec cela, pouvez-vous simplement cliquer sur le pouce levé sous la description ? c'est mieux que de spammer 17 000 personnes avec +1 . Mieux encore, proposez des cas d'utilisation significatifs.

Je n'ai jamais utilisé de filtres bidirectionnels, mais les filtres me manqueraient vraiment ! Je peux (et parfois je le fais) utiliser des propriétés calculées, mais dans certains cas simples, c'est une commodité qui accélère vraiment le flux de travail.

Considérez cet exemple très simple

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

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

Ce qui précède est tellement plus facile à écrire dans les cas où il n'est pas nécessaire d'avoir un filtrage plus complexe.

Maintenant, comparez-le à ce qui suit

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

Je ne dis pas que le second est difficile à écrire, mais lorsque vous l'utilisez dans de nombreux endroits, vous commencerez à vous répéter, et cela prend juste un peu de temps supplémentaire que vous pourriez peut-être utiliser sur d'autres fonctionnalités plus utiles !

Quoi qu'il en soit, je resterai un utilisateur heureux de Vue, partageant simplement mon opinion sur les filtres obsolètes !

Les filtres sont réutilisables. Je peux créer une fonction pour formater mes données une fois, l'enregistrer en tant que filtre et l'utiliser à partir de toutes les instances. Comment puis-je le faire en 2.0 ?

Comment puis-je le faire en 2.0 ?

• Mélanger
• Module séparé avec méthode
• Module séparé avec fonction prop calculée

Je viens de laisser un commentaire sur le fil d'annonce, donc au lieu de tout dupliquer ici, je vais simplement créer un lien vers celui-ci :

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

Je comprends parfaitement le sentiment que quelque chose de super pratique vous soit enlevé. Mais d'abord, veuillez prendre un moment pour lire le commentaire de @chrisvfritz dans le fil de discussion ci-dessus. Pour faciliter la discussion, je fais juste un copier-coller ici :

@theotherzach Merci pour votre passion pour Vue ! J'aimerais expliquer un peu mieux la dépréciation, mais d'abord, je dois me présenter. Je suis membre de l'équipe principale de Vue, j'utilise Vue tout le temps pour mon travail indépendant d'interface utilisateur et de visualisation de données, et je suis également un éducateur qui enseigne aux gens à utiliser Vue et Rails, entre autres technologies Web. Je dirige une école de code, donc j'aide les gens à apprendre à utiliser ces outils (et à les utiliser ensemble) presque _tous les jours_.

J'étais également l'un des grands partisans de la suppression des filtres dans Vue 2.0.

Le problème des filtres pour les débutants à Vue

Une grande partie de la raison pour laquelle j'étais en faveur de l'abandon des filtres était en fait _pour_ les débutants. Lorsque vous travaillez avec des étudiants, c'est une conversation qui revient plus d'une fois :

• Étudiant : "Donc, un filtre est fondamentalement une fonction ?"
• Mentor : "Oui !"
• Étudiant : "OK, puis-je l'utiliser normalement avec des parenthèses de fonction ?"
• Mentor : "Eh bien, non. C'est un type spécial de fonction."
• Étudiant : "Puis-je l'utiliser à d'autres endroits ? Comme dans une valeur calculée ?"
• Mentor : "Non, vous ne pouvez l'utiliser que dans des modèles et uniquement avec la syntaxe de canal spéciale."
• Étudiant: "... pourquoi?"

Les _exceptions_ sont l'une des grandes choses qui font trébucher les débutants. Les filtres ne sont que des fonctions, _sauf_ qu'ils nécessitent une syntaxe spéciale et ne peuvent pas être utilisés partout. Et ils utilisent une syntaxe de canal différente de la syntaxe de canal qui peut être intégrée dans ES7 , ce qui signifie qu'il ne faudra pas longtemps avant que les gens aient deux opérateurs très similaires pour faire quelque chose de très similaire, mais ils ne sont pas _tout à fait_ identiques. Et un seul d'entre eux est en fait JavaScript.

Les bibliothèques d'utilitaires sont utiles, mais Vue n'en est pas une

Dans le cas de filterBy , des transformations pour les chaînes et les nombres, et d'autres filtres spécifiques, oui, ils sont utiles dans les applications où ils apparaissent. Les bibliothèques d'utilitaires en général sont utiles. Et il existe des dizaines de bibliothèques d'utilitaires parmi lesquelles choisir, mais Vue n'est pas une bibliothèque d'utilitaires. Et franchement, aucun des utilitaires que nous avons proposés n'a été le meilleur de sa catégorie.

Gérer les devises, les dates ou même filtrer les tableaux - ce n'est pas notre objectif. De nombreuses applications n'en ont pas besoin et la plupart des applications sur lesquelles j'ai travaillé qui sont confrontées à ces problèmes nécessitent une solution plus robuste que celle que Vue propose actuellement (ou _pourrait_ offrir sans introduire de ballonnement important et de réinvention de la roue).

Dans mes applications, Accounting.js a superbement géré la devise, Moment.js (comme vous l'avez mentionné) gère les dates et les heures, pluralize ne gère pas bien de nombreuses pluralisations, donc une valeur calculée personnalisée est souvent plus souhaitable, et json est un peu plus de JSON.stringify .

Les avantages des propriétés calculées

L'utilisation de propriétés calculées à la place de filtres offre également l'avantage que la valeur traitée peut être facilement réutilisée de manière DRY _n'importe où_ dans le composant. Je me retrouve à devoir le faire dans mes applications tout le temps. La propriété computed déplace également plus de détails d'implémentation hors du modèle, ne laissant qu'une description claire de ce que fait le composant. Et un avantage par rapport aux filtres définis globalement est qu'il suffit de regarder la fonction de cette valeur informatique pour voir et modifier exactement comment cela fonctionne. Sur les tableaux, le chaînage des méthodes map et filter JavaScript fournit même la même liste linéaire de traitements que les pipes, mais d'une manière encore plus déclarative et facilement manipulable.

L'utilité de tout ce qui est défini globalement

Si vous avez besoin de définir une fonction ou toute autre chose que vous souhaitez rendre accessible dans tous vos composants, Vue.prototype.whateverIWant = mySuperCoolFunction est un excellent moyen de le faire. Personnellement, je n'ai jamais _voulait_ le faire. J'ai toujours préféré mettre une méthode d'assistance dans un module et importer ce module là où j'en ai besoin. Mais il est toujours important de noter que l'enregistrement de globals - de toute sorte - n'est pas rendu plus difficile.

Le cas de la directive debounce

Je dois dire que je suis en fait avec vous sur celui-ci ! J'ai récemment examiné tous mes projets Vue et chacun de ceux qui avaient un input quelque part utilisait également debounce . En fait, une seule de mes applications passées _n'utilisait pas_ l'anti-rebond. Bien qu'il s'agisse techniquement d'un utilitaire - lodash et de nombreux autres projets robustes offrent des solutions anti-rebond - ce problème est assez universel pour le développement de l'interface utilisateur, pour _tout_ type d'application. L'écriture de votre propre fonction anti-rebond est également suffisamment non triviale pour que je veuille probablement utiliser l'implémentation de lodash pour presque tous les projets.

Il reste un débat interne à ce sujet, nous verrons donc où cela mène. Mais oui, pour moi personnellement et il semble aussi pour d'autres, la suppression de l'anti-rebond supprime la plupart des avantages offerts par v-model .

Encore merci pour votre passion !

Sérieusement, nous aimons à quel point vous aimez Vue et sommes vraiment heureux que vous exprimiez vos préoccupations - et surtout d'une manière si gentille et respectueuse ! Nous vous entendons. L'équipe principale est composée de concepteurs, de développeurs front-end et de spécialistes de la visualisation de données. Nous utilisons tous Vue pour notre propre travail, qui est assez diversifié, nous sommes donc résolument déterminés à proposer des aliments pour chiens que nous voudrons manger nous-mêmes. :-)

Parler n'est pas cher, codez pour voir si sans filtre, comment appliquer filterBy et inverser :

écrire des fonctions de filtre pures globales dans un fichier séparé pour la réutilisation du 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}

utiliser des filtres dans le modèle App.vue

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

voir le résultat ici http://raywill.github.io/vuefilter/

Si le filtre est utilisé, le code de vue suivant ferait de même :

<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'],
    }
  },
}

Apparemment, avec le filtre pris en charge, nous pourrions écrire du code moins trivial.
Personnellement, je préfère la méthode vue 1.0, qui rend le codage plus agréable.

Quant aux préoccupations de la batterie - il existe plusieurs façons de le gérer.

1. Importer/exporter explicitement

Comme @raywill démontré ci-dessus. C'est un peu plus verbeux, mais les avantages sont que :

1. Vous n'avez pas besoin de consulter la documentation du filtre de Vue pour comprendre comment cela fonctionne. C'est super explicite où les fonctions proviennent et comment elles sont mises en œuvre.
2. Les fonctions elles-mêmes ne sont que du JavaScript. Vous pouvez les modifier / les composer pour adapter des utilisations spéciales, contrairement aux filtres intégrés que vous ne pouvez pas toucher.
3. Vous pouvez importer et réutiliser de manière programmable ces fonctions dans des méthodes, des propriétés calculées et partout où vous écrivez JavaScript.

2. Attachez-les à Vue.prototype

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

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

3. Devenez fonctionnel (pour les utilisateurs avancés)

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

Où les fonctions d'assistance ressemblent à :

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

Encore une fois, une considération de conception très importante est que les filtres intégrés peuvent être utiles, mais ils ne manquent pas de la flexibilité de PURE JavaScript . Lorsqu'une fonction intégrée ne répond pas à vos besoins, soit vous finissez par réimplémenter quelque chose de similaire (et expédiez les deux dans votre code final, où la fonction intégrée devient un code inutile et mort), soit vous devez attendre que Vue mettez-les à jour et publiez une nouvelle version.

@ yyx990803 J'aime l'approche prototype, mais qu'en est-il des cas où vous avez besoin de plusieurs filtres ?

Il est assez courant d'utiliser orderBy avec filterBy

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

Que diriez-vous des cas où vous ajouteriez également un limitBy ?

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

Cette approche rend-elle le code moins lisible ?

Oui, du moins à mon avis.

Je suppose que nous aurions pu combiner des filtres comme filterAndOrderBy mais cela ne semble pas correct non plus.

Je suis ouvert aux changements, je veux juste trouver un moyen presque aussi simple de le gérer !

De plus, l'avantage de pouvoir utiliser les filtres n'importe où est également un très bon point.

Juste pour noter, les @vuejs/collaborators ont discuté d'une option pour fournir un package d'utilitaires des filtres intégrés actuels. Il existe de nombreuses ressources qui vous fourniront des outils utilitaires pour votre base de code.

Une bonne chose à propos de la suppression des filtres principaux est que vous pouvez désormais les personnaliser/implémenter vous-même. Ce qui vous donne beaucoup plus de flexibilité.

Les expressions de modèle <div v-for="filteredData"> </div> . Il peut s'agir d'un accessoire calculé, qui peut contenir la logique de création des données filtrées. C'est beaucoup plus lisible, et c'est mieux que quelque chose comme :

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

Il est beaucoup plus réutilisable de l'affecter en tant que propriété calculée et peut même être transmis aux composants enfants. Et si vous vouliez utiliser les données filtrées à deux endroits ? Il est plus facile, plus simple, fiable et plus lisible pour les modèles d'avoir des expressions simples, par rapport à des filtres chaînés dans les expressions.

Pour tous ceux qui suivent, j'ai répondu à @chrisvfritz ici : http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

Ce qui suit résout mon cas d'utilisation d'un _très_ peu de fonctions d'aide à la vue pure disponibles dans le monde entier. Je retire mes préoccupations concernant le retrait du filtre. Brûlez-les ! 🔥 Bravo à @chrisvfritz et @yyx990803 d'avoir fait changer d'avis (le mien) quelqu'un sur Internet !

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

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

Je suis totalement d'accord avec @ yyx990803 , supprimez les filtres et respectez les fonctions JS simples.

@blake-newman C'est un très bon point, je suis surtout convaincu à ce stade, et en pensant à la lisibilité, je pense que quelque chose comme ça peut être réalisé

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

Voici un rapide jsfiddle du concept

Une bonne chose à propos de la suppression des filtres principaux est que vous pouvez désormais les personnaliser/implémenter vous-même. Ce qui vous donne beaucoup plus de flexibilité.

Vous avez toujours pu les personnaliser/implémenter vous-même.

Vue n'est pas une bibliothèque utilitaire. Et franchement, aucun des utilitaires que nous avons proposés n'a été le meilleur de sa catégorie.

Ce qui nous préoccupe, c'est la suppression de la fonctionnalité de filtre dans les modèles. La suppression des filtres intégrés a beaucoup de sens - ils peuvent être facilement recréés en les mettant en proxy pour souligner/d'autres bibliothèques d'utilitaires. Ensuite, quelqu'un pourrait même publier un seul plugin qui recrée tous les filtres intégrés actuels.

L'utilisation de propriétés calculées à la place de filtres offre également l'avantage que la valeur traitée peut être facilement réutilisée de manière DRY n'importe où dans le composant.

Bien sûr, vous pouvez utiliser des propriétés calculées si vous devez les réutiliser ailleurs. Mais si vous ne le faites pas, un filtre est toujours beaucoup plus pratique.

Il y a d'autres points que j'ai publiés dans ce lien que j'ai partagé ci-dessus.

Pourquoi ne pas prendre en charge une syntaxe pour les filtres qui fonctionne comme la syntaxe proposée par ES7 ? Cela permettrait aux gens de continuer à utiliser leurs filtres bien-aimés et de les aligner sur ce que l'avenir leur réserve. Finalement, lorsque nous avons des tuyaux ES7, vous pouvez changer l'implémentation interne sans changer l'API.

Les pipes ES7 sont-elles homologuées ou sujettes à de nombreuses modifications ?

Il est théoriquement sujet à changement, mais semble... stable ?
Statut : mindeavor/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Je pense que nous sommes sur la même page concernant la valeur des tuyaux en général. 😃 L'un des avantages du nouveau compilateur en 2.0 est que nous pouvons diriger le code de la fonction de rendu généré via Babel. Cela doit encore être exploré plus avant, mais il n'est pas inconcevable qu'une fois que |> prend de l'ampleur et qu'un plugin Babel est développé, vous pouvez à nouveau enchaîner avec plaisir des méthodes avec des canaux - _partout_ dans votre application. En tant que grand fan de LiveScript et d'autres langages fonctionnels, j'en reconnais définitivement la valeur !

cet opérateur de pipeline n'est même pas au stade 0

@thelinuxlich Oui, je crois qu'ils attendent toujours un champion sur TC39. 😞

@ rigor789 c'est aussi l'une des alternatives que je voulais mentionner ! La puissance de JavaScript vous permet d'obtenir l'expressivité de votre choix, et imo c'est mieux que de mettre la logique de filtrage à l'intérieur des modèles.

@yyx990803 Comment fonctionne Vue dans les cas suivants, lorsque le nom d'un utilisateur est mis à jour ?

<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);
    },
  },
});

Il semble que le premier ne restituerait qu'un seul objet, tandis que le second recalculerait la liste entière ?

@rpkilby cela ne semble pas être l'équivalent. Ce serait plutôt :

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

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

N'aime toujours pas l'idée d'utiliser des méthodes telles que des filtres (comme un sentiment d'intestin, cela semble faux, mais ne peut pas vraiment l'expliquer). Quoi qu'il en soit, vous avez discuté d'autres méthodes pour rendre les filtres disponibles, donc +1.

Rien de suggéré dans ce fil ne se rapproche même de l'expressivité et de la concision des filtres. Ce n'est tout simplement pas le cas.

Et ça me rend vraiment triste. Comme je l'ai dit dans le fil de discussion du forum : pour moi, cela supprime une grande partie de ce qui fait Vue Vue.

Si vous me cherchez, vous pouvez me trouver dans le coin en train de sangloter de façon audible 😟

Pas question, ce changement encourage un bon codage Javascript, faites avec :)

Je viens donc d'avoir une longue discussion avec @ yyx990803 , où j'ai - du point de vue de l'utilisateur - suggéré de conserver le support _syntax_, car il semble élégant et naturel. Mon imagination était quelque chose comme ça :

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

J'avais l'impression que cela approcherait le meilleur des deux mondes.

Au final cependant, je suis convaincu que la suppression des filtres dans leur ensemble est en fait une meilleure chose : comme @thelinuxlich vient de le dire, cela encourage une meilleure réflexion JavaScript et logique. Nous n'introduisons pas de logique dans Laravel's Blade ou dans la couche de vue de tout autre framework, et nous ne devrions pas le faire dans les modèles de Vue.

Cela dit, @JosephSilber si vous regardez l'autre coin, vous me trouverez là-bas.

Pour moi, les filtres sont très beaux, la syntaxe est exactement à quoi devrait ressembler une syntaxe de filtre.

Une autre chose intéressante à propos de Vue pour moi est qu'il est livré avec (certaines) piles incluses. Il serait vraiment triste de perdre l'une ou l'autre de ces choses - les deux qui, à mon avis, font que Vue se démarque.

En lisant le fil, il semble que la plupart des problèmes avec les filtres étaient le fait que Vue avait des filtres par défaut, et pas vraiment la fonction elle-même (ou l'est-elle ? Je ne suis toujours pas sûr).

J'aime la pensée du plug-in de filtre de @blake-newman et il devrait y avoir des exemples prédéfinis. Si d'autres personnes proposent d'autres filtres, ils doivent être plug and play. Ce serait génial. Je suis absolument d'accord que la création de filtres est une responsabilité de l'utilisateur.

Ce qui est toujours recherché, ce sont les capacités de canalisation et de chaînage et la globalité de la fonction de filtre d'origine. Les préoccupations concernant la globalité ont été couvertes par @yyx990803. Que diriez-vous de l'enchaînement avec le tuyau? Cela aide énormément à lire les modèles et à comprendre ce à quoi on peut s'attendre en tant que sortie. Le tuyau et le chaînage ont été discutés ci-dessus. Peut-on encore le faire ? Pourquoi est-ce une mauvaise chose ? Pour le créateur, c'est de l'or ! Le filtre est l'outil du concepteur, pas celui du programmeur JS. Ainsi, l'argument d'écrire mieux JS tombe du tableau, dans mon livre, mais je peux comprendre pourquoi il serait voulu. Mais, en tant que designer, je veux aussi écrire un meilleur code, et les filtres me le permettent, magnifiquement. :le sourire:

Scott

Voici la chose concernant le chaînage - les filtres sont principalement utilisés à deux fins :

1. mise en forme du texte ;
2. traitement d'un tableau.

Dans le cas du formatage de texte, 90 % ou plus du temps, une seule méthode utilitaire est utilisée. Le chaînage n'est pas vraiment un problème dans ce cas.

En ce qui concerne les tableaux : j'ai déjà souligné que le traitement des tableaux est en fait logique et convient mieux à JavaScript. Avoir plusieurs filtres de tableau chaînés peut sembler correct quand c'est simple, mais peut devenir moche quand vous utilisez plus d'un argument pour chacun. Cela vous encourage également à mettre trop de logique dans votre modèle alors que vous ne devriez vraiment pas. Ils sont également inflexibles (ne peuvent pas facilement récupérer la valeur traitée). En comparaison, avec ES2015 l'exemple original

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

peut s'écrire :

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

C'est juste du JavaScript, il n'a pas de magie, pas de syntaxe alternative et d'API spécifique au filtre à apprendre. Et vous pouvez accéder à la valeur traitée (qui est intelligemment mise en cache). Vous êtes également libre d'ajouter du sucre en plus, comme indiqué dans les commentaires précédents. De plus, votre modèle a l'air plus propre :

<div v-for="filteredThings">

Je sais que c'est comme si on enlevait une chose pratique, mais honnêtement, les arguments en faveur des filtres en ce moment me semblent juste essayer de garder la syntaxe pour le bien de la syntaxe. À mon avis, il faut plus que simplement "parce que c'est élégant" pour justifier une fonctionnalité - elle doit fournir une valeur objective. C'était le cas pour inline-templates , mais je ne le vois pas pour les filtres.

@ yyx990803 - Votre exemple illustre le problème, je pense. Encore une fois, je ne suis pas le meilleur programmeur JS, mais je n'ai pas besoin d'être un programmeur JS pour savoir que filteredThings ne dit rien de ce qu'il fait réellement. Pour moi, c'est une mauvaise pratique. :smile: Le fait que la méthode de filtrage soit globale signifie également que je dois chercher dans la documentation, le code ou déchiffrer la sortie pour savoir ce que fait la méthode. Pas vraiment élégant. À droite?

Donc OK. nous pourrions avoir un nom de méthode comme `filterByOrderByAndLimit'. Qu'en est-il des arguments ?

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

Serait-ce correct?

Si c'est le cas, cela pourrait être faisable. Pourtant, ça n'a pas l'air bon.

Et, maintenant, je ne veux que filterBy et OrderBy. Ai-je besoin d'une méthode distincte pour le faire aussi? Et puis je veux ajouter le formatage des devises. Une autre méthode ? Le chaînage de filtres dans les modèles rend la manipulation de la présentation flexible et très expressive. Cette préoccupation n'a pas encore été correctement traitée avec des méthodes (et mon manque de connaissances ne me permet pas de comprendre que les méthodes peuvent être meilleures).

Cela peut-il être possible ?

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

Je suis d'accord que faire trop de logique dans un modèle est quelque chose à éviter. Mais, le chaînage de filtres et la possibilité d'insérer simplement un filtre n'importe où dans les composants/modèles d'une application est un concept fantastique et il y avait une raison pour laquelle vous l'avez ajouté pour commencer. Quelle était cette ou ces raisons ? Si vous pouvez les nommer, alors je parierai de l'argent qu'ils dépassent "mais cela favorise les mauvaises pratiques" d'un mile.

Tout ce qui permet de la flexibilité peut être mal utilisé, tout comme Vue lui-même. L'argument principal de inline-template était qu'il était flexible et permettait à Vue d'être utilisé de différentes manières. Les filtres ne sont pas très différents, si ce n'est qu'ils sont internes à Vue et n'affectent pas la façon dont Vue peut être utilisé en externe. Cela n'enlève rien à son importance. N'oubliez pas que de nombreuses personnes ont également déclaré qu'il leur serait impossible de mettre à niveau. C'est si important que ça ! :le sourire:

La nouvelle méthode a simplement besoin des mêmes attributs que l'ancienne.

• enchaînable
• global
• ajouter aux modèles pour bien exprimer comment les données dans les modèles seront manipulées

(j'ai rien oublié ?)

S'il peut faire tout cela, alors je suis sûr que tout le monde sera à peu près satisfait. Personnellement, je ne vois pas cela se produire avec les méthodes (encore).

Scott

@smolinari

1. J'ai clairement indiqué que vous devriez mettre moins de logique dans vos modèles. C'est mon avis que cela vous plaise ou non. Évidemment, vous êtes libre d'être en désaccord, mais je ne peux pas vous aider si vous voulez aller à l'encontre des meilleures pratiques recommandées.
2. Étant donné (1) - J'ai expliqué pourquoi le chaînage n'est pas un problème car une logique complexe doit être effectuée en JavaScript.
3. J'ai également donné des exemples de la façon dont vous pouvez ajouter des méthodes disponibles dans le monde entier.
4. Voir l' exemple de @ rigor789 sur une syntaxe de chaînage personnalisée similaire à ce que vous voulez.
5. Le but du framework est de fournir ce que je crois être la meilleure façon de développer des applications frontales, pas de plaire à tout le monde. Alors, s'il vous plaît, n'utilisez pas "Je ne mettrai pas à jour si vous ne me rendez pas cette fonctionnalité" - cela ne fonctionne pas.

Pourquoi n'essayez-vous pas cette nouvelle version alpha pendant une semaine, puis venez avec des commentaires vraiment précieux (basés sur votre pratique) ? Essayez peut-être de refactoriser votre application existante et faites-nous savoir ce qui était impossible, ce qui a été amélioré, ce qui a empiré, afin que nous puissions mieux en discuter. Ce serait utile pour tout le monde je pense.

@ yyx990803 - J'ai accepté 1. Nous sommes donc d'accord. :sourire: Je ne suis tout simplement pas d'accord que ce soit une bonne raison pour sortir quelque chose qui a gagné tant d'amour.

Donc, je suppose que vous avez décidé au fil du temps que le JS pragmatique est meilleur que le HTML pragmatique ?

L'argument d'un no-go pour ne pas mettre à niveau est ce que d'autres ont dit. J'essaie juste de communiquer et d'atténuer cela.

Un dernier argument de ma part. Regardez cela des yeux de l'utilisateur. Disons que j'ai un système comme Laravel ou un autre système MVC ou MVVM qui intègre Vue, ce qui permet également à l'utilisateur de ce système de créer ses propres composants. Le filtre, tel qu'il était, simplifie la courbe d'apprentissage et permet aux utilisateurs de ce système de faire beaucoup de choses, sans toucher à aucun JS. Je suis un fan de Vue, car il permettait aux programmeurs non-JS de faire encore beaucoup de choses. C'est la même raison pour laquelle je n'aime pas React et JSX. Cette combinaison aura une base d'utilisateurs beaucoup plus petite sur Vue au fil du temps. Je parierai de l'argent dessus.

Je comprends également que la vraie flexibilité réside dans JS. Néanmoins, ne comptez pas uniquement sur JS pour la flexibilité de Vue. Gardez-le à l'esprit, tout le monde n'est pas un programmeur JS tueur. En fait, la plupart des gens ne le sont pas. Le filtre était un bon moyen de faire beaucoup pour ces personnes et c'était un bon tremplin vers d'autres manipulations JS. Les filtres ne peuvent pas le faire ? Approfondissez les méthodes JS.

D'accord. Assez de moi ..... J'ai fini. Et merci d'avoir écouté en tout cas. Vue est toujours génial! :le sourire:

@azamat-sharapov - bon point.

Scott

Voir des gens essayer de justifier de mauvaises pratiques au sein de JS me rend triste. Vraiment, vous n'avez pas besoin d'être un pro, faites juste les devoirs de base (ou n'est-ce plus basique de nos jours ?)

Le problème que j'ai avec les méthodes de filtres à l'intérieur est de sémantique.

En termes oops, les filtres sont comme des fonctions statiques tandis que les méthodes sont des fonctions non statiques.

Les filtres véhiculent une sémantique extrêmement différente de celle des méthodes. la plus grande différence étant que les filtres ne peuvent pas utiliser this , mais les méthodes le peuvent.

@ yyx990803 tout en utilisant Vue.prototype.filters peut fonctionner mais changer Vue ne me semble pas être une bonne pratique. Je préconiserais plutôt la création d'un objet séparé (global) qui contiendra tous les filtres.

Cela ne ressemble pas à une bonne pratique car les globals ne sont pas une bonne pratique. L'approche recommandée consiste à importer explicitement les méthodes d'assistance. L'attachement au prototype est une solution de contournement pour ceux qui ne souhaitent pas importer explicitement des méthodes.

Quant à la sémantique - les filtres sont un concept inventé de toute façon. En JavaScript, vous n'inventeriez pas une sémantique différente juste pour mettre une chaîne en majuscule - vous appelez une fonction. Et c'est ce qu'elles sont, des fonctions JavaScript.

Je vais faire un autre commentaire pour essayer de clarifier mon point personnel, principalement à cause du commentaire "essayer de justifier les mauvaises pratiques au sein de JS". Je n'essaie certainement pas de faire cela.

Je me rends compte que Vue est plus qu'un simple système de modèles, mais c'est aussi un système de modèles et je crains qu'il essaie de s'éloigner de ce rôle, ce que je pense qu'il ne devrait pas. Donc, en tant que moteur/système de templates, prenez le moteur de templates Twig comme un exemple très réussi de ce que l'on peut attendre d'un système de templates. Ils ont une section " Pour les concepteurs de templates " et une section " Pour les développeurs " dans leurs docs. En tant que système de modèles, Twig est également puissant pour le concepteur de modèles, car il regorge de comportements par défaut, y compris les filtres . Il permet aux non-développeurs de faire une tonne avec le système de templates, sans connaître directement PHP. Ils doivent juste apprendre ce que Twig a à offrir et comment l'utiliser. Je recherche cela dans Vue aussi. J'aimerais également voir une section "Vue pour les concepteurs de modèles" dans la documentation. :le sourire:

De plus, l'extensibilité de Twig est très importante. Si quelque chose n'est pas disponible dans la version stock, il peut être ajouté. C'est alors que le développeur intervient. Ce qui est bien aussi, c'est que les extensions peuvent être partagées, ce qui signifie que cela ne doit être fait qu'une seule fois.

L'autre avantage de ces deux niveaux de concepteur/développeur est que vous obtenez une base d'utilisateurs beaucoup plus large. Beaucoup, beaucoup plus large et c'est la même chose avec . Et lorsque les comportements par défaut ne suffisent pas, c'est alors qu'ils commencent à apprendre, volontairement, le langage sous-jacent. Et c'est à ce moment-là qu'ils apprennent les meilleures pratiques et le reste.

Si vous dites que Vue ne peut pas être un moteur de modèle sans avoir à apprendre JS, alors je dirais qu'il réduit considérablement sa valeur marchande. Si vous le dites, vous laisserez la porte ouverte pour permettre aux autres de créer ces outils pour le moteur de modèles sous forme de plug-ins, super. Mais alors tout le monde se battra pour ce qui devrait être dans le système de modèles. C'est aussi contre-productif à mon humble avis.

Dans votre étudiant parlant de l'exemple des filtres Evan, était-ce quelqu'un qui apprenait JS ou quelqu'un qui apprenait un moteur de modèle ? Si c'était ce dernier, je parie que la conversation se déroulerait différemment.

À tout prix. Je pense toujours que Vue est un système gagnant. J'espère que mes pensées inciteront les autres à penser différemment les rôles de Vue d'une manière ou d'une autre. :le sourire:

Scott

@ yyx990803 si les filtres sont un concept inventé, alors pourquoi ont-ils été inventés en premier lieu ?

Je crois que c'est parce qu'à l'intérieur <template> toutes les variables externes comme $data ou abc sont converties en this.$data et this.abc et donc des fonctions js simples définies en dehors du composant ne peut pas être référencé. Des filtres ont été introduits pour surmonter cette limitation.

Cette limitation existe toujours --- je suppose que j'ai raison --- pour supprimer la limitation, il faudrait que les développeurs codent explicitement this.abc pour référencer this.abc et accéder aux fonctions js telles qu'elles seraient référencées dans js.

Mais ce sera une fonctionnalité trop puissante, sujette aux abus et la migration de l'ancien code sera pénible. la syntaxe actuelle me semble bien meilleure que cela.

Je suis d'accord avec vous que les filtres sont essentiellement des fonctions js et doivent être importés dans component. Je n'aime tout simplement pas qu'ils soient définis au même endroit que les méthodes.

Salut à tous. J'ai lu tout le fil et c'est ce que je pense.

• Personne ne manquerait les filtres intégrés comme orderBy filterBy et tout autre
• Ce que tout le monde veut toujours avoir, c'est l'opérateur de tuyau dans les modèles
• L'équipe principale dit que la logique doit rester en javascript, pas dans les modèles, en plus il y a une fonctionnalité es7 à venir avec l'opérateur de pipe.

Ayant cela comme un résumé rapide, ce que je pense que cela pourrait être une bonne solution jusqu'à ce que js implémente un opérateur de pipe natif , serait d'avoir l'opérateur de pipe en tant que plugin et de garder la version 2.0 telle quelle. Ainsi, les utilisateurs peuvent faire

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

Pendant que nous attendons la mise en œuvre de la nouvelle fonctionnalité, elle pourrait être incluse avec un avertissement sur la dépréciation à venir ou quelque chose du genre. Je sais que n'importe qui pourrait implémenter ce plugin, mais je pense que ce serait mieux s'il était fourni et conservé par l'équipe Vue, cela serait-il possible ?

Je peux me tromper, mais je ne pense pas que Vue permette aux plugins de gâcher son compilateur.

@azamat-sharapov Bien sûr que non. Je ne pensais tout simplement pas que cela dérangerait le compilateur Vue :open_mouth:

@YerkoPalma J'adore absolument l'opérateur de pipe. Je l'utilise de manière obsessionnelle dans les langages fonctionnels et j'ai hâte de l'avoir en JavaScript ! _Mais_, imaginez que Vue n'a jamais eu de filtres. Demanderiez-vous qu'un framework frontal étende la syntaxe de JavaScript ? C'est le domaine de Babel ou un langage de compilation vers JS, pas un framework d'interface utilisateur. Si vous préférez utiliser un langage comme LiveScript, comme je le fais souvent, vous le pouvez. Mais le problème ici n'est pas avec Vue. C'est avec JavaScript lui-même et nous ne sommes pas là pour résoudre ce problème.

De plus, si nous sommes en mesure de diriger les résultats du rendu en 2.0 via Babel comme nous l'espérons, vous pourrez même utiliser le plugin suivi non TC39 si vous le souhaitez - de manière cohérente, partout dans votre JavaScript, au lieu de juste dans le modèle. Donc, si vous voulez juste une pipe, il est probable que vous puissiez l'avoir. Et vous _pouvez_ l'avoir aujourd'hui dans la version 1.x - sachez simplement que le canal que vous utiliserez dans vos modèles aura probablement une priorité et un comportement différents de ceux de votre Babel.

@smolinari et autres. Il y a deux phrases (et leurs variantes) que j'entends sans cesse :

• "Pensez aux développeurs / à la perspective de l'utilisateur"
• "Pensez aux débutants"

Les deux impliquent une hypothèse - que nous ne pensons pas à ces groupes.

Je l'ai déjà mentionné, mais je suppose qu'il faut le répéter. _Tous les membres de l'équipe principale sont soit un concepteur, soit un développeur frontend, soit une combinaison des deux . Nous utilisons ces outils tous les jours pour notre propre travail. Nous utiliserons également Vue 2.0. Croyez-moi, nous y pensons. 😉

En ce qui concerne les débutants, j'ai fait un cas ici , mais je suppose que je vais entrer dans plus de détails. Je suis un éducateur. Et j'étais un partisan de l'élimination des filtres, _en pensant aux débutants_. J'ai personnellement enseigné à des centaines de personnes - peut-être même plus d'un millier - comment pratiquer le développement Web, généralement à partir de zéro. Aucune expérience de codage antérieure. J'ai fait cela avec des collégiens, des lycéens, des étudiants universitaires, des adultes professionnels et des personnes âgées.

De ce point de vue, je peux vous dire que même si les filtres peuvent sembler être une magie excitante au début, ils ralentissent finalement l'apprentissage d'un élève en introduisant plus de complexité pour une commodité limitée. S'ils n'avaient jamais été dans Angular ou Vue et que cette conversation était inversée - nous essayions de les _introduire_ en 2.0 - nous aurions du mal à expliquer pourquoi ils étaient nécessaires et quand vous devriez les utiliser.

Avant qu'il ne soit question d'une dépréciation dans la version 2.0, j'avais éliminé les filtres du programme de notre école de code, car nous avions rassemblé suffisamment de preuves qu'ils faisaient plus de mal que de bien aux débutants. Nous préférons qu'ils acquièrent de l'expérience avec des fonctionnalités Vue plus polyvalentes, comme les méthodes et les propriétés calculées. Nous avons même déconseillé l'utilisation de filtres, car ils facilitaient la détection des mauvaises pratiques.

J'espère que cela mettra ces deux plaintes au lit. Nous verrons. 😃

Mais imaginez que Vue n'ait jamais eu de filtres. Demanderiez-vous qu'un framework frontal étende la syntaxe de JavaScript ?

Bien sûr, je le ferai, car les filtres sont très naturels pour les _templates_ comme dans Twig, mentionné précédemment. Je pense qu'avoir un opérateur pipe est aussi naturel que d'avoir la syntaxe moustache dans les modèles, je veux dire, les moustaches ne sont pas html, et pas javascript, allez-vous les supprimer aussi ? quelle est la différence avec l'opérateur de tuyau ?

L'argument "pensez aux enfants" est tout simplement stupide. Autant que je sache, Vue n'est pas conçu pour enseigner JavaScript, mais pour que les développeurs front-end fassent de la merde. Pour ces derniers, les filtres sont super.

S'ils n'avaient jamais été dans Angular ou Vue et que cette conversation était inversée - nous essayions de les introduire en 2.0 - nous aurions du mal à expliquer pourquoi ils étaient nécessaires et quand vous devriez les utiliser.

Je suis tout à fait en désaccord. J'utilise un framework Python appelé Django depuis 2005 et son langage de modèles - qui a inspiré la plupart des langages de modèles nés plus tard - a eu des filtres dès le premier jour. Après les avoir utilisés avec des développeurs front-end pendant dix ans, j'en suis venu à apprécier leur beauté et leur utilité. Il serait triste de voir cette syntaxe disparaître.

(Voici ce que Django fait avec les filtres : https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen , faites attention à votre ton - qualifier les arguments des autres de stupides n'est pas une façon constructive de participer à une discussion.

Pour ceux qui font des analogies avec les langages de modèles côté serveur - un aspect important à noter est que les langages de modèles côté serveur n'ont pas la même flexibilité que les modèles Vue (pas de propriétés calculées, expressions limitées). De plus, ils sont construits à des fins complètement différentes : produire des chaînes statiques. Les modèles Vue sont des représentations du DOM interactif - il existe des liaisons bidirectionnelles, des gestionnaires d'événements, des accessoires de composants, etc. Les filtres ne conviennent que dans un cas d'utilisation très limité dans le contexte de Vue : aujourd'hui, je pense que c'est une mauvaise idée d'autoriser les filtres partout, par exemple les filtres sur v-model, v-for et v-on introduisent plus de complexité que de bien.

Une alternative possible est de conserver les filtres mais uniquement pour les interpolations de texte - c'est-à-dire que vous ne pouvez l'utiliser qu'à l'intérieur {{ }} s, pas dans les directives.

Comme référence intéressante: Angular 2 a toujours des filtres (renommés "tuyaux") mais ils ont également intentionnellement supprimé ceux de filtrage de liste.

Désolé pour mon langage, je ne veux pas insulter qui que ce soit.

Pour moi, le but d'un framework _est_ de faire les choses difficiles et de le rendre facile pour les développeurs qui utilisent ces outils. Je soutiens toujours que la syntaxe est tout simplement imbattable et, encore une fois, ce serait triste de la voir disparaître.

Je ne connais pas ou ne comprends pas grand-chose des mécanismes sous le capot, mais du point de vue des utilisateurs, l'aspect pratique bat la pureté :)

Dans une note connexe, il a été intéressant de voir à quel point il semble y avoir de la passion dans cette communauté. Pour moi, Vue a été un outil frais et revigorant, c'est peut-être pour cela que j'ai moi-même dû participer à la peinture de ce hangar en particulier :)

Pour un autre DataPoint, Ember n'a pas de filtres ni ne permettant ni des méthodes de composant, bien qu'il ait des propriétés calculées.

Pour le cas d'utilisation des fonctions pures effectuant des transformations dans les modèles, vous devez enregistrer une assistant de guidon / empreuse.
http://emberjs.com/api/classes/ember.helper.html

Les assistants du guidon sont syntaxiquement distincts des choses qui ne sont pas des aides de guidon, c'est pourquoi je l'apporte. Ils ont cela en commun avec la syntaxe du filtre de tuyauterie. Cependant, les modèles de guidon sont «moins logiques», ce qui signifie qu'ils nécessitent une syntaxe spéciale pour un appel de fonction dans le modèle. Un problème que Vue n'a pas.

Les filtres sont simples pour les débutants, il y a une magie en utilisant pour une jolie sortie ou un filtre \ userarch dans les tableaux

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

et facilement le définir

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

C'est simple, claire sur les modèles, pour 2.x, vous définissez des filtres dans un module externe et dans les modèles obtenus

import moment from 'moment'

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

et dans le modèle

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

En tant que suggestion, pourquoi ne pas laisser de vieux filtres dans un modèle, mais déplacez-le dans le module séparé et utilisez-le à partir de la section Méthodes?

Donc, si vous en avez besoin, faites simplement

npm install vue-utils

et utilisez des filtres spécifiques de l'emballage UTILS

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

methods:{
   moment, price
}

et utiliser comme filtre commun

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

En résultat, il sera traduit en appels de fonction simple

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

_Noter_
Pour moi, les filtres utilisent la plupart des données format, tels que des dates, des chiffres ou des chaînes . Pour filtrer les tableaux \ objets, je pense mieux utiliser calculé et fonction du module VUE commun:

import _ from 'vue-utils/array'

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

Avantages:
Les débutants peuvent faciliter l'utilisation d'anciens filtres, mais en calculant et utilisent une assez belle fonction dans leurs modèles pour formater la sortie de données et les programmeurs peuvent écrire de bonnes fonctionsModules pour cela et faciliter l'utilisation.

_Pourquoi un module séparé ?_
Je pense que cela n'est pas nécessaire d'être au cœur de Vue, mais vous devez avoir des utiles pour le concepteur DeveloperstEmplate, donc pas besoin de tous les temps requièrent des lodaash, un moment ou d'autre, il suffit d'installer des utils à partir de NPM et de la facilité pour l'utiliser, mais économiserez la syntaxe d'appel de l'ancienne. modèles.
Mais une pensée importante doit être faite pour les filtres, il doit y avoir des fonctions pures, telles que getters à VUEX.

C'est facile à soutenir, aidez-vous à useUsereExtend et il a bon regard sur les modèles.

Ce dont vous avez besoin, c'est d'un chemin de mise à niveau clair et du désir d'apprendre à modulariser votre code Javascript.

@thelinuxlich On parle de filtres.

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

juste sucre de syntaxe pour

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

Mais exclure complètement les filtres pour les débutants dans Vue\javascript est mauvais. Pourquoi la communauté Laravel aime Vue ? Parce que c'est simple et puissant.

Si nous supprimons complètement les filtres, nous devons donner une alternative pour _"Pour les concepteurs de modèles"_, il n'est pas nécessaire de savoir comment trier le tableau ou le filtrer, il suffit d'entrer un exemple de forme de code et d'obtenir le résultat.

Les programmeurs doivent savoir comment _modulariser_ le code Javascript, mais reste ceux qui l'utilisent pour de petites choses pas besoin de le savoir.

Si on parle de _"Pour les concepteurs de templates"_ il suffit de mettre

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

et à l'intérieur de l'utilisation du code

Vue.use(VueUtils)

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

par exemple et fiers d'eux-mêmes, il n'est pas nécessaire de connaître js pour filtrer et trier les tableaux, beaucoup de gens veulent faire certaines choses, mais il est difficile de comprendre le code comme

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

donc pas besoin de faire des choses compliquées pour ce type de personnes, si nous pouvons donner une solution simple pour cela et que ce soit bon pour les développeurs.

Une alternative possible est de conserver les filtres mais uniquement pour les interpolations de texte - c'est-à-dire que vous ne pouvez l'utiliser qu'à l'intérieur des {{ }}, pas dans les directives.

Je pense que cela pourrait être un très bon compromis. Bien que cela ne satisfasse pas tout le monde, c'est tout ce pour quoi j'ai utilisé des filtres et je trouve en fait bizarre qu'ils puissent actuellement faire plus que cela.

Cela permettrait un formatage de texte pratique si vous souhaitez utiliser des filtres et réduire la complexité en supprimant efficacement les filtres bidirectionnels.

À mon avis, votre exemple de filtre momentjs transmet déjà trop de logique aux modèles.

Sérieusement, vous devriez diriger tout ce "pipe love" vers le référentiel de spécifications jusqu'à ce qu'il atteigne TC39 :)

J'aime ce que @yyx990803 et @VitaliyLavrenko ont suggéré. Cela pourrait être un bon terrain d'entente.

Scott

J'aime la proposition de @VitaliyLavrenko , mais quand je dis quelque chose de similaire, à propos d'avoir l'opérateur de pipe dans un plugin @azamat-sharapov a dit que les plugins ne devraient pas déranger le compilateur... Donc je ne sais pas si c'est même possible ou si je juste mal compris le commentaire?

@thelinuxlich

Quoi de mieux pour vous lire ?

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

ou

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

Pensez en tant que développeur et demandez à quelqu'un qui ne connaît pas le javascript.

Quant à moi, pour _pas les développeurs_ mieux quelque chose comme ça :

Vue.use(VueUtils)

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

C'est moyen, et utilisé comme vue-resource juste common lib.

À propos de pipe, je c'est du sucre de syntaxe

chose dans les choses | filtrePar 'foo' | commanderPar 'bar' | limitePar 5

pour

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

Quelle facilité de lecture ?

Si vous avez besoin de transmettre des données à 2 modèles de diff, vous stockez 2 ou 3 modifications pour une donnée ?

S'il s'agit de :

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

C'est une situation abstraite, mais s'il est utilisé dans un ou deux modèles ? Vous avez besoin de stocker des données pour 10 ou 100 objets ? Augmenter l'utilisation de la mémoire ? Oui, nous pouvons utiliser la méthode d'assistance et l'utiliser dans le modèle, mais pour _"Pour les concepteurs de modèles"_ qui sont loin de javascript, mieux vaut quelque chose comme title | padLeft 10 et il devrait être traduit en appel de fonction, c'est simple et fonctionnel.

Pensez aux personnes différentes, les développeurs peuvent facilement le faire de manière différente, mais d'autres personnes veulent le faire simplement.

Je le répète, trop de logique dans les templates est un anti-pattern. Au lieu d'avoir à apprendre un DSL spécifique (filtres), vous devriez apprendre Javascript.

@thelinuxlich Utilisez simplement JSX et nous obtenons React avec une liaison bidirectionnelle et quelques autres choses.

Mais avec Vue, nous obtenons des gens qui ne connaissent pas javascript, mais avec Google, ils peuvent faire quelque chose et si vous n'aimez pas le pipe, ne l'utilisez pas. Nous pouvons simplement ajouter quelque chose comme

Vue.config.pipeFuncCall = true

Et vous pouvez l'activer/le désactiver, mais pour certaines personnes, c'est facile.

_Je le répète, non seulement les développeurs JS peuvent utiliser Vue, c'est le côté le plus fort de Vue._

Les filtres communs standard sont nécessaires, mais il vaut mieux qu'ils soient dans une bibliothèque séparée et qu'il soit facile de les ajouter à la vue et à l'utilisation.

Ou vous voulez que Vue soit quelque chose comme ASM et que seuls les bons développeurs puissent l'utiliser ?

Les gars, je pense que la décision prise par l'équipe principale de Vue a été très bien expliquée. Ne pouvons-nous pas répéter la même chose encore et encore et commenter uniquement avec quelque chose de nouveau, de précieux, le cas échéant ?

Si cela fait partie des principes de base de Vue d'être plus facile pour les développeurs non-JS, même si cela nuit aux principes du langage, alors je serai d'accord avec vous, mais ce n'est probablement pas le cas.

Comme je l'ai déjà dit, je suis généralement d'accord avec les filtres obsolètes, ils me manqueront sûrement pour des raisons de commodité, mais je suis plus que sûr qu'un système de filtre très similaire peut être introduit en tant que plugin.

J'ai donné un exemple de preuve de concept un peu plus tôt, qui pourrait être utilisé dans des accessoires calculés, ainsi qu'en ligne

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

D'un autre côté, si quelqu'un veut le tuyau, je suis sûr que cela peut être fait, avec quelque chose comme ça

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

Ou peut-être, s'il y avait un crochet qui permettrait aux plugins d'analyser les expressions et de les traiter comme ils le souhaitent, cela pourrait également être un moyen possible, mais cela dépend uniquement de la complexité de sa mise en œuvre et des effets que cela aurait sur le framework (performances/taille), et si @yyx990803 voudrait effectivement aller dans ce sens ou pas !

J'ai l'impression que si on nous donne des alternatives élégantes, faciles à utiliser (Plugins ou quelque chose dans le noyau), nous nous y habituerons assez rapidement.

@ rigor789 pour filtrer les tableaux et les trier, etc., mieux utiliser les calculs, c'est beaucoup plus propre. Mais je pense que problème pour afficher les données au format diff:

si nous avons le champ created_at et que nous avons besoin dans le modèle de le rendre au format jj.mm.AAAA ou dans les liens

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

pour ces filtres utilisés bien maintenant, quelle alternative pouvons-nous obtenir de 2.x ?

Pour l'instant n'utilisez que

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

et définissez la méthode de date, mais cela rend le modèle sale, si vous stockez 3 champs supplémentaires, cela coûte de la mémoire, et s'il s'agit de 100 à 200 objets, cela devient lourd.

Voici la décision finale :

1. Les filtres seront pris en charge, mais uniquement à l'intérieur des interpolations de texte. Cela les limite à des fins de formatage de texte tout en appliquant une autre logique dans JavaScript land.
2. Vue 2.0 sera livré sans filtres intégrés. La communauté peut créer ses propres packs de filtres si nécessaire.
3. La syntaxe du filtre changera pour utiliser la syntaxe d'appel de fonction pour les arguments au lieu d'être délimitée par des espaces. Cela le rend plus conforme à JavaScript et à d'autres langages de modèles populaires (Jinja2, swig, twig...) :

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

Merci d'avoir écouté Evan. C'est ce qui rend Vue génial. Il a un grand chef. :le sourire:

Scott

@yyx990803 & @chrisvfritz

Une chose qui semble avoir été enterrée dans cette discussion est les filtres à double sens. Les filtres bidirectionnels sont ceux qui sont les plus difficiles à reproduire avec les autres solutions proposées.

1. Considérez cet exemple simple , que j'ai posté dans ce fil de discussion. L'utilisation de propriétés calculées pour cela aurait 2 principaux inconvénients :
   
   
   
   1. Vous devrez créer une nouvelle propriété calculée pour chaque valeur, ce qui entraînera une tonne de code passe-partout.
   
   
   2. Pour aggraver les choses, les propriétés calculées ne peuvent même pas être imbriquées . Si vous avez un graphique d'objets plus complexe, toutes vos propriétés calculées devront être au niveau supérieur. Vous vous retrouveriez avec des noms de propriété longs et verbeux nécessitant plus de surcharge cognitive pour suivre en permanence quelle propriété calculée suit quelle valeur imbriquée.
   
   

Rejeter ce cas d'utilisation comme "trivial" ou "moins compliqué" est contre-productif. Je l'ai utilisé sur des applications à moyenne et grande échelle. Il a fait des merveilles ! La démo est forcément simple, mais la technique est solide.

1. Ceci est encore plus confus lorsqu'il s'agit d'un tableau dans v-for , comme dans cet exemple (encore une fois, intentionnellement simple). En itérant sur un tableau, vous ne trouverez aucun recours dans les propriétés calculées. La seule façon de contourner ce problème consiste à disposer d'un composant distinct pour chaque élément du tableau, en ajoutant encore plus de passe-partout.

Comparez cet exemple avec des filtres :

``` js
importer une devise à partir de 'some-currency-filter' ;
importer des produits à partir de 'produits-stub' ;

nouveau Vue({
el : document.body,
données : { produits },
filtres : { devise },
});
```

À un sans filtres :

``` js
importer une devise à partir de 'some-currency-filter' ;
importer des produits à partir de 'produits-stub' ;

nouveau Vue({
el : document.body,
données : { produits },
Composants: {
produit: {
accessoires : ['produit'],
calculé : {
le prix: {
avoir() {
return currency.read(this.product.price);
},
ensemble (valeur) {
this.product.price = devise.écrire(valeur)
}
},
expédition: {
avoir() {
return currency.read(this.product.shipping);
},
ensemble (valeur) {
this.product.shipping = devise.écrire(valeur)
}
},
manutention: {
avoir() {
return currency.read(this.product.handling);
},
ensemble (valeur) {
this.product.handling = currency.write(valeur)
}
},
réduction: {
avoir() {
return currency.read(this.product.discount);
},
ensemble (valeur) {
this.product.discount = currency.write(valeur)
}
}
}
}
}
});
```

Je sais lequel des éléments ci-dessus je voudrais écrire.

_{(cela pourrait peut-être être nettoyé un peu en créant des fabriques de propriétés calculées, mais le fait demeure que celles-ci sont beaucoup plus détaillées que nécessaire)}

Étant donné que l'équipe principale semble fermement opposée à la syntaxe du tube de filtrage, serait-il possible d'introduire un filter pour la directive v-model ?

Avec un filter , nous pourrons conserver la première version élégante du JS ci-dessus, et simplement réécrire le modèle pour utiliser le paramètre au lieu de la syntaxe du tube magique :

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

Cela trouverait le bon équilibre entre ne pas avoir de syntaxe magique tout en conservant la possibilité de convertir facilement les entrées dans les deux sens sans trop de passe-partout.

Merci pour votre considération.

J'ai réécrit votre exemple pour incorporer votre filtre en tant que directive personnalisée : jsfiddle .
Bien qu'il ne soit pas aussi concis qu'un filtre, il n'est pas aussi douloureux que je l'imaginais. Et il ne m'a pas fallu beaucoup de temps pour assembler les pièces à partir de choses qui sont déjà disponibles pour nous tous.

@Nirazul créer des directives dédiées pour chaque filtre a déjà été proposé . Avoir besoin de créer une nouvelle directive qui réimplémente toutes les fonctionnalités v-model pour chaque type de filtre que vous utilisez dans votre application est tout simplement absurde.

De plus, votre directive ne fonctionne même pas complètement comme des filtres ; brouiller le champ après avoir changé la valeur ne le reformate pas. De plus, v-model fait bien plus que vous dans cette directive.

La directive peut évidemment être modifiée avec plus de fonctionnalités et de correctifs, mais le point demeure : ce sont tous des pansements en plus de quelque chose qui devrait être très simple dès la sortie de la boîte.

Je n'ai vu aucune proposition dans ce fil mentionnant des directives personnalisées. Pourriez-vous m'indiquer ce commentaire ?

Comme vous pouvez l'imaginer, je ne l'ai pas écrit et testé pour que vous l'utilisiez dans votre application. Je voulais juste montrer, ce qui est possible en ce moment comme alternative. Si cela est possible si facilement, il y a peut-être de la place pour un plugin pour automatiser encore plus le processus.
Il est évident que cette directive écrite rapidement ne dispose pas de toutes les fonctionnalités du v-model. Peut-être qu'une directive de filtre personnalisée combinée avec des paramètres et/ou des modificateurs serait suffisante pour remplacer les filtres.

Restons constructifs, comme j'ai essayé de l'être pour résoudre ton problème. Il est toujours plus facile de s'appuyer sur une solution au lieu d'apporter une contribution et d'aller de l'avant.

@JosephSilber vous avez besoin de vous détendre. "absurde" est un mot fort.

Salut, La suppression du filtre est-elle motivée par la réduction de l'encombrement des modèles ou affecte-t-elle sérieusement
l'implémentation technique du 2.0 ? S'il s'agit d'un ancien problème d'effet visuel, pourquoi ne pas autoriser
filtre comme maintenant (mais avec le nouveau formulaire javascript)
mais en le limitant à un seul par expression, comme v-for="i of list | orderBy('key')", (pas plus d'un signe pipe)
cela pourrait rendre le traitement des filtres dans 2.0 plus simple et prévisible et moins encombré visuellement.
Puisqu'il y aura une analyse de filtre pour {{}}, l'autoriser dans d'autres expressions aurait du sens.
cela s'adapterait à tous les cas d'utilisation/fonctions existants (comme le filtrage bidirectionnel, élément dans v-for).
Toutes les utilisations existantes de plus d'un filtre peuvent être facilement fusionnées/mises à niveau en une seule par les propriétaires.

@tomsmithgroup Ce que vous avez suggéré (et plus que cela) a été décidé pour rester pris en charge dans la version 2.0.

@yyx990803 & @chrisvfritz aimeraient connaître votre avis sur les filtres bidirectionnels .

@JosephSilber Donc, avec la fabrique de propriétés calculées à laquelle vous avez fait allusion, il n'y a même pas beaucoup de passe-partout:

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'])
    }
  }
})

Bien que personnellement, je ne créerais pas d'usine pour cet exemple, car chacune de ces propriétés sont en fait des préoccupations distinctes qui _apparaissent_ identiques pour le moment. Lorsque vous supprimez des filtres, il devient beaucoup plus évident à quel point ce composant était complexe. C'est ce que vous voyez comme passe-partout.

Et c'est une énorme raison pour laquelle les composants _existent_. Diviser la complexité en préoccupations gérables. Lorsque je regarde un composant, tout ce qu'il fait doit s'intégrer facilement dans ma mémoire de travail, sinon le développement devient beaucoup plus lent et plus sujet aux erreurs. Cacher la complexité derrière la syntaxe des filtres ne supprime pas cette complexité.

Pour le démontrer, examinons ce qui se passe lorsque le problème répond aux exigences changeantes du monde réel : supposons que vous décidiez que la remise ne devrait pas être supérieure au prix + expédition + manutention. Ou la manipulation ne doit pas dépasser le montant X. Ou le champ de remise doit être un pourcentage, au lieu d'une devise. Ou si le total dépasse un certain montant, une remise minimale doit automatiquement être appliquée.

Vous pourriez être tenté de rendre le filtre plus complexe avec des options supplémentaires et une logique conditionnelle. Au fur et à mesure que vous mettez à jour l'API et la logique interne du filtre, vous devez maintenant réfléchir à la manière dont vos modifications pourraient affecter tout ce qui consomme le filtre - peut-être même en dehors du composant actuel, s'il s'agit d'un filtre partagé. Alors maintenant, vous êtes dans une situation où apporter des modifications à votre application commence à vous sembler intimidant. Et c'est parce qu'un double filtre partagé vous a permis de déléguer l'état du composant interne à l'extérieur du composant, violant les limites du composant, augmentant le couplage et masquant la complexité à laquelle vous devez toujours penser chaque fois que vous travaillez sur le composant.

En décomposant les éléments en plusieurs composants individuellement moins complexes, avec des propriétés calculées ou des accessoires liés définis séparément, vous mettez souvent à jour une ligne pour vous adapter à une exigence changeante. Pas d'options ou de conditions supplémentaires. Aucune refactorisation pour satisfaire la complexité de mise à l'échelle. Vous n'avez pas à penser à quoi que ce soit en dehors du composant _ou même en dehors de cette propriété unique_. Votre application était depuis le début et reste toujours facile à penser et à mettre à jour.

Je pense que ce qui rend les filtres initialement séduisants dans ce cas, c'est qu'ils sont un remède facile à atteindre contre la duplication. Mais la duplication n'est pas passe-partout lorsqu'elle est accessoire (c'est-à-dire que le code se trouve être le même en ce moment, avant que les problèmes du monde réel ne commencent inévitablement à arriver).

Et je ne peux pas mieux dire que Sandi Metz :

la duplication est beaucoup moins chère que la mauvaise abstraction

@chrisvfritz Les filtres n'ont absolument rien à voir avec les exigences de l'entreprise. Les filtres formatent simplement les données. C'est ça. Ils ne le manipulent en aucune façon, forme ou forme. filter="currency" est conceptuellement identique au number . Les exigences métier ne doivent évidemment jamais être traitées dans les filtres.

Supposons que vous décidiez que la remise ne devrait pas être supérieure au prix + expédition + manutention. Ou la manipulation ne doit pas dépasser le montant X.

Ensuite, vous utiliseriez un module de validation approprié, à la vue-validator . Le filtre de devise restera en place malgré tout, affichant simplement la valeur sous-jacente.

le champ de remise doit être un pourcentage, au lieu d'une devise.

Alors évidemment son type n'est plus monnaie. Ce n'est pas différent si vous échangez un type="text" contre type="email" lorsque les exigences du nom d'utilisateur changent. Ou même lorsque vous supprimez le paramètre number lorsqu'un champ n'est plus un nombre.

si le total dépasse un certain montant, une remise minimale doit automatiquement être appliquée.

Encore une fois, le minimum sera appliqué, mais le filtre de devise restera en place. Vous voudriez toujours l'afficher en tant que devise.

Lorsque vous mettez à jour l'API et la logique interne du filtre, vous devez maintenant réfléchir à la manière dont vos modifications pourraient affecter tout ce qui consomme le filtre [...] deux filtres vous ont permis de déléguer l'état du composant interne à l'extérieur du composant

Non. Vous _jamais_ mettez une logique ou un état dans le filtre lui-même. Le filtre est une fonction idempotente strictement pour le formatage des valeurs. Idéalement, il ne devrait même pas être exécuté dans le contexte de la VM ; il ne devrait pas y avoir de this partir desquels extraire des données supplémentaires.

la duplication est beaucoup moins chère que la mauvaise abstraction

... quand, comme vous l'avez dit, vous extrayez du code qui se trouve être le même en ce moment. Les filtres, en revanche, sont de simples fonctions idempotentes qui formatent une valeur. Ils ne sont pas du tout une abstraction.

Les filtres tl;dr ne sont pas une abstraction et ne remplacent pas une exigence commerciale explicite. Les filtres n'ont jamais de logique interne et ne devraient jamais l'être. Ils sont conceptuellement similaires à l'attribut type du HTML et au paramètre number du v-model number

Le filtre bidirectionnel est certainement une abstraction. Le comportement actuel des filtres bidirectionnels sur v-model cache beaucoup de magie à l'intérieur - en particulier, il permet à la valeur DOM de l'entrée d'être temporairement désynchronisée avec le modèle sous-jacent, et ne les "synchronise" que lorsque vous brouiller le champ. BTW @JosephSilber ce comportement a été implémenté spécifiquement en raison de votre demande, donc je peux comprendre pourquoi vous vous sentez si fortement à ce sujet.

Cependant, le plus gros problème que je vois avec les filtres bidirectionnels est que la logique sous-jacente est une boîte noire et que l'utilisateur n'a aucun moyen de la personnaliser davantage que de faire des demandes de fonctionnalités. Pour moi, la meilleure option consiste à fournir les éléments de base appropriés pour mettre en œuvre vous-même un tel comportement. Et laissez-moi vous montrer comment cela est possible en 2.0 :

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

Ici, nous avons un composant de base CustomInput qui implémente le comportement "hors synchronisation jusqu'au flou" des filtres bidirectionnels actuels. En raison des modifications apportées à la version 2.0, vous pouvez utiliser directement v-model sur des composants personnalisés tant que le composant accepte un accessoire value et $émet des événements input . En outre, il formate également la valeur sur les événements change , ce qui n'est actuellement pas possible avec les filtres bidirectionnels . Vous pouvez encore ajuster ce composant pour obtenir le comportement souhaité sans être lié à la façon dont les filtres bidirectionnels sont implémentés par le framework.

Le composant de base n'implémente pas la logique d'analyse/de formatage - vous l'étendez avec les méthodes parse et format pour obtenir des composants d'entrée personnalisés adaptés à des cas d'utilisation spécifiques. Dans ce cas, un composant CurrencyInput .

Le composant de base est plus complexe que les filtres bidirectionnels, car nous implémentons maintenant nous-mêmes le comportement magique précédent. Cependant, vous n'avez besoin de définir ce composant qu'une seule fois. En retour, vous obtenez un contrôle total sur la façon dont il doit se comporter au cas où vous souhaiteriez le modifier ultérieurement. Je crois que c'est un compromis valable.

Ceci est un exemple de la façon dont nous devrions penser davantage aux composants car c'est une abstraction unifiée pour la réutilisation qui vous donne le plus de contrôle. Voir également l' exemple select2 2.0 - auparavant, dans la version 1.0, cela était implémenté sous forme de directive, mais maintenant c'est un composant avec la même interface v-model .

Pour moi, la meilleure option consiste à fournir les éléments de base appropriés pour mettre en œuvre vous-même un tel comportement.

C'est génial et certainement ce dont Vue a besoin, mais j'aurais aimé lire ceci

Pour moi, la meilleure option consiste à fournir les éléments de base appropriés pour démarrer avec Vue et à étendre également Vue avec un nouveau comportement de filtrage vous-même.

En d'autres termes, le composant d'entrée de devise ainsi qu'un certain nombre d'autres composants de filtrage par défaut ne pourraient-ils pas faire partie de Vue ? Parce que tout le monde utilise des devises à un moment donné, n'est-ce pas ? Pourquoi laisser tout le monde faire le même travail encore et encore ? Le formatage des devises est suffisamment standard pour en faire une partie du propre sac à outils des composants de filtrage de Vue et ils constituent un excellent exemple de base pour que d'autres apprennent à créer leurs propres composants de filtrage.

Et ..... il ne manque qu'une seule chose dans l'exemple pour être un composant d'entrée de devise fini et c'est une fonctionnalité i18n, que je pense que Vue devrait également impliquer. Le formatage du numéro de devise doit changer en fonction des paramètres régionaux sélectionnés par la personne (le spectateur). Je veux dire les données locales, c'est-à-dire . "DE_de" pour formater la devise et d'autres nombres comme indiqué dans cet explorateur de paramètres régionaux (qui découle d'une norme). Ajoutez cela dans Vue et vous avez un excellent système de composants de formatage de devises / nombres intégré directement dans Vue, que les 1000 autres développeurs qui utilisent Vue n'ont pas besoin de se créer eux-mêmes, mais peuvent plutôt utiliser directement sur place, quand ils obtiennent Vue . Cela fait de Vue un système de template puissant !

Si l'utilisation de ce "composant de formatage i18n" ne peut pas être utilisé de manière chaînée en tant que filtre comme dans la version 1.0, il devrait être pluggable. Ce serait bien aussi. C'est ce que fait Aurelia et c'est aussi ce que fait Twig avec ses extensions . Le composant d'entrée de devise pourrait toujours être <currency-input> .

Cet i18n et d'autres filtres de modèles standard doivent vraiment être quelque chose que les autres n'ont pas besoin de reproduire constamment, s'ils n'ont pas à le faire. Si vous me montriez comment faire un tel plug-in, je ferais même le plug-in i18n pour vous. ça m'intéresse dans l'ensemble ! :sourire:

Scott

Parce que tout le monde utilise des devises à un moment donné, n'est-ce pas ?

Non, pas vraiment. Pour ma part, je ne l'ai jamais vraiment utilisé :) La même chose s'appliquerait à tous les autres filtres intégrés - certains d'entre eux sont utiles à certains d'entre nous, quand les autres sont tout simplement inutiles. Pendant que nous sommes sur ce sujet, la plupart du temps, je voulais utiliser un filtre intégré, j'ai quand même fini par écrire ma propre version, rendant le code mort de la version intégrée.

une fonctionnalité i18n, que je pense que Vue devrait également impliquer.

C'est, encore une fois, très discutable. Un support i18n complet peut être assez complexe, et IMO n'appartient pas à Vue, surtout lorsque la plupart des utilisateurs n'en auront de toute façon pas besoin.

Maintenant, je voudrais soulever ceci : chaque fois que nous essayons de faire une comparaison entre Vue et un autre modèle/framework, il y a une chose essentielle à garder à l'esprit : contrairement à Django/Laravel/Twig, Vue est essentiellement une bibliothèque cliente, et donc doit être le plus léger possible. Il serait plus logique de le garder assez simple - tout en conservant toutes les fonctionnalités _core_ bien sûr - au lieu d'ajouter des "fonctionnalités" et des "utilitaires" juste pour le soi-disant "utilité" ou "élégance". Si vous voulez autre chose que des fonctions de base, la meilleure solution serait d'utiliser un plugin ou même de développer le vôtre. Prenons ceci comme exemple : pour un SPA courant, est-ce que i18n/currency est plus vital qu'un routeur ou qu'un gestionnaire d'état ? Je ne pense pas. Et pourtant, vue-router et vuex n'appartiennent pas à Vue, mais ont leurs propres référentiels. En d'autres termes, Vue est progressif .

Si vous me montriez comment faire un tel plug-in, je ferais même le plug-in i18n pour vous. ça m'intéresse dans l'ensemble !

Je pense que c'est une approche plus sensée, et merci pour votre intérêt :)

si beaucoup auront besoin d'utiliser i18n dans certains domaines)) je pense que je peux entrer dans le code et changer manuellement quelques noms de certaines choses, pour la beauté.
Par exemple: il y a quelques heures à peine, il m'a fallu butstrap.datepikker - Je ne me connecte pas, i18n malgré le fait qu'il existe une telle possibilité. Rapide 60 secondes. "Manuellement" a remplacé les noms des jours de la semaine et des mois, et tout - ok ! ))

@phanan - Votre argumentation est la raison pour laquelle j'ai mentionné les "plugins". Je suis d'accord, tout le monde ne voudra pas la monnaie ou la fonctionnalité i18n et ceux qui ne peuvent pas garder leur application légère, mais en tant que système de modèles, je pense (et c'est vraiment mon opinion personnelle) Vue devrait également avoir une telle fonctionnalité standard disponible trop. Plus important encore, et ma préoccupation, c'est qu'il ne devrait pas être que tout le monde doive réinventer les roues de composants de filtre i18n ou monétaire. En d'autres termes, tout comme Vue-Router et Vuex sont des ajouts disponibles à Vue, un bon nombre de filtres standard comme la devise et i18n pourraient l'être aussi.

Oh, et assez intéressant, Angular a intégré i18n, semble-t-il.

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

Angular prend en charge i18n/l10n pour les filtres de date, de nombre et de devise.

Ember et React semblent avoir suivi la voie "laisser le monde des développeurs le faire par eux-mêmes".
Vidéo intéressante.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Peut-être que Vue n'a besoin que d'une intégration à FormatJS ? Vue Intl ? :le sourire:

Edit : Cela ne peut pas être aussi simple, n'est-ce pas ? https://github.com/learningequality/vue-intl/blob/master/index.js

Scott

Angular a i18n intégré, semble-t-il.

Angular est également livré avec ng-router qui, d'après ce que j'ai entendu, est évité par la communauté ng au profit de ui-router.

Maintenant, si l'équipe Angular remplace ng-router par ui-router, cela entraînera des changements et des douleurs.

s'ils essaient d'améliorer ng-router, ils perdent leur temps car une meilleure solution (ui-router) existe déjà.

Si Vue a commencé à prendre en charge i18n, la devise, etc. dans son cœur, la même situation se produira également pour vue.

Je trouve les filtres intégrés pratiques, mais à cet égard, je suis d'accord avec l'équipe vuejs.

Ensuite, nous sommes tous d'accord sur le fait que les filtres ne sont pas dans le noyau de Vue. Je suis aussi un fan de componentization en fait. Mais, Vue ne pourrait-il pas également proposer les filtres en tant que plugins de base ? Comme Vuex et Vue-Router ?

Scott

Mais, Vue ne pourrait-il pas également proposer les filtres en tant que plugins de base ? Comme Vuex et Vue-Router ?

C'est exactement ce que @blake-newman a partagé plus tôt.

Salut : la page de décision finale indiquait qu'il n'autorisait que le filtre pour le texte
afficher {{}} (v-texte)
pas pour d'autres expressions comme v-for="item of list | sortBy"
Ou ai-je mal compris ?
Ce que je voulais dire, c'était continuer à avoir un filtre comme dans la version 1.0 mais en limitant un seul filtre
par expression

Le dimanche 1er mai 2016 à 22h24, Phan An [email protected] a écrit :

@tomsmithgroup https://github.com/tomsmithgroup Ce que vous avez suggéré
(et plus que cela) ont été décidés
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 à
restent pris en charge dans la version 2.0.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@ yyx990803 Puis-je conclure de votre réponse que les filtres bidirectionnels ne seront pas pris en charge dans la version 2.0 ?

@fnlctrl c'est exact. Construisez simplement vos propres composants.

Je vais faire un petit hors-sujet : ces filtres bidirectionnels sont-ils vraiment utiles en production ?
Je veux dire, est-il vraiment acceptable de laisser l'utilisateur saisir quoi que ce soit dans une entrée, puis de la reformater une fois qu'elle est floue ?
Mon équipe commerciale exige toujours nos entrées à agir comme cela : vous ne pouvez pas taper quelque chose de mal. Donc, même maintenant, avec Vue nous utilisons jquery.inputmask à cette fin, car le changement instantané dans les deux sens est devenu obsolète (celui-là me manque vraiment ...)
Je veux dire, y a-t-il vraiment un problème avec ces filtres à double sens ou les gens y réfléchissent-ils trop? :)

@fullfs Les filtres bidirectionnels sont largement utilisés dans notre application de production (beaucoup de <input> s) pour plus de commodité, mais comme je le vois maintenant, pourquoi filtrer les valeurs en temps réel au lieu de simplement les filtrer une fois avant qu'elles ne le soient POST-ed sur le serveur ? Il faudra du temps pour refactoriser le code, mais je pense que je ne les manquerai pas :D

Si vous souhaitez une mise à jour optimiste de l'interface utilisateur (ce qui est la norme aujourd'hui à mon humble avis, en particulier pour les mobiles), vous souhaiterez que l'entrée soit correctement formatée pratiquement au moment où l'entrée a été donnée.

Scott

Les filtres à 2 voies sont vraiment agréables à voir. Vous pouvez toujours créer vos propres composants personnalisés, avec ou sans filtres disponibles, mais cela prend du temps. La bibliothèque doit offrir de la flexibilité, mais aussi un moyen plus rapide et pratique de faire les choses. L'inclusion de filtres bidirectionnels n'empêcherait pas les utilisateurs de créer leurs propres composants s'ils le devaient, mais permettrait un développement plus rapide lorsque la fonctionnalité existante correspond aux besoins, ce qui est la plupart du temps. C'est toujours un compromis entre la surface API et la commodité. L'équilibre doit être trouvé, et Vue en avait déjà un excellent. Se débarrasser des filtres semble être un pas en arrière par rapport au bon point d'équilibre. La bibliothèque devient plus petite, mais la base de code et le passe-partout de tous les projets qui l'utilisent grandissent.

Si les filtres doivent vraiment être obsolètes, il serait peut-être bon de fournir une alternative capable de spécifier un analyseur et un formateur pour les directives du modèle v, de manière simple. Avec les filtres, vous pouvez écrire uniquement cette partie de l' exemple @yyx990803 fourni :

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

Sans filtres à 2 voies, il faut aussi écrire

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

Donc, plus de flexibilité, mais aussi plus de code pour le même résultat.

@aristidesfl - les filtres ne sont pas obsolètes. Nous avons gagné la bataille, partiellement. MDR! Ils seront limités à être utilisés uniquement dans les interpolations de texte. Voir ici : https://github.com/vuejs/vue/issues/2873

Scott

Merci @smolinari . Je parlais en particulier des filtres à 2 voies.

s'il te plait reviens! nous en avons besoin, je suis d'accord avec tout ce que vous avez dit. mais c'est si facile, nous sommes des utilisateurs paresseux, nous voulons juste un moyen paresseux et facile. tout comme keep-alive.

Peut-être devrait-il y avoir un moyen d'ajouter des modificateurs de modèle v personnalisés (http://rc.vuejs.org/guide/forms.html#Modifiers)

Ils fonctionnent comme des filtres bidirectionnels.

@ecmel a accepté. C'est la voie à suivre.

Ouvrez un problème de demande de fonctionnalité alors :)

@ecmel une idée similaire, bien que décrite comme des modificateurs de type, a été discutée ici .

@rpkilby Cette discussion est également fermée, nous devrions peut-être en ouvrir une nouvelle pour les modificateurs de modèle v personnalisés.

Ne plus pouvoir faire ceci :

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

Limiter les filtres à {{ }} semble étrange, il y a de nombreuses fois où vous voudriez utiliser un filtre dans une liaison d'attribut (sans passer de prop), et nous ne pouvons plus utiliser {{ }} dans les attributs !

@LinusBorg Ouvert https://github.com/vuejs/vue/issues/3666

Limiter les filtres à {{ }} semble étrange, il y a de nombreuses fois où vous voudriez utiliser un filtre dans une liaison d'attribut (sans passer de prop), et nous ne pouvons plus utiliser {{ }} dans les attributs !

Ils ont été supprimés car ils peuvent être facilement remplacés par des propriétés et des méthodes calculées, tout en ayant eux-mêmes une API plus limitée et aucune possibilité de mise en cache des résultats.

Alors:

• une API de moins
• utilisez les mêmes méthodes dans le modèle et le code JS, pas besoin de dupliquer le comportement du filtre à utiliser dans le code de l'application.
• les accessoires calculés peuvent être mis en cache
• plus de flexibilité car c'est juste du JS

pseudocode devant :

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

Désolé, je ne suis que "nouveau".
Mais venant d'Angular 1, ne pas avoir de filtres semble vraiment étrange et contre-intuitif, pourquoi serait-il préférable que chaque développeur développe son propre ensemble de filtres et définisse lui-même les entrées calculées, etc. mieux que de l'intégrer?
Et ce qui est maintenant considéré comme la meilleure pratique pour filtrer un très grand tableau, par objets dans l'élément. Avec angular, il ne s'agissait que d'une seule ligne de code. Il était possible de filtrer un tableau pour une entrée de recherche et cela ferait toute la magie, ce qui devrait être la fonction d'un framework.

Et ce qui est maintenant considéré comme la meilleure pratique pour filtrer un très grand tableau

Qu'est-ce qu'un très grand tableau ? Théoriquement, une propriété calculée serait également utile pour le filtrage.

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

pourquoi serait-il préférable que chaque développeur développe son propre ensemble de filtres et définisse lui-même les entrées calculées, etc. mieux que de l'intégrer ?

J'avais l'habitude de penser de la même manière (et pourquoi j'ai commencé le fil), mais depuis que j'ai appris que c'est fondamentalement un jeu d'enfant de créer ce genre de filtres par vous-même, et qu'il y a tellement de choses que chaque développeur pourrait vouloir en tant que filtre (ou propriété calculée), je me suis rendu compte que ce n'était pas si grave de ne pas avoir de filtres intégrés.

Scott

Dans mon cas, cela équivaut à> 10 000 lignes dans json fournies par une base de données firebase.
Je vois pourquoi vous pourriez penser de cette façon et décider de supprimer la fonctionnalité, mais c'est un problème supplémentaire pour les développeurs.

J'ai fourché le violon pour être en ligne avec ma structure de données :
https://jsfiddle.net/nw5yhLwv/
J'ai donc besoin de coder la recherche d'une chaîne dans mon objet à la main?

Je ne comprends pas votre question. Pardon. Le violon ressemble à celui que j'ai posté.

Scott

Calculé vs filtres

Les filtres sont peut-être mauvais pour les performances, car ils sont calculés pour chaque rendu (tout comme les méthodes) et les propriétés calculées sont faciles à faire et ne sont recalculées que si nécessaire, sinon les résultats sont mis en cache, ce qui signifie que Vue peut voler.

Oh. et nous avons les deux. 😄

Scott

Hey, j'ai bidouillé un peu et maintenant j'ai compris, c'est un super concept ! 😄

Je vais verrouiller ce fil maintenant, car la discussion à ce sujet est terminée depuis longtemps - Vue 2.0 est sorti depuis quelques mois, et la critique sur la chute des filtres s'est largement apaisée.

Une discussion plus approfondie dans ce fil n'est pas productive. Si vous voyez un nouvel angle sur le sujet qui, selon vous, mérite d'être discuté, veuillez ouvrir un nouveau sujet.