Vue: [Sugestão] Vue 2.0 - Traga de volta os filtros por favor

Esclarecendo um ponto que veio originalmente do chat do Gitter: debounce não é um filtro, e foi apenas mais uma das mudanças 2.0 que as pessoas não ficaram empolgadas em perder.

Correção cortesia de @JosephSilber : debounce é um filtro e um parâmetro v-model .

Obrigado @agc93. Eu removi esse ponto.

Scott

Na pior das hipóteses, criaremos pequenos plugins para lidar com isso. Sobre filtros, há https://www.npmjs.com/package/babel-plugin-pipe-operator
O problema é que isso não funcionará sem a compilação do babel

Também não estou muito empolgado com algumas das mudanças. Para filtros, parece haver uma alternativa fácil de registrar mixins globais . No entanto, não gosto muito da ideia de poluir todos os escopos de métodos dos meus componentes para tarefas ultrassimples como pluralizar e assim por diante. Eu nunca usei filtros bidirecionais, no entanto.

Os filtros eram apenas convenientes e bonitos. As duas coisas que o vue sempre fez certo (até agora).

Quando li o post sobre o vue 2.0, fiquei empolgado com todas as novas possibilidades (especialmente o dom virtual e a renderização do servidor), mas também fiquei surpreso e um pouco triste com o fato de os filtros terem desaparecido.

Eles eram uma das minhas partes favoritas do vue, não apenas porque eram facilmente usáveis ​​e encadeáveis, mas principalmente porque eram facilmente extensíveis e tinham uma bela sintaxe para usá-los diretamente no template. Especialmente em combinação com loops v-for , eles eram uma combinação perfeita.

Pensando que terei que usar propriedades computadas para substituir a filtragem para cada prop que eu quiser, estou preocupado em escrever muito clichê no futuro. Embora os mixins possam mitigar uma parte do problema, ainda sinto que faltará uma parte da elegância e facilidade de usar o vue.

Todo mundo que concorda com isso, você pode, por favor, clicar em polegar para cima na descrição? é melhor do que enviar spam para 17 mil pessoas com +1 . Melhor ainda, crie alguns casos de uso significativos.

Nunca usei filtros bidirecionais, mas sentiria muita falta dos filtros! Posso (e às vezes uso) usar propriedades computadas, mas em alguns casos simples, é uma conveniência que realmente acelera o fluxo de trabalho.

Considere este exemplo muito simples

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

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

O acima é muito mais fácil de escrever nos casos em que não é necessário ter uma filtragem mais complexa.

Agora compare com o seguinte

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

Eu não estou dizendo que o segundo é difícil de escrever, mas quando você o usa em muitos lugares, você começará a se repetir, e isso leva algum tempo extra que você talvez possa usar em alguns outros recursos mais úteis!

De qualquer forma, permanecerei um usuário Vue feliz, apenas compartilhando minha opinião sobre os filtros sendo obsoletos!

Os filtros são reutilizáveis. Posso criar uma função para formatar meus dados uma vez, registrá-los como filtro e usar apenas de todas as instâncias. Como posso fazer isso em 2.0?

Como posso fazer isso em 2.0?

• Mixin
• Módulo separado com método
• Módulo separado com função prop computada

Acabei de deixar um comentário no tópico de anúncio, então, em vez de duplicar tudo aqui, vou simplesmente criar um link para ele:

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

Eu entendo totalmente a sensação de algo super conveniente sendo tirado de você. Mas primeiro, por favor, reserve um momento para ler o comentário de @chrisvfritz no tópico do fórum acima. Para facilitar a discussão, estou apenas copiando e colando aqui:

@theotherzach Obrigado por sua paixão pelo Vue! Eu gostaria de explicar a depreciação um pouco melhor, mas primeiro, devo me apresentar. Sou membro da equipe principal do Vue, uso Vue o tempo todo para meu trabalho freelancer de UI e visualização de dados, e também sou um educador que ensina as pessoas a usar Vue e Rails, entre outras tecnologias da web. Eu dirijo uma escola de código, então ajudo as pessoas a aprender a usar essas ferramentas (e usá-las juntas) quase _todos os dias_.

Eu também fui um dos grandes defensores da remoção de filtros no Vue 2.0.

O problema com filtros para iniciantes no Vue

Uma grande parte do motivo pelo qual eu era a favor de preterir filtros era na verdade _para_ iniciantes. Ao trabalhar com alunos, esta é uma conversa que surge mais de uma vez:

• Aluno: "Então um filtro é basicamente uma função?"
• Mentor: "Sim!"
• Aluno: "OK, posso usar normalmente com parênteses de função?"
• Mentor: "Bem, não. É um tipo especial de função."
• Aluno: "Posso usar em outros lugares? Como em um valor calculado?"
• Mentor: "Não, você só pode usá-lo em templates e apenas com a sintaxe de pipe especial."
• Aluno: "... por quê?"

Uma das grandes coisas que atrapalham os iniciantes são as _exceções_. Os filtros são apenas funções, _exceto_ eles requerem uma sintaxe especial e não podem ser usados ​​em todos os lugares. E eles usam uma sintaxe de pipe que é diferente da sintaxe de pipe que pode ser integrada ao ES7 , o que significa que não demorará muito até que as pessoas tenham dois operadores muito semelhantes para fazer algo muito semelhante, mas eles não são _muito_ os mesmos. E apenas um deles é realmente JavaScript.

Bibliotecas Util _são_ úteis, mas Vue não é uma

No caso de filterBy , transformações para strings e números, e outros filtros específicos, sim, são úteis nas aplicações onde surgem. Bibliotecas Util em geral são úteis. E existem dezenas de ótimas bibliotecas utilitárias para escolher, mas o Vue não é uma biblioteca utilitária. E, francamente, nenhum dos utilitários que oferecemos foi o melhor da categoria.

Manipular moedas, datas ou até mesmo filtrar arrays - esses não são nosso foco. Muitos aplicativos não os exigem e a maioria dos aplicativos em que trabalhei que _faz_ enfrentam esses problemas exigem uma solução mais robusta do que o Vue oferece atualmente (ou _poderia_ oferecer sem introduzir inchaço significativo e reinvenção da roda).

Em meus aplicativos, Accounting.js lida com moeda de forma excelente, Moment.js (como você mencionou) lida com datas e horas, pluralize não lida bem com muitas pluralizações, portanto, um valor calculado personalizado geralmente é mais desejável e json é pouco mais que JSON.stringify .

As vantagens das propriedades computadas

O uso de propriedades computadas no lugar de filtros também oferece a vantagem de que o valor processado pode ser facilmente reutilizado de maneira DRY _em qualquer lugar_ no componente. Eu me vejo tendo que fazer isso em meus aplicativos o tempo todo. A propriedade computada também move mais detalhes de implementação para fora do modelo, deixando apenas uma descrição clara do que o componente faz. E uma vantagem sobre os filtros definidos globalmente é que basta olhar para a função desse valor de computador para ver e ajustar exatamente como está funcionando. Em arrays, encadear os métodos map e filter do JavaScript ainda fornece a mesma lista linear de processamento que os pipes fazem, mas de uma maneira ainda mais declarativa e facilmente manipulável.

A utilidade de qualquer definição globalmente definida

Se você precisar definir uma função ou qualquer outra coisa que queira acessível em todos os seus componentes, Vue.prototype.whateverIWant = mySuperCoolFunction é uma ótima maneira de fazer isso. Pessoalmente, eu nunca quis fazer isso. Sempre preferi colocar um método auxiliar em um módulo e importar esse módulo onde preciso. Mas ainda é importante notar que registrar globais - de qualquer tipo - não é mais difícil.

O caso da diretiva debounce

Eu tenho que dizer, eu estou realmente com você em um presente! Recentemente, examinei todos os meus projetos Vue e cada um que tinha um input em algum lugar também usava debounce . Na verdade, apenas um dos meus aplicativos anteriores _não_ usava debounce. Embora tecnicamente seja um utilitário - lodash e muitos outros projetos robustos oferecem soluções de debounce - esse problema é bastante universal para o desenvolvimento de interface do usuário, para _qualquer_ tipo de aplicativo. Escrever sua própria função debounce também não é trivial o suficiente para que eu provavelmente queira usar a implementação do lodash para quase todos os projetos.

Ainda há algum debate interno sobre isso, então vamos ver até onde vai. Mas sim, para mim pessoalmente e parece também alguns outros, remover debounce remove a maior parte da conveniência oferecida por v-model .

Mais uma vez, obrigado por sua paixão!

Sério, nós amamos o quanto você ama o Vue e estamos muito felizes por você estar expressando suas preocupações - e especialmente de uma maneira tão gentil e respeitosa! Estamos te ouvindo. A equipe principal é composta por designers, desenvolvedores front-end e especialistas em visualização de dados. Todos nós usamos o Vue para nosso próprio trabalho, que é bastante diversificado, então estamos definitivamente dedicados a lançar comida de cachorro que queremos comer. :-)

Falar é barato, vamos codificar para ver se sem filtro, como aplicamos filterBy e reverse:

escreva funções de filtro puro global em um arquivo separado para reutilização de código

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

usar filtros no modelo 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>

veja o resultado aqui http://raywill.github.io/vuefilter/

Se o filtro for usado, o código vue a seguir faria o mesmo:

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

Aparentemente, com suporte a filtro, poderíamos escrever código menos trivial.
Pessoalmente, prefiro o modo vue 1.0, que torna a codificação mais agradável.

Quanto às preocupações do clichê - existem várias maneiras de lidar com isso.

1. Importar/exportar explicitamente

Como @raywill demonstrado acima. É um pouco mais detalhado, mas os benefícios são que:

1. Você não precisa pesquisar a documentação do filtro do Vue para entender como ele funciona. É super explícito de onde as funções estão vindo e como elas são implementadas.
2. As funções em si são apenas JavaScript. Você pode alterá-los/compô-los para se adequar a casos de usos especiais, ao contrário dos filtros embutidos que você não pode tocar.
3. Você pode importar e reutilizar programaticamente essas funções em métodos, propriedades computadas e em qualquer lugar onde escrever JavaScript.

2. Anexe-os a Vue.prototype

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

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

3. Torne-se funcional (para usuários avançados)

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

Onde as funções auxiliares se parecem:

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

Novamente, uma consideração de design muito importante é que os filtros integrados podem ser úteis, mas eles não têm a flexibilidade do JavaScript puro . Quando uma função interna não atende às suas necessidades, você acaba reimplementando algo semelhante (e enviando ambos em seu código final, onde o interno se torna inútil, código morto), ou precisa esperar que o Vue atualizá-los e lançar uma nova versão.

@yyx990803 Eu gosto da abordagem do protótipo, mas e os casos em que você precisa de vários filtros?

É muito comum usar orderBy junto com filterBy

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

Que tal casos em que você adicionaria um limitBy também?

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

Essa abordagem torna o código menos legível?

Sim, pelo menos na minha opinião.

Acho que poderíamos ter combinado filtros como filterAndOrderBy mas isso também não parece certo.

Estou aberto a mudanças, só quero criar uma maneira quase tão fácil de lidar com isso!

Além disso, o benefício de poder usar os filtros em qualquer lugar também é um ponto muito bom.

Apenas para observar, os @vuejs/collaborators estão discutindo uma opção para fornecer um pacote de utilitários dos filtros integrados atuais. Existem muitos recursos por aí que fornecerão ferramentas de utilidade para sua base de código.

Uma coisa boa sobre a remoção dos filtros principais é que agora você pode personalizá-los/implementá-los você mesmo. O que lhe dá muito mais flexibilidade.

As expressões de modelo @rigor789 devem ser o mais simples possível. Idealmente como <div v-for="filteredData"> </div> . Isso pode ser um prop computado, que pode conter a lógica para criar os dados filtrados. Isso é muito mais legível e é melhor do que algo como:

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

É muito mais reutilizável atribuir como uma propriedade computada e pode até ser passado para componentes filhos. E se você quisesse usar os dados filtrados em dois lugares? É mais fácil, mais simples, confiável e mais legível para os modelos terem expressões simples, em comparação com filtros encadeados em expressões.

Para quem está acompanhando, respondi @chrisvfritz aqui: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

O seguinte resolve meu caso de uso de _muito_ poucas funções auxiliares de visualização pura disponíveis globalmente. Retiro minhas preocupações com a remoção do filtro. Queime-os! 🔥 Parabéns a @chrisvfritz e @yyx990803 por mudar a mente de alguém (a minha) na Internet!

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

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

Eu concordo totalmente com @yyx990803 , remova os filtros e mantenha as funções JS simples.

@blake-newman Esse é um ponto muito bom, estou convencido neste momento e, pensando em legibilidade, acho que algo assim pode ser alcançado

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

Aqui está um rápido jsfiddle do conceito

Uma coisa boa sobre a remoção dos filtros principais é que agora você pode personalizá-los/implementá-los você mesmo. O que lhe dá muito mais flexibilidade.

Você sempre foi capaz de personalizá-los/implementá-los você mesmo.

Vue não é uma biblioteca de utilitários. E, francamente, nenhum dos utilitários que oferecemos foi o melhor da categoria.

O que nos preocupa é remover a funcionalidade de filtro nos modelos. A remoção dos filtros integrados faz muito sentido – eles podem ser facilmente recriados usando-os como proxy para sublinhar/outras bibliotecas úteis. Então, alguém pode até lançar um único plugin que recrie todos os filtros internos atuais.

O uso de propriedades computadas no lugar de filtros também oferece a vantagem de que o valor processado pode ser facilmente reutilizado de maneira DRY em qualquer lugar do componente.

Claro que você pode usar propriedades computadas se precisar reutilizá-las em outro lugar. Mas se você não fizer isso, um filtro ainda é muito mais conveniente.

Há alguns outros pontos que postei nesse link que compartilhei acima.

Por que não suportar uma sintaxe para filtros que funciona como a sintaxe proposta do ES7? Isso permitiria que as pessoas continuassem usando seus filtros amados e os alinhassem com o que o futuro pode reservar. Eventualmente, quando tivermos pipes ES7, você poderá alternar a implementação interna sem alterar a API.

Os tubos ES7 são aprovados ou estão sujeitos a muitas alterações?

Está teoricamente sujeito a mudanças, mas parece... estável?
Status: mindeavor/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Acho que estamos na mesma página em relação ao valor dos tubos em geral. 😃 Uma vantagem do novo compilador em 2.0 é que podemos canalizar o código da função de renderização gerado através do Babel. Isso ainda precisa ser mais explorado, mas não é inconcebível que uma vez que |> ganhe mais impulso e um plugin Babel para ele seja desenvolvido, você possa encadear métodos com pipes novamente - _everywhere_ em seu aplicativo. Como um grande fã do LiveScript e de outras linguagens funcionais, eu definitivamente reconheço o valor !

este operador de pipeline não está nem no estágio 0

@thelinuxlich Sim, acredito que eles ainda estão esperando por um campeão no TC39. 😞

@rigor789 essa é uma das alternativas que eu queria mencionar também! O poder do JavaScript permite que você alcance a expressividade de sua escolha, e é melhor do que colocar a lógica de filtragem dentro de templates.

@yyx990803 Como o Vue funciona nos seguintes casos, quando o nome de um usuário é atualizado?

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

Parece que o primeiro renderizaria apenas um objeto, enquanto o último recalcularia a lista inteira?

@rpkilby que não parece ser o equivalente. Seria mais como:

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

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

Ainda não gosto da ideia de usar métodos como filtros (como um pressentimento, parece errado, mas não consigo explicar). De qualquer forma, você discutiu outros métodos de disponibilizar filtros, então +1.

Nada sugerido neste tópico chega nem perto da expressividade e concisão dos filtros. Simplesmente não.

E isso me deixa muito triste. Como eu disse no tópico do fórum: para mim, isso remove uma grande parte do que torna o Vue Vue.

Se você me procura, pode me encontrar no canto soluçando audivelmente 😟

De jeito nenhum, essa mudança incentiva uma boa codificação Javascript, lide com isso :)

Então, acabei de ter uma longa discussão com @yyx990803 , onde eu – da perspectiva de um usuário – sugeri manter o suporte _syntax_, porque parece elegante e natural. Minha imaginação era algo assim:

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

Fiquei com a impressão de que isso se aproximaria do melhor dos dois mundos.

No final, porém, estou convencido de que remover os filtros como um todo é realmente uma coisa melhor: como o @thelinuxlich acabou de dizer, incentiva um melhor JavaScript e pensamento lógico. Não introduzimos lógica no Blade do Laravel ou na camada de visualização de qualquer outro framework, e não devemos nos templates do Vue.

Dito isso, @JosephSilber , se você olhar para o outro canto, você me encontrará lá.

Para mim, os filtros são muito bonitos, a sintaxe é exatamente como uma sintaxe de filtro deve ser.

Também uma coisa atraente sobre o Vue para mim é que ele vem com (algumas) baterias incluídas. Seria muito triste perder qualquer uma dessas coisas - ambas que, na minha opinião, fazem o Vue se destacar.

Lendo o tópico, parece que a maior preocupação com os filtros era o fato de o Vue ter filtros padrão, e não a função em si (ou é? Ainda não tenho certeza).

Eu gosto do pensamento do plug-in de filtro de @blake-newman e deve haver exemplos pré-construídos. Se outras pessoas criarem outros filtros, eles devem ser plug and play. Isso seria bom. Concordo absolutamente que a criação de filtros é uma responsabilidade do usuário.

O que ainda é desejado são as habilidades de pipe e encadeamento e a globalidade do recurso de filtro original. As preocupações com a globalidade foram cobertas por @yyx990803. Como sobre o encadeamento com o tubo? Isso ajuda muito na leitura dos modelos e na compreensão do que deve ser esperado como saída. O tubo e o encadeamento foram discutidos acima. Ainda pode ser feito? Por que é uma coisa ruim? Para o designer, é ouro! O filtro é uma ferramenta do designer, não do programador JS. Assim, o argumento de escrever melhor JS cai fora do quadro, no meu livro, mas posso entender por que seria desejado. Mas, como designer, quero escrever código melhor também, e os filtros me permitem, lindamente. :sorriso:

Scott

Aqui está o que diz respeito ao encadeamento - os filtros são usados ​​principalmente para dois propósitos:

1. formatação de texto;
2. processamento de uma matriz.

No caso de formatação de texto, 90% ou mais das vezes é usado apenas um único método utilitário. O encadeamento não é realmente um problema neste caso.

Quanto aos arrays: já mencionei que o processamento de array é de fato lógico e é mais adequado em JavaScript. Ter vários filtros de matriz encadeada pode parecer bom quando é simples, mas pode ficar feio quando você usa mais de 1 argumento para cada um. Também está encorajando você a colocar muita lógica em seu modelo quando você realmente não deveria. Eles também são inflexíveis (não podem recuperar facilmente o valor processado). Em comparação, com o ES2015 o exemplo original

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

pode ser escrito como:

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

É apenas JavaScript, não tem mágica, sintaxe alternativa e API específica de filtro para aprender. E você pode acessar o valor processado (que é armazenado em cache de forma inteligente). Você também pode adicionar açúcar em cima disso, conforme mostrado nos comentários anteriores. Além disso, seu modelo parece mais limpo:

<div v-for="filteredThings">

Eu sei que isso é como uma coisa útil sendo retirada, mas honestamente, os argumentos para filtros agora me parecem apenas tentar manter a sintaxe por causa da sintaxe. Na minha opinião, é preciso mais do que apenas "porque é elegante" para justificar um recurso - ele precisa fornecer valor objetivo. Este foi o caso de inline-templates , mas não vejo isso para filtros.

@yyx990803 - Seu exemplo exemplifica o problema, eu acho. Novamente, não sou o melhor programador de JS, mas não preciso ser um programador de JS para saber que filteredThings não diz nada sobre o que realmente faz. Para mim, isso é uma má prática. :smile: O fato de o método de filtragem ser global também significa que devo procurar em docs, o código ou decifrar a saída para descobrir o que o método faz. Não muito elegante. Direito?

Então ok. poderíamos ter um nome de método como `filterByOrderByAndLimit'. E os argumentos?

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

Isso seria correto?

Se for, isso pode ser viável. Ainda assim, não parece bom.

E, agora eu quero apenas filterBy e OrderBy. Preciso de um método separado para fazer isso também? E então eu quero adicionar formatação de moeda. Outro método? O encadeamento de filtros nos templates torna a manipulação da apresentação flexível e muito expressiva. Essa preocupação ainda não foi devidamente abordada com métodos (e minha falta de conhecimento não está me permitindo entender que métodos podem ser melhores).

Isso pode ser possível?

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

Concordo que fazer muita lógica em um modelo é algo a ser evitado. Mas, o encadeamento de filtros e a capacidade de simplesmente inserir um filtro em qualquer lugar nos componentes/modelos de um aplicativo é um conceito fantástico e havia uma razão pela qual você o adicionou para começar. Qual foi esse motivo ou motivos? Se você puder nomeá-los, então aposto dinheiro que superam "mas promove práticas ruins" por uma milha.

Qualquer coisa que permita flexibilidade pode ser usada de forma inadequada, assim como o próprio Vue. O principal argumento para inline-template era que era flexível e permitia que o Vue fosse usado de diferentes maneiras. Filters não é muito diferente, exceto que é interno do Vue e não afeta como o Vue pode ser usado externamente. Ainda assim, isso não desvaloriza sua importância. Lembre-se, muitas pessoas também disseram que isso seria impossível para eles atualizarem. É tão importante! :sorriso:

A nova maneira só precisa dos mesmos atributos que a antiga.

• encadeável
• global
• adicionar aos modelos para expressar bem como os dados nos modelos serão manipulados

(esqueci alguma coisa?)

Se puder fazer tudo isso, tenho certeza de que todos ficarão bastante satisfeitos. Eu pessoalmente não consigo ver isso acontecendo com métodos (ainda).

Scott

@smolinari

1. Afirmei claramente que você deve colocar menos lógica em seus modelos. Esta é a minha opinião, quer você goste ou não. Obviamente, você é livre para discordar, mas não posso ajudá-lo se você quiser trabalhar contra as melhores práticas recomendadas.
2. Dado (1) - expliquei por que o encadeamento não é um problema porque a lógica complexa deve ser feita em JavaScript.
3. Também dei exemplos de como você pode adicionar métodos disponíveis globalmente.
4. Veja o exemplo de @rigor789 em uma sintaxe de encadeamento personalizada semelhante ao que você deseja.
5. O objetivo da estrutura é fornecer o que _eu_ acredito ser a melhor maneira de desenvolver aplicativos front-end, não para agradar a todos. Portanto, não use "Não atualizarei se você não me devolver esse recurso" - não funciona.

Por que vocês não experimentam esta nova versão alfa por uma semana e depois vêm com alguns comentários realmente valiosos (com base em sua prática)? Talvez tente refatorar seu aplicativo existente e nos informe o que era impossível, o que foi melhorado, o que piorou, para que possamos discutir melhor. Isso seria útil para todos, eu acho.

@yyx990803 - Eu concordei com 1. Então nós concordamos. :smile: Eu só não concordo que seja uma razão adequada para tirar algo que ganhou tanto amor.

Então, acho que você decidiu com o tempo que JS pragmático é melhor que HTML pragmático?

O argumento de não ir para não atualizar é o que outros disseram. Estou apenas tentando comunicar e mitigar isso.

Um último argumento meu. Olhe para isso dos olhos do usuário do usuário. Digamos que eu tenha um sistema como o Laravel ou algum outro sistema MVC ou MVVM que incorpore o Vue, que também permite que o usuário desse sistema construa seus próprios componentes. O filtro, como era, simplifica a curva de aprendizado e permite que os usuários desse sistema façam muito, sem tocar em nenhum JS. Eu sou um fã do Vue, porque ele permitiu que programadores não JS ainda fizessem muito. Esta é a mesma razão pela qual eu não gosto de React e JSX. Essa combinação terá uma base de usuários muito menor em relação ao Vue com o passar do tempo. Aposto dinheiro nisso.

Eu também entendo que a verdadeira flexibilidade está no JS. Ainda assim, por favor, não confie apenas no JS para a flexibilidade do Vue. Tenha isso em mente, nem todo mundo é um programador JS matador. Na verdade, a maioria das pessoas não são. O filtro foi uma boa maneira de fazer muito para essas pessoas e foi um bom trampolim para mais manipulação de JS. Os filtros não conseguem fazer isso? Aprofunde-se nos métodos JS.

OK. Chega de mim ..... Estou feito. E, obrigado por ouvir de qualquer forma. Vue ainda é incrível! :sorriso:

@azamat-sharapov - bom ponto.

Scott

Ver pessoas tentando justificar más práticas dentro do JS me deixa triste. Realmente, você não precisa ser um profissional, apenas faça o dever de casa básico (ou não é mais básico hoje em dia?)

O problema que tenho com os métodos filter-inside é de semântica.

Em termos oops, os filtros são como funções estáticas, enquanto os métodos são funções não estáticas.

Os filtros transmitem uma semântica extremamente diferente dos métodos. a maior diferença é que os filtros não podem usar this , mas os métodos podem.

@yyx990803 enquanto estiver usando Vue.prototype.filters pode funcionar, mas alterar Vue não parece uma boa prática para mim. Eu prefiro defender a criação de um objeto separado (global) que conterá todos os filtros.

Não parece uma boa prática porque globals não é uma boa prática. A abordagem recomendada é importar explicitamente métodos auxiliares. Anexar ao protótipo é uma solução alternativa para aqueles que não desejam importar métodos explicitamente.

Quanto à semântica - os filtros são um conceito cunhado de qualquer maneira. Em JavaScript você não inventaria uma semântica diferente apenas para colocar uma string em maiúscula - você chama uma função. E é isso que elas são, funções JavaScript.

Vou fazer mais um comentário para tentar deixar meu ponto pessoal mais claro, principalmente por causa do comentário "tentando justificar más práticas dentro do JS". Eu certamente não estou tentando fazer isso.

Percebo que o Vue é mais do que apenas um sistema de templates, mas também é um sistema de templates e temo que esteja tentando se afastar desse papel, o que acho que não deveria. Portanto, como um mecanismo/sistema de modelagem, considere o mecanismo de modelagem Twig como um exemplo muito bem-sucedido do que se poderia esperar de um sistema de modelagem. Eles têm uma seção " Para os designers de modelo " e uma seção " Para os desenvolvedores " em seus documentos. Como um sistema de templates, o Twig também é poderoso para o designer de templates, porque está repleto de comportamentos padrão, incluindo filtros . Ele permite que não desenvolvedores façam muito com o sistema de templates, sem conhecer diretamente o PHP. Eles só precisam aprender o que o Twig tem a oferecer e como usá-lo. Estou procurando isso no Vue também. Eu gostaria de ver uma seção "Vue para designers de modelos" nos documentos também. :sorriso:

Além disso, muito importante é a extensibilidade do Twig. Se algo não estiver disponível na versão de estoque, ele pode ser adicionado. É quando o desenvolvedor intervém. O bom é que as extensões podem ser compartilhadas, o que significa que isso só precisa ser feito uma vez.

A outra coisa legal sobre esses dois níveis de designer/desenvolvedor é que você obtém uma base muito mais ampla de usuários. Muito, muito mais amplo e isso é o mesmo com o . E quando os padrões de comportamento não são suficientes, é quando eles começam a aprender, voluntariamente, a linguagem subjacente. E é aí que eles aprendem as melhores práticas e o resto.

Se você está dizendo que o Vue não pode ser um mecanismo de modelo sem ter que aprender JS, então eu diria que está diminuindo consideravelmente seu valor de mercado. Se você disser, você deixará a porta aberta para permitir que outros criem essas ferramentas para o mecanismo de modelagem como plug-ins, ótimo. Mas, então, todos estarão lutando pelo que deveria estar no sistema de templates. Isso também é IMHO contraproducente.

No seu aluno falando sobre o exemplo de filtros Evan, foi alguém aprendendo JS ou alguém aprendendo um mecanismo de modelo? Se fosse o último, aposto que a conversa seria diferente.

A qualquer custo. Eu ainda acho que o Vue é um sistema vencedor. Espero que meus pensamentos possam fazer os outros pensarem de forma diferente sobre os papéis de Vue de alguma forma. :sorriso:

Scott

@yyx990803 se os filtros são um conceito cunhado, então por que eles foram cunhados em primeiro lugar?

Eu acredito que é porque dentro de <template> todas as variáveis ​​externas como $data ou abc são convertidas em this.$data e this.abc e, portanto, funções js simples definidas fora do componente não pode ser referenciado. Filtros foram introduzidos para superar essa limitação.

Essa limitação ainda existe --- suponho que estou certo --- remover a limitação exigiria que os desenvolvedores codificassem explicitamente this.abc para referenciar this.abc e acessar funções js como seriam referenciadas em js.

Mas esse será um recurso muito poderoso, propenso a abuso e a migração de código antigo será uma dor. a sintaxe atual parece muito melhor do que isso para mim.

Concordo com você que os filtros são basicamente funções js e devem ser importados para o componente. Eu só não gosto que eles sejam definidos no mesmo lugar que os métodos.

Olá a todos. Li todo o tópico e é isso que penso.

• Ninguém sentiria falta dos filtros embutidos como orderBy filterBy e qualquer outro
• O que todo mundo ainda quer ter por perto é o operador de tubo em modelos
• A equipe principal diz que a lógica deve ficar em javascript, não em templates, além de que vem um recurso es7 com o operador pipe.

Tendo isso como um resumo rápido o que eu acho que poderia ser uma boa solução até que js implemente um operador de pipe nativo , seria ter o operador de pipe como um plugin e manter a versão 2.0 como está. Assim, os usuários podem fazer

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

Enquanto aguardamos a implementação do novo recurso, ele pode ser incluído com algum aviso sobre a suspensão de uso ou algo assim. Eu sei que qualquer um poderia implementar esse plugin, mas acho que seria melhor se ele fosse fornecido e mantido pela equipe Vue, isso seria possível?

Posso estar errado, mas não acho que o Vue permita que plugins mexam com seu compilador.

@azamat-sharapov Claro que não. Eu só não achei que iria mexer com o compilador Vue :open_mouth:

@YerkoPalma Eu absolutamente _amo_ o operador de tubos. Eu o uso obsessivamente em linguagens funcionais e mal posso esperar para tê-lo em JavaScript! _Mas_, imagine que o Vue nunca teve filtros. Você estaria solicitando que um framework frontend estendesse a sintaxe do JavaScript? Esse é o domínio do Babel ou de uma linguagem de compilação para JS, não de uma estrutura de interface do usuário. Se você preferir usar uma linguagem como o LiveScript, como costumo fazer, você pode. Mas o problema aqui não é com o Vue. É com o próprio JavaScript e não estamos aqui para consertar isso.

Além disso, se pudermos canalizar os resultados da renderização em 2.0 através do Babel, como esperamos, você poderá usar o plug-in rastreado não-TC39, se quiser - de forma consistente, em todo o seu JavaScript, em vez de apenas no molde. Então, se você quer apenas um cachimbo, é provável que você consiga tê-lo. E você _pode_ tê-lo hoje em 1.x - apenas esteja avisado que o pipe que você usaria em seus templates provavelmente terá uma precedência e comportamento diferente daquele em seu Babel.

@smolinari e outros. Há duas frases (e variações delas) que continuo ouvindo:

• "Pense nos desenvolvedores / na perspectiva do usuário"
• "Pense em iniciantes"

Ambos implicam uma suposição - que não estamos pensando nesses grupos.

Já mencionei isso antes, mas acho que precisa ser reiterado. _Todos_ na equipe principal são designers, desenvolvedores front-end ou uma combinação de ambos . Usamos essas ferramentas todos os dias para nosso próprio trabalho. Nós estaremos usando o Vue 2.0 também. Acredite, nós _estamos_ pensando nisso. 😉

Quanto aos iniciantes, fiz um caso aqui , mas acho que vou entrar em mais detalhes. Eu sou um educador. E eu era um defensor da eliminação de filtros, _pensando em iniciantes_. Eu ensinei pessoalmente centenas de pessoas - talvez até mais de mil - como praticar desenvolvimento web, geralmente do zero. Sem experiência anterior em codificação. Eu fiz isso com alunos do ensino médio, alunos do ensino médio, estudantes universitários, adultos profissionais e idosos.

A partir dessa perspectiva, posso dizer que, embora os filtros possam parecer uma mágica empolgante no início, eles acabam retardando o aprendizado de um aluno, introduzindo mais complexidade para conveniência limitada. Se eles nunca tivessem estado em Angular ou Vue e essa conversa fosse invertida - estávamos tentando _introduzi-los em 2.0 - teríamos dificuldade em explicar por que eles eram necessários e quando você deveria usá-los.

Antes que houvesse qualquer conversa sobre a descontinuação do 2.0, eu eliminei os filtros do currículo em nossa escola de código, porque reunimos evidências suficientes de que eles estavam fazendo mais mal do que bem para iniciantes. Preferimos que eles ganhem experiência com recursos Vue mais versáteis, como métodos e propriedades computadas. Até desencorajamos o uso de filtros, porque eles facilitam a detecção de más práticas.

Espero que isso acabe com essas duas queixas. Veremos. 😃

Mas, imagine que o Vue nunca teve filtros. Você estaria solicitando que um framework frontend estendesse a sintaxe do JavaScript?

Claro que sim, pois os filtros são muito naturais para _templates_ como no Twig, mencionado anteriormente. Eu sinto que ter um operador de pipe é tão natural quanto ter a sintaxe bigode em templates, quer dizer, bigodes não são html, e não javascript vocês vão removê-los também? qual é a diferença com o operador de tubulação?

O argumento "pense nas crianças" é simplesmente estúpido. Até onde eu sei, o Vue não foi projetado para ensinar JavaScript, mas para desenvolvedores front-end fazerem merda. Para os últimos filtros são ótimos.

Se eles nunca tivessem estado em Angular ou Vue e essa conversa fosse invertida - estávamos tentando apresentá-los em 2.0 - teríamos dificuldade em explicar por que eles eram necessários e quando você deveria usá-los.

Eu discordo muito. Eu tenho usado uma estrutura Python chamada Django desde 2005 e sua linguagem de modelagem - que tem sido a inspiração para a maioria das linguagens de modelagem que surgiram mais tarde - teve filtros desde o primeiro dia. Depois de usá-los com desenvolvedores front-end por mais de dez anos, passei a apreciar sua beleza e utilidade. Seria triste ver essa sintaxe desaparecer.

(Aqui está o que o Django faz com filtros: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen , por favor, preste atenção ao seu tom - chamar os argumentos dos outros de burros não é uma maneira construtiva de participar de uma discussão.

Para aqueles que fazem analogias com linguagens de template do lado do servidor - um aspecto importante a ser observado é que as linguagens de template do lado do servidor não têm a mesma flexibilidade que os templates Vue têm (sem propriedades computadas, expressões limitadas). Além disso - eles são construídos para propósitos completamente diferentes: saída de strings estáticas. Os templates Vue são representações do DOM interativo - existem ligações bidirecionais, manipuladores de eventos, props de componentes e muito mais. Filtros só se encaixam em um caso de uso muito limitado no contexto Vue: hoje eu acredito que é uma má idéia permitir filtros em todos os lugares, por exemplo, filtros em v-model, v-for e v-on introduzem mais complexidade do que bem.

Uma alternativa possível é manter filtros, mas apenas para interpolações de texto - ou seja, você só pode usá-lo dentro de {{ }} s, não em diretivas.

Como uma referência interessante: o Angular 2 ainda possui filtros (renomeados como "pipes"), mas também removeram intencionalmente os filtros de lista.

Desculpe pela minha linguagem, não quero insultar ninguém.

Para mim, o propósito de um framework _é_ fazer as coisas difíceis e fazer com que pareça fácil para os desenvolvedores que usam essas ferramentas. Eu ainda argumento que a sintaxe simplesmente não pode ser superada e, novamente, seria triste vê-la desaparecer.

Eu não conheço ou entendo muito dos mecanismos sob o capô, mas do ponto de vista dos usuários, a praticidade supera a pureza :)

Em uma nota relacionada, foi interessante ver quanta paixão parece haver nesta comunidade. Para mim o Vue tem sido uma ferramenta nova e revigorante, talvez por isso eu mesmo tenha participado da pintura deste galpão em particular :)

Para outro ponto de dados, o Ember não possui filtros nem permite métodos de componentes, embora tenha propriedades computadas.

Para o caso de uso de funções puras que executam transformações no modelo, você precisa registrar um auxiliar de guidão/auxiliar de ember.
http://emberjs.com/api/classes/Ember.Helper.html

Os ajudantes de guidão são sintaticamente distintos de coisas que não são ajudantes de guidão e é por isso que trago isso. Eles têm isso em comum com a sintaxe do filtro de tubulação. No entanto, os modelos de guiador são "sem lógica", o que significa que eles exigem uma sintaxe especial para uma chamada de função no modelo. Um problema que o Vue não tem.

Filtros é simples para iniciantes, há alguma mágica usando para saída bonita ou filtro\ordersearch em arrays

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

e facilidade defini-lo

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

é simples, claro nos templates, para 2.x você define filtros no módulo externo e nos templates obtém

import moment from 'moment'

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

e no modelo

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

Como sugestão, por que não deixar os filtros antigos no modelo, mas mover os filtros em um módulo separado e usá-lo na seção de métodos?

Então, se você precisar, é só fazer

npm install vue-utils

e use filtros específicos do pacote utils

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

methods:{
   moment, price
}

e use como filtro comum

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

no resultado, ele pode ser traduzido para uma simples chamada de função

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

_Observação_
Para mim, os filtros mais usados ​​para formatar dados, como datas, números ou strings . Para filtrar arrays\objects, acho melhor usar computado e função do módulo vue comum:

import _ from 'vue-utils/array'

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

Benefícios:
Iniciantes podem facilmente usar filtros antigos, mas na computação e usar funções bonitas em seus modelos para formatar a saída de dados e os programadores podem escrever módulos de funções próprias para isso e facilidade de uso.

_Por que módulo separado?_
Eu acho que não é necessário estar no núcleo do Vue, mas o Vue deve ter alguns utils para desenvolvedores de designers de templates, então não é necessário o tempo todo exigir lodash, moment ou então, basta instalar utils do npm e facilidade de usá-lo, mas salve a sintaxe de chamada antiga para modelos.
Mas um pensamento importante deve ser feito para filtros, deve haver funções puras, como getters em vuex.

É fácil de suportar, fácil de usar, usar, estender e dar uma boa olhada nos modelos.

O que vocês precisam é de um caminho de atualização claro e o desejo de aprender a modularizar seu código Javascript.

@thelinuxlich Falamos sobre filtros.

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

apenas açúcar de sintaxe para

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

Mas excluir completamente os filtros para iniciantes em Vue\javascript é ruim. Por que a comunidade Laravel gosta do Vue? Porque é simples e poderoso.

Se removermos completamente os filtros, precisamos dar alternativa para _"Para os designers de modelos"_, não há necessidade de saber como classificar o array ou filtrá-lo, basta inserir o exemplo do formulário de código e obter o resultado.

Os programadores devem saber como _modularizar_ código Javascript, mas quem o usa para pequenas coisas não precisa saber.

Se falamos de _"Para os designers de templates"_ pode-se simplesmente colocar

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

e dentro do uso do código

Vue.use(VueUtils)

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

por exemplo e orgulhosos, não há necessidade de saber js para filtrar e classificar arrays, muitas pessoas querem fazer algumas coisas, mas é difícil entender código como

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

então não há necessidade de fazer coisas complicadas para esse tipo de pessoa, se pudermos dar uma solução simples para isso e for bom para os desenvolvedores.

Uma alternativa possível é manter filtros, mas apenas para interpolações de texto - ou seja, você só pode usá-lo dentro de {{ }}s, não em diretivas.

Acho que isso poderia ser um compromisso muito bom. Embora não satisfaça a todos, é tudo o que eu usei filtros e, na verdade, acho estranho que eles atualmente possam fazer mais do que isso.

Isso permitiria uma formatação de texto conveniente se você desejasse usar filtros e reduzir a complexidade removendo efetivamente os filtros bidirecionais.

Na minha opinião, seu exemplo de filtro momentjs já está passando muita lógica para os templates.

Sério, você deve direcionar todo esse "pipe love" para o repositório de especificações até chegar ao TC39 :)

Eu gosto do que @yyx990803 e @VitaliyLavrenko sugeriram. Isso pode ser um bom meio termo.

Scott

Gosto da proposta do @VitaliyLavrenko , mas quando falo algo parecido, sobre ter o operador de pipe em um plugin @azamat-sharapov disse que plugins não devem mexer no compilador... apenas interpretou mal o comentário?

@thelinuxlich

O que é melhor para você ler?

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

Pense como desenvolvedor e pergunte a alguém que não conhece javascript.

Quanto a mim, para _não desenvolvedores_ melhor algo assim:

Vue.use(VueUtils)

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

É meio e usado como vue-resource apenas lib comum.

Sobre pipe, eu é açúcar de sintaxe

coisa nas coisas | filtrarPor 'foo' | ordemPor 'barra' | limite por 5

por

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

Que facilidade de leitura?

Se você precisa passar dados para 2 templates diff, você armazena 2 ou 3 modificações para um dado?

Se for algum tipo:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

É uma situação abstrata, mas se usar em um ou dois templates? Você precisa armazenar dados para 10 ou 100 objetos? Aumentar o uso de memória? Sim, podemos usar o método auxiliar e usá-lo no modelo, mas para _"Para os designers de modelo"_ que estão longe do javascript, melhor algo como title | padLeft 10 e deve ser traduzido para chamada de função, é fácil e funcional.

Pense nas pessoas do diff, os desenvolvedores podem fazer isso de maneira fácil, mas outras pessoas querem fazê-lo de forma simples.

Eu vou dizer de novo, muita lógica em templates é um anti-padrão. Em vez de ter que aprender um DSL específico (filtros), você deve aprender Javascript.

@thelinuxlich Basta usar o JSX e obteremos o React com ligação de 2 vias e algumas outras coisas.

Mas com o Vue temos, pessoas que não conhecem javascript, mas com google podem fazer alguma coisa e se você não gosta de pipe, não use. Podemos apenas adicionar algo como

Vue.config.pipeFuncCall = true

E você pode ativar/desativar, mas para algumas pessoas é fácil.

_Vou dizer novamente, não apenas os desenvolvedores de JS podem usar o Vue, é o lado mais forte do Vue._

Filtros comuns padrão precisam, mas é melhor que haja uma biblioteca separada e facilidade para adicioná-lo ao vue e usar.

Ou você quer que o Vue seja algo como ASM e apenas bons desenvolvedores possam usá-lo?

Pessoal, acho que a decisão da equipe principal do Vue foi muito bem explicada. Não podemos repetir a mesma coisa várias vezes e comentar apenas com algo novo, valioso, se houver?

Se for parte dos princípios básicos do Vue ser mais fácil para desenvolvedores não JS, mesmo que isso prejudique os princípios da linguagem, então eu concordo com você, mas provavelmente não é o caso.

Como eu disse antes, estou bem com filtros sendo obsoletos, certamente sentirei falta deles por causa de sua conveniência, mas tenho mais do que certeza de que um sistema de filtros muito semelhante pode ser introduzido como um plug-in.

Eu dei um exemplo de prova de conceito um pouco antes, que pode ser usado em props computados, bem como em inline

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

Por outro lado, se alguém quiser o cachimbo, tenho certeza que pode ser feito, com algo assim

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

Ou talvez, se houvesse um gancho que permitisse aos plugins analisar expressões e processá-las como quiserem, isso também poderia ser uma maneira possível, mas isso depende apenas de quão complexo é implementar e quais efeitos isso teria no framework (desempenho/tamanho), e se @yyx990803 realmente quer ir nessa direção ou não!

Eu sinto que, se nos derem alternativas elegantes, fáceis de usar (Plugins ou algo no núcleo), vamos nos acostumar rapidamente.

@rigor789 para filtrar matrizes e classificá-las, etc, melhor usar computado, é muito limpo. Mas acho que há problema em exibir dados no formato diff:

se tivermos o campo created_at e precisarmos no template renderizá-lo como dd.mm.YYYY ou em links

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

para esses filtros usados ​​bem agora, que alternativa podemos obter do 2.x?

Por enquanto só use

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

e definir o método de data, mas é tornar o modelo sujo, se armazenar 3 campos adicionais, custará memória e, se tiver 100-200 objetos, ficará pesado.

Eis a decisão final:

1. Filtros serão suportados, mas apenas dentro de interpolações de texto. Isso os limita a fins de formatação de texto enquanto impõe outra lógica na terra do JavaScript.
2. O Vue 2.0 será fornecido sem filtros integrados. A comunidade pode criar seus próprios pacotes de filtros, se necessário.
3. A sintaxe do filtro será alterada para usar a sintaxe de invocação de função para argumentos em vez de delimitada por espaço. Isso o deixa mais alinhado com JavaScript e outras linguagens de modelagem populares (Jinja2, swig, twig...):

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

Obrigado por ouvir Evan. É isso que torna o Vue ótimo. Tem um grande líder. :sorriso:

Scott

@yyx990803 & @chrisvfritz

Uma coisa que parece ter sido enterrada nessa discussão são os filtros bidirecionais. Os filtros bidirecionais são os mais difíceis de replicar com outras soluções propostas.

1. Considere este exemplo simples , que postei nesse tópico do fórum. Usar propriedades computadas para isso teria 2 desvantagens principais:
   
   
   
   1. Você terá que criar uma nova propriedade computada para cada valor, resultando em uma tonelada de código clichê.
   
   
   2. Para piorar as coisas, as propriedades computadas não podem ser aninhadas . Se você tiver um gráfico de objeto mais complexo, todas as suas propriedades computadas terão que estar no nível superior. Você acabaria com nomes de propriedades longos e detalhados exigindo mais sobrecarga cognitiva para acompanhar constantemente quais propriedades computadas rastreiam quais valores aninhados.
   
   

Descartar este caso de uso como "trivial" ou "menos complicado" é contraproducente. Eu usei isso em aplicativos de média e grande escala. Tem funcionado maravilhas! A demonstração é necessariamente simples, mas a técnica é sólida.

1. Isso é ainda mais confuso ao lidar com uma matriz em v-for , como neste exemplo (novamente, intencionalmente simples). Iterando sobre uma matriz, você não encontrará recursos nas propriedades computadas. A única maneira de contornar isso é ter um componente separado para cada item na matriz, adicionando ainda mais clichê.

Compare este exemplo com filtros:

``` js
importar moeda de 'algum filtro de moeda';
importar produtos de 'produtos-stub';

novo Vue({
el: document.body,
dados: { produtos },
filtros: { moeda },
});
```

Para um sem filtros:

``` js
importar moeda de 'algum filtro de moeda';
importar produtos de 'produtos-stub';

novo Vue({
el: document.body,
dados: { produtos },
componentes: {
produtos: {
adereços: ['produto'],
calculado: {
preço: {
pegue() {
return moeda.read(this.product.price);
},
set(valor) {
this.product.price = moeda.write(valor)
}
},
envio: {
pegue() {
return currency.read(this.product.shipping);
},
set(valor) {
this.product.shipping = moeda.write(valor)
}
},
manipulação: {
pegue() {
return currency.read(this.product.handling);
},
set(valor) {
this.product.handling = moeda.write(valor)
}
},
desconto: {
pegue() {
return moeda.read(este.produto.desconto);
},
set(valor) {
this.product.discount = moeda.write(valor)
}
}
}
}
}
});
```

Eu sei qual dos itens acima eu gostaria de escrever.

_{(isso talvez possa ser um pouco limpo criando fábricas de propriedades computadas, mas o ponto é que elas são muito mais detalhadas do que o necessário)}

Como a equipe principal parece se opor firmemente à sintaxe do pipe do filtro, seria possível introduzir um parâmetro filter para a diretiva v-model ?

Com um parâmetro filter poderemos manter a primeira versão elegante do JS acima, e simplesmente reescrever o template para usar o parâmetro ao invés da sintaxe magic pipe:

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

Isso atingiria o equilíbrio certo de não ter sintaxe mágica, mantendo a capacidade de converter facilmente a entrada para frente e para trás sem muito clichê.

Obrigado por sua consideração.

Eu reescrevi seu exemplo para incorporar seu filtro como uma diretiva personalizada: jsfiddle .
Embora não seja tão conciso quanto um filtro, não é tão doloroso quanto eu imaginava. E não me levou muito tempo para juntar as peças de coisas que já estão disponíveis para todos nós.

@Nirazul criar diretivas dedicadas para cada filtro foi proposto antes . A necessidade de criar uma nova diretiva que reimplemente toda a funcionalidade v-model para cada tipo de filtro que você usa em seu aplicativo é simplesmente absurda.

Além disso, sua diretiva nem funciona totalmente como filtros; desfocar o campo depois de alterar o valor não o reformata. Além disso, v-model faz muito mais do que você nessa diretiva.

A diretiva obviamente pode ser alterada com mais recursos e correções, mas o ponto permanece: todos esses são band-aids em cima de algo que deve ser realmente simples e pronto para uso.

Eu não vi nenhuma proposta neste tópico mencionando diretivas personalizadas. Você poderia me indicar este comentário?

Como você pode imaginar, eu não escrevi e testei para você usar em seu aplicativo. Eu só queria mostrar o que é possível agora como alternativa. Se isso for possível com tanta facilidade, talvez haja espaço para um plugin automatizar ainda mais o processo.
É óbvio que esta diretiva escrita rapidamente não possui a funcionalidade completa do v-model. Talvez uma diretiva de filtro personalizada combinada com parâmetros e/ou modificadores seja suficiente para substituir os filtros.

Vamos permanecer construtivos, como eu tentei ser para resolver seu problema. É sempre mais fácil se basear em uma solução em vez de fazer uma contribuição e seguir em frente.

@JosephSilber você precisa relaxar. "absurdo" é uma palavra forte.

Oi, A remoção do filtro é motivada pela redução da confusão de modelos ou está afetando seriamente
a implementação técnica de 2.0? Se for um problema de efeito visual anterior, que tal permitir
filtro como agora (mas com o novo formulário javascript)
mas limitando-o apenas para um por expressão, como v-for="i of list | orderBy('key')", (não mais que um sinal de barra vertical)
isso poderia tornar o processamento de filtros em 2.0 mais simples e previsível e visualmente menos confuso.
Como haverá análise de filtro para {{}}, faria sentido permitir isso em outras expressões.
isso acomodaria todos os casos de uso/funções existentes (como filtragem bidirecional, item dentro de v-for).
Quaisquer usos existentes de mais de um filtro podem ser facilmente mesclados/atualizados em um pelos proprietários.

@tomsmithgroup O que você sugeriu (e mais do que isso) foi decidido permanecer com suporte no 2.0.

@yyx990803 & @chrisvfritz adorariam ouvir seus pensamentos sobre filtros bidirecionais .

@JosephSilber Então, com a fábrica de propriedades computadas que você mencionou, não há muito clichê:

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

Embora, pessoalmente, eu não criaria uma fábrica para este exemplo, porque cada uma dessas propriedades são, na verdade, preocupações separadas que apenas _aparecem_ iguais agora. Quando você remove filtros, fica muito mais óbvio o quão complexo era aquele componente. Isso é o que você está vendo como clichê.

E esta é uma grande razão pela qual os componentes _existem_. Para dividir a complexidade em preocupações gerenciáveis. Quando olho para um componente, tudo o que ele está fazendo precisa caber facilmente na minha memória de trabalho, caso contrário o desenvolvimento se torna muito mais lento e mais propenso a erros. Esconder a complexidade por trás da sintaxe dos filtros não remove essa complexidade.

Para demonstrar isso, vejamos o que acontece quando o problema atende aos requisitos de mudança do mundo real: Digamos que você decida que o desconto não deve ser maior do que o preço + frete + manuseio. Ou o manuseio não deve exceder a quantidade X. Ou o campo de desconto deve ser uma porcentagem, em vez de uma moeda. Ou se o total exceder um determinado valor, um desconto mínimo deverá ser aplicado automaticamente.

Você pode ficar tentado a tornar o filtro mais complexo com opções extras e lógica condicional. À medida que você atualiza a API e a lógica interna do filtro, agora você precisa pensar em como suas alterações podem afetar qualquer outra coisa que consuma o filtro - possivelmente até mesmo fora do componente atual, se este for um filtro compartilhado. Então agora você está em uma situação em que fazer alterações em seu aplicativo começa a parecer assustador. E tudo isso porque um filtro compartilhado com dois filtros permitiu delegar o estado interno do componente para fora do componente, violando os limites do componente, aumentando o acoplamento e ocultando a complexidade na qual você ainda precisa pensar toda vez que trabalha no componente.

Ao dividir as coisas em vários componentes individualmente menos complexos, com propriedades computadas definidas separadamente ou props vinculadas, você geralmente atualiza uma linha para se ajustar a um requisito em mudança. Sem opções extras ou condicionais. Nenhuma refatoração para satisfazer a complexidade de dimensionamento. Você não precisa pensar em nada fora do componente _ou mesmo fora dessa propriedade única_. Seu aplicativo foi desde o início e ainda continua fácil de pensar e atualizar.

Acho que o que torna os filtros inicialmente sedutores neste caso é que eles são uma cura fácil de alcançar para a duplicação. Mas a duplicação não é clichê quando é incidental (ou seja, o código simplesmente é o mesmo agora, antes que os problemas do mundo real inevitavelmente comecem a aparecer).

E não posso colocar melhor do que Sandi Metz:

a duplicação é muito mais barata do que a abstração errada

@chrisvfritz Os filtros não têm absolutamente nada a ver com os requisitos de negócios. Os filtros apenas formatam os dados. É isso. Eles não o manipulam de forma alguma, forma ou forma. filter="currency" é conceitualmente o mesmo que o parâmetro number . Obviamente, os requisitos de negócios nunca devem ser tratados nos filtros.

Digamos que você decida que o desconto não deve ser maior que o preço + frete + manuseio. Ou o manuseio não deve exceder a quantidade X.

Então você usaria algum módulo de validação adequado, à la vue-validator . O filtro de moeda permanecerá no lugar independentemente, simplesmente exibindo o valor subjacente.

o campo de desconto deve ser uma porcentagem, em vez de uma moeda.

Então, obviamente, seu tipo não é mais moeda. Não é diferente se você trocar type="text" por type="email" quando os requisitos de nome de usuário mudarem. Ou mesmo quando você remove o parâmetro number quando um campo não é mais um número.

se o total exceder um determinado valor, um desconto mínimo deverá ser aplicado automaticamente.

Novamente, o mínimo será aplicado, mas o filtro de moeda permanecerá no lugar. Você ainda deseja exibi-lo como moeda.

À medida que você atualiza a API e a lógica interna do filtro, agora você precisa pensar em como suas alterações podem afetar qualquer outra coisa que consuma o filtro [...] dois filtros permitem delegar o estado do componente interno para fora do componente

Não. Você _nunca_ coloca qualquer lógica ou estado no próprio filtro. O filtro é uma função idempotente estritamente para formatação de valores. Idealmente, nem deveria ser executado no contexto da VM ; ele não deve ter this para extrair dados adicionais.

a duplicação é muito mais barata do que a abstração errada

...quando, como você disse, você está abstraindo código que por acaso é o mesmo agora. Os filtros, por outro lado, são funções idempotentes simples que formatam um valor. Eles não são uma abstração em tudo.

Os filtros tl;dr não são uma abstração e não substituem os requisitos comerciais explícitos. Os filtros nunca têm lógica interna e nunca deveriam. Eles são conceitualmente semelhantes ao atributo v-model type do HTML e ao parâmetro number do v-model.

O filtro bidirecional é certamente uma abstração. O comportamento atual dos filtros bidirecionais em v-model esconde muita mágica - especificamente, permite que o valor DOM da entrada fique temporariamente fora de sincronia com o modelo subjacente e apenas os "sincronize" quando você borrar o campo. BTW @JosephSilber este comportamento foi implementado especificamente devido ao seu pedido, então eu posso entender por que você se sente tão forte sobre isso.

No entanto, o maior problema que vejo com filtros bidirecionais é que a lógica subjacente é uma caixa preta e o usuário não tem como personalizá-la além de fazer solicitações de recursos. Para mim, a melhor opção é fornecer os blocos de construção adequados para implementar esse comportamento por conta própria. E deixe-me mostrar como isso é possível em 2.0:

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

Aqui temos um componente básico CustomInput que implementa o comportamento "fora de sincronia até o desfoque" dos filtros bidirecionais atuais. Devido às mudanças na versão 2.0, você pode usar v-model diretamente em componentes personalizados, desde que o componente aceite um prop value e $emita input eventos. Além disso, também formata o valor em eventos change , o que atualmente não é possível com filtros bidirecionais . Você pode ajustar ainda mais esse componente para obter qualquer comportamento desejado sem estar vinculado à forma como os filtros bidirecionais são implementados pela estrutura.

O componente base não implementa a lógica de análise/formatação - você o estende com os métodos parse e format para obter componentes de entrada personalizados adaptados para casos de uso específicos. Neste caso, um componente CurrencyInput .

O componente base é mais complexo do que os filtros bidirecionais, porque agora estamos implementando o comportamento mágico anterior. No entanto, você só precisa definir este componente uma vez. Em troca, você obtém controle total sobre como ele deve se comportar caso queira alterá-lo mais tarde. Acredito que essa seja uma troca digna.

Este é um exemplo de como devemos pensar mais em componentes porque é uma abstração unificada para reutilização que oferece mais controle. Veja também o exemplo 2.0 select2 - anteriormente em 1.0 isso era implementado como uma diretiva, mas agora é um componente com a mesma interface v-model .

Para mim, a melhor opção é fornecer os blocos de construção adequados para implementar esse comportamento por conta própria.

Isso é ótimo e definitivamente o que o Vue precisa, no entanto, eu gostaria de ter lido isso

Para mim, a melhor opção é fornecer os blocos de construção adequados para começar com o Vue e também estender o Vue com um novo comportamento de filtragem.

Em outras palavras, o componente de entrada de moeda, juntamente com vários outros componentes de filtragem padrão, não poderia fazer parte do Vue? Porque todo mundo usa moedas em algum momento, certo? Por que deixar para todos os outros fazer o mesmo trabalho de novo e de novo? A formatação de moeda é padrão o suficiente para torná-la parte do pacote de ferramentas de componentes de filtragem do próprio Vue e eles são um ótimo exemplo básico para outros aprenderem a criar seus próprios componentes de filtragem também.

E ..... há apenas uma coisa faltando no exemplo para ser um componente de entrada de moeda finalizado e esse é um recurso i18n, que acredito que o Vue também deve incluir. A formatação do número da moeda deve mudar dependendo da localidade selecionada da pessoa (do visualizador). Quero dizer dados de localidade, ou seja. "DE_de" para formatar a moeda e outros números conforme mostrado neste Locale Explorer (que deriva de um padrão). Adicione isso ao Vue e você terá um ótimo sistema de componentes de formatação de moeda / número embutido no Vue, que os milhares de outros devs que usam o Vue não precisam se criar, mas podem usar no local, quando obtêm o Vue . Isso torna o Vue um poderoso sistema de templates!

Se usar este "componente de formatação i18n" não pode ser usado de forma encadeada como um filtro como em 1.0, ele deve ser plugável. Isso seria bom também. Isso é o que Aurelia está fazendo e é o que Twig faz também com suas extensões . O componente de entrada de moeda ainda pode ser <currency-input> .

Este i18n e outros filtros de modelagem padrão realmente precisam ser algo que outros não precisam reproduzir constantemente, se não precisarem. Se você me mostrar como fazer um plug-in desse tipo, eu até faria o plug-in i18n para você. Estou muito interessado nisso como um todo! :smile:

Scott

Porque todo mundo usa moedas em algum momento, certo?

Não, realmente não. Eu, por exemplo, nunca realmente usei :) O mesmo se aplica a todos os outros filtros embutidos – alguns deles são úteis para alguns de nós, enquanto os outros são simplesmente inúteis. Enquanto estamos neste tópico, na maioria das vezes eu queria usar um filtro interno, acabei escrevendo minha própria versão de qualquer maneira, renderizando o código morto da versão interna.

um recurso i18n, que acredito que o Vue também deveria incluir.

Isso é, novamente, muito discutível. Um suporte abrangente a i18n pode ser bastante complexo, e o IMO não pertence ao Vue, especialmente quando a maioria dos usuários não precisa dele de qualquer maneira.

Agora, eu gostaria de levantar isso: toda vez que tentamos fazer uma comparação entre o Vue e outro template/framework, há uma coisa importante a ser lembrada: Ao contrário do Django/Laravel/Twig, o Vue é essencialmente uma biblioteca cliente e, portanto, precisa ser o mais leve possível. Faria mais sentido mantê-lo simples o suficiente - mantendo todos os recursos _core_, é claro - em vez de adicionar "recursos" e "utils" apenas por causa da chamada "utilidade" ou "elegância". Se você quiser algo além das funções principais, a maneira mais preferida seria usar um plug-in ou até mesmo desenvolver o seu próprio. Tome isso como um exemplo: Para um SPA comumente visto, i18n/currency é mais vital do que um roteador ou um gerenciador de estado? Acho que não. E ainda, vue-router e vuex não pertencem ao Vue, mas têm seus próprios repositórios. Em outras palavras, o Vue é progressivo .

Se você me mostrar como fazer um plug-in desse tipo, eu até faria o plug-in i18n para você. Estou muito interessado nisso como um todo!

Eu acredito que esta é uma abordagem mais sensata, e obrigado pelo seu interesse :)

se muito vai precisar usar i18n em algumas áreas)) Acho que posso entrar no código e alterar manualmente alguns nomes de algumas coisas, por beleza.
Por exemplo: apenas algumas horas atrás, levei butstrap.datepikker - eu não me conecto, i18n apesar do fato de que existe essa possibilidade. Rápidos 60 segundos. "Manualmente" substituiu os nomes dos dias da semana e dos meses, e tudo - ok! ))

@phanan - Sua argumentação é o motivo pelo qual mencionei "plugins". Eu concordo, nem todo mundo vai querer a funcionalidade de moeda ou i18n e aqueles que não podem manter seu aplicativo leve, mas como um sistema de templates, eu acredito (e esta é minha opinião pessoal) Vue também deve ter essa funcionalidade padrão disponível também. Mais importante, e minha preocupação, é que não deveria ser que todos tenham que reinventar o i18n ou as rodas do componente do filtro de moeda. Em outras palavras, assim como Vue-Router e Vuex são adições disponíveis ao Vue, um bom número de filtros padrão como moeda e i18n também podem ser.

Ah, e curiosamente, o Angular tem i18n embutido, parece.

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

Angular suporta i18n/l10n para filtros de data, número e moeda.

Ember e React parecem ter seguido a rota "deixe o mundo dos desenvolvedores fazer por conta própria".
Vídeo interessante.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Talvez o Vue precise apenas de uma integração com o FormatJS? VueIntl? :sorriso:

Edit: Não pode ser tão simples, pode? https://github.com/learningequality/vue-intl/blob/master/index.js

Scott

Angular tem i18n embutido ao que parece.

Angular também vem com ng-router que, pelo que ouvi, é evitado pelo ng-community em favor do ui-router.

Agora, se a equipe Angular substituir ng-router por ui-router, isso resultará em alterações e dor.

se eles tentarem melhorar o ng-router, eles estão perdendo seu tempo, pois já existe uma solução melhor (ui-router).

Se o Vue começou a suportar i18n, moeda etc em seu núcleo, a mesma situação acontecerá com o vue também.

Eu acho os filtros embutidos convenientes, mas neste assunto eu concordo com a equipe vuejs.

Então todos concordamos que os filtros não estão no núcleo Vue. Eu também sou um fã de componentização, na verdade. Mas, o Vue não poderia oferecer os filtros como plugins principais também? Como Vuex e Vue-Router?

Scott

Mas, o Vue não poderia oferecer os filtros como plugins principais também? Como Vuex e Vue-Router?

Isso é exatamente o que @blake-newman compartilhou anteriormente.

Oi: a página de decisão final indicou apenas permitindo filtro para texto
exibir {{}} (v-texto)
não para outras expressões como v-for="item of list | sortBy"
Ou eu entendi errado?
O que eu quis dizer foi continuar tendo filtro como em 1.0, mas limitando apenas um filtro
por expressão

Em domingo, 1 de maio de 2016 às 22h24, Phan An [email protected] escreveu:

@tomsmithgroup https://github.com/tomsmithgroup O que você sugeriu
(e mais do que isso) foram decididos
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 para
permanecem suportados em 2.0.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@yyx990803 Posso concluir da sua resposta que os filtros bidirecionais não serão suportados na versão 2.0?

@fnlctrl está correto. Basta construir seus próprios componentes.

Vou fugir um pouco do assunto: esses filtros bidirecionais são realmente úteis na produção?
Quero dizer, é realmente bom deixar o usuário digitar qualquer coisa em uma entrada e reformatá-la depois que ela estiver desfocada?
Minha equipe de negócios sempre exige que nossas entradas ajam assim : você não pode digitar nada errado. Então, mesmo agora, com Vue , usamos jquery.inputmask para esse propósito, pois a mudança bidirecional instantânea foi preterida (essa eu realmente sinto falta ...)
Quero dizer, há realmente um problema com esses filtros bidirecionais ou pessoas apenas pensando demais? :)

@fullfs Filtros bidirecionais são amplamente usados ​​em nosso aplicativo de produção (muitos <input> s) por conveniência, mas como vejo agora, por que filtrar os valores em tempo real em vez de apenas filtrá-los uma vez antes de serem POST-ed para o servidor? Vai levar algum tempo para refatorar o código, mas acho que não vou sentir falta deles :D

Se você deseja uma atualização otimista da interface do usuário (que é a norma hoje IMHO, especialmente para dispositivos móveis), você desejará a entrada formatada corretamente praticamente no momento em que a entrada foi fornecida.

Scott

Os filtros de 2 vias são muito bons no vue. Você sempre pode construir seus próprios componentes personalizados, com ou sem filtros disponíveis, mas isso leva tempo. A biblioteca deve fornecer flexibilidade, mas também uma maneira mais rápida e conveniente de fazer as coisas. A inclusão de filtros de 2 vias não impediria as pessoas de construir seus próprios componentes se necessário, mas permitiria um desenvolvimento mais rápido quando a funcionalidade existente atendesse às necessidades, o que acontece na maioria das vezes. É sempre um compromisso entre a superfície da API e a conveniência. O equilíbrio tem que ser encontrado, e o Vue já tinha um ótimo. Livrar-se dos filtros parece ser um passo atrás do ponto certo de equilíbrio. A biblioteca fica menor, mas a base de código e o clichê de todos os projetos que a utilizam crescem cada vez mais.

Se os filtros forem realmente obsoletos, talvez seja bom fornecer uma alternativa capaz de especificar um analisador e um formatador para diretivas v-model, de maneira fácil. Com filtros é possível escrever apenas esta parte do exemplo @yyx990803 fornecido:

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

Sem filtros de 2 vias, também é necessário escrever

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

Portanto, mais flexibilidade, mas também mais código para o mesmo resultado.

@aristidesfl - os filtros não estão sendo preteridos. Vencemos a batalha, parcialmente. LOL! Eles serão limitados a serem usados ​​apenas em interpolações de texto. Veja aqui: https://github.com/vuejs/vue/issues/2873

Scott

Obrigado @smolinari . Eu estava me referindo particularmente aos filtros de 2 vias.

por favor volte! precisamos disso, concordo com tudo o que você disse. mas é tão fácil, somos usuários preguiçosos, só queremos uma maneira fácil e preguiçosa. assim como manter-se vivo.

Pode haver uma maneira de adicionar modificadores de modelo v personalizados (http://rc.vuejs.org/guide/forms.html#Modifiers)

Eles funcionam como filtros bidirecionais.

@ecmel concordou. Este é o caminho a seguir.

Abra um problema de solicitação de recurso então :)

@ecmel uma ideia semelhante, embora descrita como modificadores de tipo, foi discutida aqui .

@rpkilby Essa discussão também está encerrada, talvez devêssemos abrir uma nova para modificadores de modelo v personalizados.

Não é mais possível fazer isso:

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

Limitar filtros a {{ }} parece estranho, muitas vezes você gostaria de usar um filtro em uma ligação de atributo (não passando um prop), e não podemos mais usar {{ }} em atributos !

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

Limitar filtros a {{ }} parece estranho, muitas vezes você gostaria de usar um filtro em uma ligação de atributo (não passando um prop), e não podemos mais usar {{ }} em atributos !

Eles foram removidos porque podem ser facilmente substituídos por propriedades e métodos computados, embora tenham uma API mais limitada e nenhuma possibilidade de armazenar em cache os resultados.

Assim:

• uma API a menos
• use os mesmos métodos no modelo e no código JS, não há necessidade de duplicar o comportamento do filtro para usar no código do aplicativo.
• adereços computados podem ser armazenados em cache
• mais flexibilidade porque é apenas JS

pseudocódigo adiante:

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

Desculpe, eu sou apenas "novo".
Mas, vindo do Angular 1, não ter filtros parece realmente estranho e contra intuitivo, por que seria melhor que cada desenvolvedor desenvolvesse seu próprio conjunto de filtros e definindo as entradas computadas etc. melhor do que tê-lo embutido?
E o que agora é considerado a melhor prática para filtrar uma matriz realmente grande, por objetos no elemento. Com angular, isso era apenas uma linha de código. Era possível filtrar um array para uma entrada de pesquisa e isso faria toda a mágica, que deveria ser a função de um framework.

E o que agora é considerado a melhor prática para filtrar uma matriz muito grande

O que é uma matriz realmente grande? Teoricamente, uma propriedade computada também serviria para filtrar.

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

por que seria melhor que cada desenvolvedor desenvolvesse seu próprio conjunto de filtros e definindo as entradas computadas etc. melhor do que tê-lo embutido?

Eu costumava pensar da mesma maneira (e por que comecei o tópico), mas desde que aprendi que é basicamente um pedaço de bolo criar esses tipos de filtros por conta própria, e que há tantas coisas que cada desenvolvedor pode querer como um filtro (ou propriedade computada), percebi que não é grande coisa não ter filtros embutidos.

Scott

No meu caso, é igual a > 10.000 linhas em json fornecidas por um banco de dados do Firebase.
Entendo por que você pode pensar dessa forma e decidir descartar o recurso, no entanto, é um incômodo adicional para os desenvolvedores.

Eu bifurquei o violino para estar alinhado com minha estrutura de dados:
https://jsfiddle.net/nw5yhLwv/
Então eu preciso codificar a pesquisa de uma string no meu objeto manualmente?

Eu não entendo sua pergunta. Desculpe. O violino se parece com o que eu postei.

Scott

Computado vs. filtros

Os filtros são possivelmente ruins para o desempenho, já que são calculados para cada renderização (assim como os métodos) e as propriedades computadas são fáceis de fazer, e só são recalculadas, quando necessário, caso contrário os resultados são armazenados em cache, o que significa que o Vue pode voar.

Oh. e nós temos os dois. 😄

Scott

Ei, eu fiz um pouco de violino e agora entendi, é um ótimo conceito! 😄

Vou bloquear este tópico agora, já que a discussão sobre isso está encerrada há muito tempo - o Vue 2.0 foi lançado há alguns meses e as críticas sobre a queda de filtros diminuíram amplamente.

Uma discussão mais aprofundada neste tópico não é produtiva. Se você vir um novo ângulo para o tópico que você acha que precisa de discussão, abra uma nova questão.