Vue: [Sugerencia] Vue 2.0: devuelva los filtros, por favor

Aclarando un punto que originalmente vino del chat de Gitter: debounce no es un filtro, y fue solo otro de los cambios 2.0 que la gente no estaba encantada de perder.

Corrección cortesía de @JosephSilber : debounce es tanto un filtro como un parámetro v-model .

Gracias @agc93. He quitado ese punto.

scott

En el peor de los casos, crearemos pequeños complementos para solucionar esto. Acerca de los filtros, hay https://www.npmjs.com/package/babel-plugin-pipe-operator
El problema es que esto no funcionará sin la compilación de babel.

Tampoco estoy muy entusiasmado con algunos de los cambios. Para los filtros, parece haber una alternativa fácil al registrar mixins globales . Sin embargo, no me gusta mucho la idea de contaminar todos los alcances de los métodos de mis componentes para tareas ultrasimples como pluralizar, etc. Sin embargo, nunca he usado filtros de dos vías.

Los filtros eran convenientes y hermosos. Las dos cosas que vue siempre hizo bien (hasta ahora).

Cuando leí la publicación en vue 2.0, me entusiasmaron todas las nuevas posibilidades (especialmente el dominio virtual y la representación del servidor), pero también me sorprendió y me entristeció un poco que los filtros desaparecieran.

Eran una de mis partes favoritas de vue, no solo porque eran fáciles de usar y encadenar, sino principalmente porque eran fácilmente extensibles y tenían una hermosa sintaxis para usarlas directamente en la plantilla. Especialmente en combinación con bucles v-for , eran una combinación perfecta.

Pensando que tendré que usar propiedades calculadas para reemplazar el filtrado para todos y cada uno de los accesorios que quiero, me preocupa escribir mucho en el futuro. Si bien los mixins pueden mitigar una parte del problema, todavía siento que faltará una parte de la elegancia y la facilidad de uso de vue.

Todos los que estén de acuerdo con esto, ¿pueden simplemente hacer clic en el pulgar hacia arriba debajo de la descripción? es mejor que enviar spam a 17 mil personas con +1 . Aún mejor, proponga algunos casos de uso significativos.

Nunca he usado filtros de dos vías, ¡pero realmente extrañaría los filtros! Puedo (ya veces lo hago) usar propiedades calculadas, pero en algunos casos simples, es una conveniencia que realmente acelera el flujo de trabajo.

Considere este ejemplo muy simple

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

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

Lo anterior es mucho más fácil de escribir en los casos en que no se requiere tener un filtrado más complejo.

Ahora compáralo con lo siguiente

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

No digo que el segundo sea difícil de escribir, pero cuando lo usa en muchos lugares, comenzará a repetirse, ¡y solo toma un tiempo extra que quizás podría usar en otras características más útiles!

De cualquier manera, seguiré siendo un usuario feliz de Vue, ¡solo compartiré mi opinión sobre los filtros obsoletos!

Los filtros son reutilizables. Puedo crear una función para formatear mis datos una vez, registrarlos como un filtro y simplemente usarlos desde todas las instancias. ¿Cómo puedo hacerlo en 2.0?

¿Cómo puedo hacerlo en 2.0?

• mezclando
• Módulo separado con método
• Módulo separado con función de utilería calculada

Acabo de dejar un comentario en el hilo del anuncio, así que en lugar de duplicarlo todo aquí, simplemente lo enlazaré:

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

Entiendo perfectamente la sensación de que te quiten algo súper conveniente. Pero primero tómese un momento para leer el comentario de @chrisvfritz en el hilo del foro anterior. Para facilitar la discusión, solo lo copio y lo pego aquí:

@theotherzach ¡ Gracias por tu pasión por Vue! Me gustaría explicar un poco mejor la desaprobación, pero primero, debo presentarme. Soy miembro del equipo central de Vue, uso Vue todo el tiempo para mi trabajo independiente de visualización de datos y interfaz de usuario, y también soy un educador que enseña a las personas a usar Vue y Rails, entre otras tecnologías web. Dirijo una escuela de código, por lo que ayudo a las personas a aprender a usar estas herramientas (y usarlas juntas) casi _todos los días_.

También fui uno de los grandes defensores de la eliminación de filtros en Vue 2.0.

El problema con los filtros para principiantes en Vue

Una gran parte de la razón por la que estaba a favor de desaprobar los filtros era en realidad _para_ principiantes. Cuando se trabaja con estudiantes, esta es una conversación que surge más de una vez:

• Estudiante: "¿Entonces un filtro es básicamente una función?"
• Maestro: "¡Sí!"
• Estudiante: "Está bien, ¿puedo usarlo normalmente con paréntesis de función?"
• Mentor: "Bueno, no. Es un tipo especial de función".
• Estudiante: "¿Puedo usarlo en otros lugares? ¿Como en un valor calculado?"
• Mentor: "No, solo puede usarlo en plantillas y solo con la sintaxis de tubería especial".
• Estudiante: "... ¿por qué?"

Una de las grandes cosas que hacen tropezar a los principiantes son las _excepciones_. Los filtros son solo funciones, _excepto_ que requieren una sintaxis especial y no se pueden usar en todas partes. Y usan una sintaxis de tubería que es diferente de la sintaxis de tubería que puede integrarse en ES7 , lo que significa que no pasará mucho tiempo hasta que las personas tengan dos operadores muy similares para hacer algo muy similar, pero no son _totalmente_ iguales. Y solo uno de ellos es en realidad JavaScript.

Las bibliotecas de utilidades _son_ útiles, pero Vue no lo es

En el caso de filterBy , transforms para cadenas y números, y otros filtros específicos, sí, son útiles en las aplicaciones donde surgen. Las bibliotecas de utilidades en general son útiles. Y hay docenas de excelentes bibliotecas de utilidades para elegir, pero Vue no es una biblioteca de utilidades. Y francamente, ninguna de las utilidades que hemos ofrecido ha sido la mejor en su clase.

Manejar monedas, fechas o incluso filtrar matrices: estos no son nuestro enfoque. Muchas aplicaciones no los requieren y la mayoría de las aplicaciones en las que he trabajado que _sí_ enfrentan estos problemas requieren una solución más robusta que la que Vue ofrece actualmente (o _podría_ ofrecer sin introducir una reinvención significativa de la rueda).

En mis aplicaciones, Accounting.js ha manejado la moneda magníficamente, Moment.js (como mencionaste) maneja fechas y horas, pluralize no maneja bien muchas pluralizaciones, por lo que un valor calculado personalizado suele ser más deseable, y json es poco más que JSON.stringify .

Las ventajas de las propiedades calculadas

El uso de propiedades calculadas en lugar de filtros también ofrece la ventaja de que el valor procesado se puede reutilizar fácilmente en SECO _en cualquier lugar_ del componente. Me encuentro teniendo que hacer esto en mis aplicaciones todo el tiempo. La propiedad calculada también saca más detalles de implementación de la plantilla, dejando solo una descripción limpia de lo que hace el componente. Y una ventaja sobre los filtros definidos globalmente es que uno solo necesita mirar la función para ese valor de computadora para ver y modificar exactamente cómo está funcionando. En las matrices, el encadenamiento de los métodos map y filter JavaScript incluso proporciona la misma lista lineal de procesamiento que hacen las canalizaciones, pero de una manera aún más declarativa y fácil de manipular.

La utilidad de definir globalmente lo que sea

Si necesita definir una función o cualquier otra cosa que desee que esté accesible en todos sus componentes, Vue.prototype.whateverIWant = mySuperCoolFunction es una excelente forma de hacerlo. Personalmente, nunca _quise_ hacerlo. Siempre he preferido poner un método auxiliar en un módulo e importar ese módulo donde lo necesito. Pero aún es importante tener en cuenta que registrar globales, de cualquier tipo, no es más difícil.

El caso de la directiva debounce

¡Tengo que decir que en realidad estoy contigo en esto! Recientemente revisé todos mis proyectos de Vue y cada uno que tenía un input alguna parte también usaba debounce . De hecho, solo una de mis aplicaciones anteriores _no_ usó antirrebote. Si bien técnicamente es una utilidad (lodash y muchos otros proyectos sólidos ofrecen soluciones antirrebote), este problema es bastante universal para el desarrollo de la interfaz de usuario, para _cualquier_ tipo de aplicación. Escribir su propia función de rebote tampoco es lo suficientemente trivial como para que probablemente quiera usar la implementación de lodash para casi todos los proyectos.

Queda cierto debate interno sobre esto, así que veremos a dónde va. Pero sí, para mí personalmente y también para otros, eliminar el rebote elimina la mayor parte de la comodidad que ofrece v-model .

De nuevo, ¡gracias por tu pasión!

En serio, nos encanta cuánto amas a Vue y estamos muy contentos de que expreses tus preocupaciones, ¡y especialmente de una manera tan amable y respetuosa! Te estamos escuchando. El equipo central está formado por diseñadores, desarrolladores front-end y especialistas en visualización de datos. Todos usamos Vue para nuestro propio trabajo, que es bastante diverso, por lo que definitivamente estamos dedicados a sacar comida para perros que querremos comer nosotros mismos. :-)

Hablar es barato, vamos a codificar a ver si sin filtro, como aplicamos filterBy y viceversa:

escriba funciones de filtro puras globales en un archivo separado para la reutilización del 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 en la plantilla 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>

vea el resultado aquí http://raywill.github.io/vuefilter/

Si se usa el filtro, el siguiente código vue haría lo mismo:

<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, con el filtro soportado podríamos escribir código menos trivial.
Personalmente, prefiero la forma vue 1.0, que hace que la codificación sea más agradable.

En cuanto a las preocupaciones repetitivas, hay varias formas de lidiar con ellas.

1. Importar/exportar explícitamente

Como @raywill demostró arriba. Es un poco más detallado, pero los beneficios son que:

1. No tiene que buscar la documentación del filtro de Vue para comprender cómo funciona. Es súper explícito de dónde provienen las funciones y cómo se implementan.
2. Las funciones en sí son solo JavaScript. Puede modificarlos/componerlos para que se ajusten a casos de usos especiales, a diferencia de los filtros incorporados que no puede tocar.
3. Puede importar y reutilizar mediante programación estas funciones en métodos, propiedades calculadas y en cualquier lugar donde escriba JavaScript.

2. Adjuntarlos a Vue.prototype

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

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

3. Sea funcional (para usuarios avanzados)

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

Donde las funciones auxiliares se ven como:

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

Nuevamente, una consideración de diseño muy importante es que los filtros incorporados pueden ser útiles, pero carecen de la flexibilidad de JavaScript puro . Cuando una función incorporada no se adapta a sus necesidades, termina reimplementando algo similar (y enviando ambos en su código final, donde el código incorporado se vuelve inútil, código inactivo), o tiene que esperar a que Vue actualizarlos y lanzar una nueva versión.

@yyx990803 Me gusta el enfoque de prototipo, pero ¿qué pasa con los casos en los que necesita varios filtros?

Es bastante común usar orderBy junto filterBy

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

¿Qué hay de los casos en los que agregaría limitBy también?

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

¿Este enfoque hace que el código sea menos legible?

Sí, al menos en mi opinión.

Supongo que podríamos haber combinado filtros como filterAndOrderBy pero eso tampoco se siente bien.

Estoy abierto a los cambios, ¡solo quiero encontrar una manera casi tan fácil de manejarlo!

Además, el beneficio de poder usar los filtros en cualquier lugar también es un buen punto.

Solo para tener en cuenta, @vuejs/collaborators han estado discutiendo una opción para proporcionar un paquete de utilidades de los filtros integrados actuales. Hay muchos recursos que le proporcionarán herramientas de utilidad para su base de código.

Una cosa buena de eliminar los filtros principales es que ahora puede personalizarlos/implementarlos usted mismo. Lo que te da mucha más flexibilidad.

Las expresiones de plantilla de <div v-for="filteredData"> </div> . Esto puede ser un accesorio calculado, que puede contener la lógica para crear los datos filtrados. Esto es mucho más legible, y es mejor que algo como:

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

Es mucho más reutilizable para asignar como una propiedad calculada, e incluso puede transmitirse a componentes secundarios. ¿Qué pasaría si quisiera usar los datos filtrados en dos lugares? Es más fácil, simple, confiable y legible que las plantillas tengan expresiones simples, en comparación con filtros encadenados en las expresiones.

Para cualquiera que me siga, respondí a @chrisvfritz aquí: http://forum.vuejs.org/topic/3891/annunciando-vue-js-2-0-public-preview/17

Lo siguiente resuelve mi caso de uso de _muy_ pocas funciones auxiliares de vista pura disponibles globalmente. Retiro mis preocupaciones sobre la eliminación del filtro. ¡Quémalos! 🔥 ¡Felicitaciones a @chrisvfritz y @yyx990803 por cambiar la opinión de alguien (la mía) en Internet!

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

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

Estoy totalmente de acuerdo con @ yyx990803 , elimino los filtros y me limito a las funciones simples de JS.

@ blake-newman Ese es un muy buen punto, estoy mayormente convencido en este punto, y pensando en la legibilidad, creo que se puede lograr algo como esto

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

Aquí hay un jsfiddle rápido del concepto.

Una cosa buena de eliminar los filtros principales es que ahora puede personalizarlos/implementarlos usted mismo. Lo que te da mucha más flexibilidad.

Siempre pudo personalizarlos/implementarlos usted mismo.

Vue no es una biblioteca de utilidades. Y francamente, ninguna de las utilidades que hemos ofrecido ha sido la mejor en su clase.

Lo que nos preocupa es eliminar la funcionalidad de filtro en las plantillas. La eliminación de los filtros incorporados tiene mucho sentido: se pueden recrear fácilmente enviándolos a guiones bajos u otras bibliotecas de utilidad. Entonces, alguien podría incluso lanzar un solo complemento que recrea todos los filtros incorporados actuales.

El uso de propiedades calculadas en lugar de filtros también ofrece la ventaja de que el valor procesado se puede reutilizar fácilmente en SECO en cualquier parte del componente.

Por supuesto, puede usar propiedades calculadas si tiene que reutilizarlas en otro lugar. Pero si no lo hace, un filtro sigue siendo mucho más conveniente.

Hay algunos otros puntos que publiqué en ese enlace que compartí arriba.

¿Por qué no admitir una sintaxis para filtros que funcione como la sintaxis propuesta por ES7? Eso permitiría a las personas seguir usando sus queridos filtros y alinearlo con lo que puede deparar el futuro. Eventualmente, cuando tengamos tuberías ES7, puede cambiar la implementación interna sin cambiar la API.

¿Las tuberías ES7 están aprobadas o sujetas a muchos cambios?

En teoría, está sujeto a cambios, pero parece... ¿estable?
Estado: mindeavor/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Creo que estamos en la misma página con respecto al valor de las tuberías en general. 😃 Una ventaja del nuevo compilador en 2.0 es que podemos canalizar el código de la función de renderizado generado a través de Babel. Esto aún debe explorarse más a fondo, pero no es inconcebible que una vez que |> gane más impulso y se desarrolle un complemento de Babel para él, felizmente podría encadenar métodos con tuberías nuevamente, _en todas partes_ en su aplicación. Como gran fanático de LiveScript y otros lenguajes funcionales, ¡definitivamente reconozco el valor !

este operador de tubería ni siquiera está en la etapa 0

@thelinuxlich Sí, creo que todavía están esperando un campeón en TC39. 😞

@rigor789 ¡ esa es una de las alternativas que quería mencionar también! El poder de JavaScript le permite lograr la expresividad de su elección y, en mi opinión, es mejor que poner la lógica de filtrado dentro de las plantillas.

@ yyx990803 ¿Cómo funciona Vue en los siguientes casos, cuando se actualiza el nombre de un usuario?

<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 el primero solo volvería a renderizar un objeto, mientras que el segundo volvería a calcular la lista completa.

@rpkilby eso no parece ser el equivalente. Sería más como:

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

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

Todavía no me gusta la idea de usar métodos como filtros (como intuición, parece incorrecto, pero realmente no puedo explicarlo). De cualquier manera, discutió otros métodos para hacer que los filtros estén disponibles, entonces +1.

Nada de lo sugerido en este hilo se acerca a la expresividad y brevedad de los filtros. Simplemente no lo hace.

Y eso me pone muy triste. Como dije en el hilo del foro: para mí, esto elimina una gran parte de lo que hace que Vue Vue.

Si me buscas, puedes encontrarme en la esquina sollozando audiblemente 😟

De ninguna manera, este cambio fomenta una buena codificación de Javascript, trátelo :)

Así que acabo de tener una larga discusión con @yyx990803 , donde, desde la perspectiva del usuario, sugerí mantener el soporte de _syntax_, porque se siente elegante y natural. Mi imaginación era algo así:

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

Tenía la impresión de que esto se acercaría a lo mejor de ambos mundos.

Sin embargo, al final, estoy convencido de que eliminar los filtros en su conjunto es en realidad algo mejor: como acaba de decir @thelinuxlich , fomenta un mejor JavaScript y pensamiento lógico. No introducimos la lógica en Laravel's Blade ni en la capa de vista de ningún otro marco, y no deberíamos hacerlo en las plantillas de Vue.

Dicho esto, @JosephSilber si miras hacia la otra esquina, me encontrarás allí.

Para mí, los filtros se sienten muy hermosos, la sintaxis es exactamente como debería verse una sintaxis de filtro.

También una cosa atractiva de Vue para mí es que viene con (algunas) baterías incluidas. Sería realmente triste perder cualquiera de estas cosas, las cuales, en mi opinión, hacen que Vue se destaque.

Al leer el hilo, parece que la mayor parte de la preocupación con los filtros era el hecho de que Vue tenía filtros predeterminados, y no realmente la función en sí (¿o lo es? Todavía no estoy seguro).

Me gusta el pensamiento del complemento de filtro de @blake-newman y debería haber ejemplos prediseñados. Si a otras personas se les ocurren otros filtros, deberían ser plug and play. Eso seria genial. Estoy absolutamente de acuerdo en que la creación de filtros es responsabilidad del usuario.

Lo que aún se desea son las capacidades de canalización y encadenamiento y la globalidad de la función de filtro original. Las preocupaciones sobre la globalidad fueron cubiertas por @yyx990803. ¿Qué tal el encadenamiento con la tubería? Ayuda mucho a leer las plantillas y comprender lo que se espera como resultado. La tubería y el encadenamiento se discutieron anteriormente. ¿Todavía se puede hacer? ¿Por qué es algo malo en absoluto? Para el diseñador, ¡es oro! El filtro es una herramienta de diseñador, no del programador JS. Entonces, el argumento de escribir mejor JS cae fuera del tablero, en mi libro, pero puedo entender por qué sería necesario. Pero, como diseñador, también quiero escribir mejor código, y los filtros me lo permiten maravillosamente. :sonrisa:

scott

Esto es lo que ocurre con el encadenamiento: los filtros se utilizan principalmente para dos propósitos:

1. formato de texto;
2. procesamiento de una matriz.

En el caso de dar formato al texto, el 90% o más de las veces se utiliza un único método de utilidad. El encadenamiento no es realmente un gran problema en este caso.

En cuanto a las matrices: ya he señalado que el procesamiento de matrices es, de hecho, lógico y se adapta mejor a JavaScript. Tener varios filtros de matriz encadenados puede verse bien cuando es simple, pero puede volverse feo cuando usa más de 1 argumento para cada uno. También lo alienta a poner demasiada lógica en su plantilla cuando en realidad no debería hacerlo. También son inflexibles (no pueden recuperar fácilmente el valor procesado). En comparación, con ES2015 el ejemplo original

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

Se puede escribir 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)
  }
}

Es solo JavaScript, no tiene magia, no tiene una sintaxis alternativa y una API específica de filtro para aprender. Y puede acceder al valor procesado (que se almacena en caché de forma inteligente). También puede agregar azúcar encima de esto como se muestra en los comentarios anteriores. Además, su plantilla se ve más limpia:

<div v-for="filteredThings">

Sé que esto es como algo práctico que se está quitando, pero honestamente, los argumentos a favor de los filtros en este momento me suenan a tratar de mantener la sintaxis por el bien de la sintaxis. En mi opinión, se necesita algo más que "porque es elegante" para justificar una función: debe proporcionar un valor objetivo. Este fue el caso de inline-templates , pero no lo veo para los filtros.

@ yyx990803 : creo que su ejemplo ejemplifica el problema. Nuevamente, no soy el mejor programador de JS, pero no necesito ser un programador de JS para saber que filteredThings no dice nada sobre lo que realmente hace. Para mí, eso es una mala práctica. :smile: El hecho de que el método de filtrado sea global también significa que debo buscar en documentos, el código o descifrar la salida para averiguar qué hace el método. No muy elegante. ¿Correcto?

Tan bien. podríamos tener un nombre de método como `filterByOrderByAndLimit'. ¿Qué pasa con los argumentos?

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

¿Sería eso correcto?

Si es así, podría ser factible. Aún así, no se ve bien.

Y ahora solo quiero filterBy y OrderBy. ¿Necesito un método separado para hacer eso también? Y luego quiero agregar formato de moneda. ¿Otro método? El encadenamiento de filtros en las plantillas hace que la manipulación de la presentación sea flexible y muy expresiva. Esta preocupación aún no se ha abordado adecuadamente con los métodos (y mi falta de conocimiento no me permite comprender que los métodos pueden ser mejores).

¿Puede ser esto posible?

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

Estoy de acuerdo en que aplicar demasiada lógica en una plantilla es algo que se debe evitar. Pero, el encadenamiento de filtros y la capacidad de simplemente insertar un filtro en cualquier parte de los componentes/plantillas de una aplicación es un concepto fantástico y hubo una razón por la que lo agregó para empezar. ¿Cuál fue esa razón o razones? Si puede nombrarlos, entonces apostaría dinero que superan "pero promueve malas prácticas" por una milla.

Cualquier cosa que permita la flexibilidad se puede usar incorrectamente, al igual que Vue. El argumento principal para inline-template era que era flexible y permitía que Vue se usara de diferentes maneras. Los filtros no son muy diferentes, aparte de que son internos de Vue y no afectan cómo se puede usar Vue externamente. Aún así, eso no devalúa su importancia. Recuerde, muchas personas también han dicho que esto sería imposible para ellos actualizar. ¡Así de importante es! :sonrisa:

La nueva forma solo necesita los mismos atributos que tenía la antigua.

• encadenable
• global
• agregue a las plantillas para expresar bien cómo se manipularán los datos en las plantillas

(¿Me olvidé de algo?)

Si puede hacer todo eso, entonces estoy seguro de que todos estarán bastante satisfechos. Personalmente, no puedo ver que suceda con los métodos (todavía).

scott

@smolinari

1. He dicho claramente que debería poner menos lógica en sus plantillas. Esta es mi opinión, les guste o no. Obviamente, es libre de estar en desacuerdo, pero no puedo ayudarlo si desea trabajar en contra de las mejores prácticas recomendadas.
2. Dado (1): he explicado por qué el encadenamiento no es un problema porque la lógica compleja debe realizarse en JavaScript.
3. También he dado ejemplos de cómo puede agregar métodos disponibles globalmente.
4. Vea el ejemplo de @rigor789 en una sintaxis de encadenamiento personalizada similar a la que desea.
5. El objetivo del marco es proporcionar lo que _yo_ creo que es la mejor manera de desarrollar aplicaciones front-end, no para complacer a todos. Por lo tanto, no use "No actualizaré si no me devuelve esta función", ya que no funciona.

¿Por qué no prueban esta nueva versión alfa durante una semana y luego vienen con algunos comentarios realmente valiosos (basados ​​en su práctica)? Tal vez intente refactorizar su aplicación existente y háganos saber qué era imposible, qué se mejoró, qué empeoró, para que podamos discutirlo mejor. Eso sería útil para todos, creo.

@ yyx990803 - Acepté 1. Así que estamos de acuerdo. :smile: Simplemente no estoy de acuerdo en que sea una razón adecuada para sacar algo que ha ganado tanto amor.

Entonces, supongo que con el tiempo ha decidido que el JS pragmático es mejor que el HTML pragmático.

El argumento de no ir por no actualizar es lo que otros han dicho. Solo estoy tratando de comunicar y mitigar eso.

Un último argumento de mi parte. Mira esto desde los ojos del usuario del usuario. Digamos que tengo un sistema como Laravel o algún otro sistema MVC o MVVM que incorpora Vue, que también permite al usuario de ese sistema construir sus propios componentes. El filtro, tal como estaba, simplifica la curva de aprendizaje y permite a los usuarios de ese sistema hacer mucho, sin tocar ningún JS. Soy fanático de Vue, porque permitió que los programadores que no eran JS aún hicieran mucho. Esta es la misma razón por la que no me gustan React y JSX. Esa combinación tendrá una base de usuarios mucho más pequeña que Vue a medida que pase el tiempo. Apuesto dinero a ello.

También entiendo que la verdadera flexibilidad radica en JS. Aún así, no confíe únicamente en JS para la flexibilidad en Vue. Téngalo en cuenta, no todo el mundo es un programador JS asesino. De hecho, la mayoría de la gente no lo es. El filtro fue una buena manera de hacer mucho por esas personas y fue un buen trampolín hacia una mayor manipulación de JS. ¿Los filtros no pueden hacerlo? Profundice en los métodos JS.

Está bien. Suficiente de mí... he terminado. Y, gracias por escuchar en cualquier caso. ¡Vue sigue siendo increíble! :sonrisa:

@ azamat-sharapov: buen punto.

scott

Ver a la gente tratando de justificar las malas prácticas dentro de JS me entristece. Realmente, no necesitas ser un profesional, solo haz la tarea básica (¿o ya no es básica en estos días?)

El problema que tengo con los filtros dentro de los métodos es de semántica.

En términos de ups, los filtros son como funciones estáticas mientras que los métodos son funciones no estáticas.

Los filtros transmiten semánticas extremadamente diferentes a los métodos. la mayor diferencia es que los filtros no pueden usar this , pero los métodos sí.

@ yyx990803 al usar Vue.prototype.filters puede funcionar, pero cambiar Vue no me parece una buena práctica. Prefiero recomendar la creación de un objeto separado (global) que contenga todos los filtros.

No parece una buena práctica porque globals no es una buena práctica. El enfoque recomendado es importar explícitamente métodos auxiliares. Adjuntar al prototipo es una solución para aquellos que no desean importar métodos explícitamente.

En cuanto a la semántica, los filtros son un concepto acuñado de todos modos. En JavaScript, no inventarías una semántica diferente solo para escribir en mayúsculas una cadena: llamas a una función. Y eso es lo que son, funciones JavaScript.

Voy a hacer un comentario más para tratar de aclarar mi punto personal, principalmente por el comentario "tratando de justificar las malas prácticas dentro de JS". Ciertamente no estoy tratando de hacer eso.

Me doy cuenta de que Vue es más que un simple sistema de plantillas, pero también es un sistema de plantillas y me temo que está tratando de alejarse de ese rol, lo que creo que no debería. Entonces, como motor/sistema de plantillas, tome el motor de plantillas Twig como un ejemplo muy exitoso de lo que uno podría esperar de un sistema de plantillas. Tienen una sección " Para los diseñadores de plantillas " y una sección " Para los desarrolladores " en sus documentos. Como sistema de plantillas, Twig también es poderoso para el diseñador de plantillas, porque está repleto de comportamientos predeterminados, incluidos los filtros . Permite a los no desarrolladores hacer mucho con el sistema de plantillas, sin conocer directamente PHP. Solo tienen que aprender lo que Twig tiene para ofrecer y cómo usarlo. Estoy buscando esto en Vue también. También me gustaría ver una sección "Vue para diseñadores de plantillas" en los documentos. :sonrisa:

Además, muy importante es la extensibilidad de Twig. Si algo no está disponible en la versión estándar, se puede agregar. Ahí es cuando interviene el desarrollador. Lo bueno es que las extensiones también se pueden compartir, lo que significa que solo se debe hacer una vez.

La otra cosa buena de estos dos niveles de diseñador/desarrollador es que obtienes una base de usuarios mucho más amplia. Mucho, mucho más amplio y esto es lo mismo con . Y cuando los valores predeterminados de comportamiento no son suficientes, es cuando comienzan a aprender, de buena gana, el lenguaje subyacente. Y ahí es cuando aprenden las mejores prácticas y lo demás.

Si está diciendo que Vue no puede ser un motor de plantillas sin tener que aprender JS, entonces diría que está reduciendo considerablemente su valor de mercado. Si dice, dejará la puerta abierta para permitir que otros hagan esas herramientas para el motor de plantillas como complementos, genial. Pero entonces todos lucharán por lo que debería estar en el sistema de plantillas. Eso también es contraproducente en mi humilde opinión.

En el ejemplo de su estudiante hablando sobre los filtros, Evan, ¿era alguien que estaba aprendiendo JS o alguien que estaba aprendiendo un motor de plantillas? Si fuera lo último, apuesto a que la conversación sería diferente.

De todos modos. Sigo pensando que Vue es un sistema ganador. Espero que mis pensamientos puedan hacer que otros piensen de manera diferente sobre los roles de Vue de alguna manera. :sonrisa:

scott

@yyx990803 si los filtros son un concepto acuñado, ¿por qué se acuñaron en primer lugar?

Creo que es porque dentro <template> todas las variables externas como $data o abc se convierten en this.$data y this.abc y, por lo tanto, se definen funciones simples de js fuera del componente no se puede hacer referencia. Se introdujeron filtros para superar esta limitación.

Esa limitación aún existe ---Supongo que tengo razón--- para eliminar la limitación requeriría que los desarrolladores codificaran explícitamente this.abc para hacer referencia a this.abc y acceder a las funciones js como se haría referencia en js.

Pero esa será una característica demasiado poderosa, propensa al abuso y la migración del código antiguo será un dolor. la sintaxis actual me parece mucho mejor que eso.

Estoy de acuerdo con usted en que los filtros son básicamente funciones js y deben importarse al componente. Simplemente no me gusta que estén definidos en el mismo lugar que los métodos.

Hola a todos. He leido todo el hilo y esto es lo que pienso.

• Nadie extrañaría los filtros incorporados como orderBy filterBy y cualquier otro
• Lo que todos quieren tener todavía es el operador de tuberías en las plantillas.
• El equipo central dice que la lógica debe mantenerse en javascript, no en plantillas, además de que viene una característica de es7 con el operador de canalización.

Teniendo eso como un resumen rápido, creo que podría ser una buena solución hasta que js implemente un operador de tubería nativo , sería tener el operador de tubería como un complemento y mantener la versión 2.0 tal como está. Entonces, los usuarios pueden hacer

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

Mientras esperamos la implementación de la nueva función, podría incluirse con alguna advertencia sobre la próxima desaprobación o algo así. Sé que cualquiera podría implementar ese complemento, pero creo que sería mejor si el equipo de Vue lo proporcionara y lo mantuviera, ¿podría ser eso posible?

Podría estar equivocado, pero no creo que Vue permita que los complementos interfieran con su compilador.

@azamat-sharapov Por supuesto que no. Simplemente no pensé que se metería con el compilador de Vue: open_mouth:

@YerkoPalma Me encanta el operador de tuberías. ¡Lo uso obsesivamente en lenguajes funcionales y no veo la hora de tenerlo en JavaScript! _Pero_, imagina que Vue nunca hubiera tenido filtros. ¿Estaría solicitando que un marco frontend amplíe la sintaxis de JavaScript? Ese es el dominio de Babel o un lenguaje compilado a JS, no un marco de interfaz de usuario. Si prefiere usar un lenguaje como LiveScript, como hago a menudo, puede hacerlo. Pero el problema aquí no es con Vue. Es con JavaScript en sí mismo y no estamos aquí para arreglar eso.

Además, si podemos canalizar los resultados del renderizado en 2.0 a través de Babel como esperamos, incluso podrá usar el complemento rastreado sin TC39 si lo desea, de manera consistente, en todas partes en su JavaScript, en lugar de solo en la plantilla. Entonces, si solo quiere una pipa, es probable que pueda tenerla. Y _puede_ tenerlo hoy en 1.x; solo tenga en cuenta que es probable que la canalización que usaría en sus plantillas tenga una precedencia y un comportamiento diferentes a los de su Babel.

@smolinari y otros. Hay dos frases (y variaciones de las mismas) que sigo escuchando:

• "Piense en los desarrolladores / la perspectiva del usuario"
• "Piensa en principiantes"

Ambos implican una suposición: que _no_ estamos pensando en estos grupos.

He mencionado esto antes, pero supongo que necesita reiteración. _Todos_ en el equipo central son diseñadores, desarrolladores frontend o una combinación de ambos . Usamos estas herramientas todos los días para nuestro propio trabajo. También usaremos Vue 2.0. Créame, estamos pensando en eso. 😉

En cuanto a los principiantes, hice un caso aquí , pero supongo que entraré en más detalles. soy un educador Y yo era partidario de eliminar los filtros, _pensando en los principiantes_. Personalmente, he enseñado a cientos de personas, tal vez incluso a más de mil, cómo practicar el desarrollo web, generalmente desde cero. Sin experiencia previa en codificación. He hecho esto con estudiantes de secundaria, preparatoria, estudiantes universitarios, adultos profesionales y personas de la tercera edad.

Desde esa perspectiva, puedo decirles que si bien los filtros pueden parecer magia emocionante al principio, en última instancia, ralentizan el aprendizaje de un estudiante al introducir más complejidad para una comodidad limitada. Si nunca hubieran estado en Angular o Vue y esta conversación se invirtiera (tratábamos de _introducirlos_ en 2.0), tendríamos dificultades para explicar por qué eran necesarios y cuándo debería usarlos.

Antes de que se hablara de una desaprobación en 2.0, eliminé los filtros del plan de estudios en nuestra escuela de código, porque reunimos suficiente evidencia de que estaban haciendo más daño que bien a los principiantes. Preferimos que adquieran experiencia con funciones de Vue más versátiles, como métodos y propiedades calculadas. Incluso desaconsejamos el uso de filtros, porque facilitaban la detección de malas prácticas.

Espero que ponga estas dos quejas a la cama. Ya veremos. 😃

Pero imagina que Vue nunca hubiera tenido filtros. ¿Estaría solicitando que un marco frontend amplíe la sintaxis de JavaScript?

Por supuesto que lo haré, ya que los filtros son muy naturales para las _plantillas_ como en Twig, mencionado antes. Siento que tener un operador de tubería es tan natural como tener la sintaxis de bigote en las plantillas, quiero decir, los bigotes no son html, y no javascript, ¿ustedes también los van a eliminar? ¿Cuál es la diferencia con el operador de tuberías?

El argumento de "piensa en los niños" es simplemente tonto. Hasta donde yo sé, Vue no está diseñado para enseñar JavaScript, sino para que los desarrolladores front-end hagan cosas. Para estos últimos los filtros son geniales.

Si nunca hubieran estado en Angular o Vue y esta conversación se invirtiera (tratábamos de presentarlos en 2.0), tendríamos dificultades para explicar por qué eran necesarios y cuándo debería usarlos.

Estoy muy en desacuerdo. He estado usando un marco de Python llamado Django desde 2005 y su lenguaje de plantillas, que ha sido la inspiración para la mayoría de los lenguajes de plantillas nacidos más tarde, ha tenido filtros desde el primer día. Después de usarlos con desarrolladores front-end durante diez años, he llegado a apreciar su belleza y utilidad. Sería triste ver desaparecer esta sintaxis.

(Esto es lo que hace Django con los filtros: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference)

@Uninen , tenga cuidado con su tono: llamar tontos los argumentos de los demás no es una forma constructiva de participar en una discusión.

Para aquellos que dibujan analogías con los lenguajes de plantillas del lado del servidor, un aspecto importante a tener en cuenta es que los lenguajes de plantillas del lado del servidor no tienen la misma cantidad de flexibilidad que tienen las plantillas de Vue (sin propiedades calculadas, expresiones limitadas). Además, están diseñados para propósitos completamente diferentes: generar cadenas estáticas. Las plantillas de Vue son representaciones de DOM interactivo: hay enlaces bidireccionales, controladores de eventos, accesorios de componentes y más. Los filtros solo encajan en un caso de uso muy limitado en el contexto de Vue: hoy creo que es una mala idea permitir filtros en todas partes, por ejemplo, los filtros en v-model, v-for y v-on introducen más complejidad que bien.

Una posible alternativa es mantener los filtros, pero solo para interpolaciones de texto, es decir, solo puede usarlo dentro {{ }} s, no en directivas.

Como referencia interesante: Angular 2 todavía tiene filtros (rebautizados como "tuberías") pero también eliminaron intencionalmente la lista de filtros.

Perdón por mi lenguaje, no es mi intención insultar a nadie.

Para mí, el propósito de un marco _es_ hacer las cosas difíciles y hacer que parezca fácil para los desarrolladores que usan estas herramientas. Sigo argumentando que la sintaxis es insuperable y, de nuevo, sería triste verla desaparecer.

No sé ni entiendo gran parte de los mecanismos debajo del capó, pero desde el punto de vista de los usuarios, la practicidad supera la pureza :)

En una nota relacionada, ha sido interesante ver cuánta pasión parece haber en esta comunidad. Para mí, Vue ha sido una herramienta fresca y vigorizante, tal vez por eso tuve que participar en la pintura de este cobertizo en particular :)

Para otro punto de datos, Ember no tiene filtros ni permite métodos de componentes, aunque tiene propiedades calculadas.

Para el caso de uso de funciones puras que realizan transformaciones en la plantilla, debe registrar un asistente de manillar / asistente de ember.
http://emberjs.com/api/classes/Ember.Helper.html

Los ayudantes del manillar son sintácticamente distintos de las cosas que no son ayudantes del manillar, por eso lo menciono. Tienen eso en común con la sintaxis del filtro de tuberías. Sin embargo, las plantillas de manillar son "sin lógica", lo que significa que requieren una sintaxis especial para una llamada de función en la plantilla. Un problema que Vue no tiene.

Los filtros son simples para los principiantes, se ve algo de magia al usarlos para obtener una salida bonita o filtrar \ ordenar la búsqueda en matrices

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

y la facilidad lo define

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

es simple, claro en las plantillas, para 2.x defines filtros en el módulo externo y en las plantillas obtienes

import moment from 'moment'

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

y en plantilla

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

Como sugerencia, ¿por qué no dejar los filtros antiguos en la plantilla, pero mover los filtros en un módulo separado y usarlo desde la sección de métodos?

Así que si lo necesitas, hazlo

npm install vue-utils

y use filtros específicos del paquete utils

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

methods:{
   moment, price
}

y usar como filtro común

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

en resultado, se traducirá a una llamada de función simple

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

_Nota_
Para mí, los filtros se usan más para formatear datos, como fechas, números o cadenas . Para filtrar matrices\objetos, creo que es mejor usar el cálculo y la función del módulo vue común:

import _ from 'vue-utils/array'

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

Beneficios:
Los principiantes pueden usar filtros antiguos con facilidad, pero en computación y uso de funciones bonitas en sus plantillas para formatear la salida de datos y los programadores pueden escribir sus propios módulos de funciones y facilitar su uso.

_¿Por qué módulo separado?_
Creo que no es necesario que esté en el núcleo de Vue, pero Vue debe tener algunas utilidades para los desarrolladores, el diseñador de plantillas, por lo que no es necesario que todo el tiempo requiera lodash, momento o de lo contrario, simplemente instale las utilidades de npm y sea fácil de usar, pero guarde la sintaxis de llamadas anterior para plantillas.
Pero se debe hacer un pensamiento importante para los filtros, debe haber funciones puras, como getters en vuex.

Es fácil de soportar, fácil de usar, reutilizar, extender y tiene un buen aspecto en las plantillas.

Lo que necesitan es una ruta de actualización clara y el deseo de aprender a modularizar su código Javascript.

@thelinuxlich Hablamos de filtros.

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

solo azúcar de sintaxis para

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

Pero excluir completamente los filtros para principiantes en Vue\javascript es malo. ¿Por qué la comunidad de Laravel le gusta Vue? Porque es simple y poderoso.

Si eliminamos completamente los filtros, necesitamos dar una alternativa para _"Para los diseñadores de plantillas"_, no es necesario saber cómo ordenar la matriz o filtrarla, solo desea ingresar el ejemplo del formulario de código y obtener el resultado.

Los programadores deben saber cómo _modularizar_ el código Javascript, pero el resto de los que lo usan para cosas pequeñas no necesitan saberlo.

Si hablamos de _"Para los diseñadores de plantillas"_ solo se puede poner

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

y uso de código interno

Vue.use(VueUtils)

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

por ejemplo y orgullosos de sí mismos, no es necesario saber js para filtrar y ordenar matrices, mucha gente quiere hacer algunas cosas, pero hay un código difícil de entender 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)
  }
}

así que no hay necesidad de complicar las cosas para este tipo de personas, si podemos dar una solución simple para eso y sería bueno para los desarrolladores.

Una posible alternativa es mantener los filtros, pero solo para interpolaciones de texto, es decir, solo puede usarlo dentro de {{ }}, no en directivas.

Creo que esto podría ser un muy buen compromiso. Si bien no satisfará a todos, es para lo único que usé filtros y, de hecho, me parece extraño que actualmente puedan hacer más que eso.

Permitiría un formato de texto conveniente si desea usar filtros y reducir la complejidad eliminando efectivamente los filtros bidireccionales.

En mi opinión, su ejemplo de filtro momentjs ya está pasando demasiada lógica a las plantillas.

En serio, deberías dirigir todo este "amor por las tuberías" al repositorio de especificaciones hasta que llegue a TC39 :)

Me gusta lo que han sugerido tanto @yyx990803 como @VitaliyLavrenko . Ese podría ser un buen término medio.

scott

Me gusta la propuesta de @VitaliyLavrenko , pero cuando digo algo similar, sobre tener el operador de tubería en un complemento, @azamat-sharapov dijo que los complementos no deberían interferir con el compilador... Así que estoy confundido si es posible o si solo entendiste mal el comentario?

@thelinuxlich

¿Qué mejor para ti leer?

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

o

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

Piense como desarrollador y pregúntele a alguien que no sepa javascript.

Por mi parte, para _no desarrolladores_ mejor algo como esto:

Vue.use(VueUtils)

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

Es medio, y se usa como vue-resource solo lib común.

Acerca de la pipa, es azúcar de sintaxis

cosa en las cosas | filtroPor 'foo' | orderBy 'barra' | limite por 5

por

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

¿Qué facilidad para leer?

Si necesita pasar datos a 2 plantillas de diferencias, ¿almacena 2 o 3 modificaciones para un dato?

Si es algo como:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

Es una situación abstracta, pero ¿si se usa en una o dos plantillas? ¿Necesita almacenar datos para 10 o 100 objetos? ¿Aumentar el uso de la memoria? Sí, podemos usar el método de ayuda y usarlo en la plantilla, pero para _"Para los diseñadores de plantillas"_ que lejos de javascript es mejor algo como título | padLeft 10 y debería traducirse a llamada de función, es fácil y funcional.

Piense en personas diferentes, los desarrolladores pueden hacerlo fácilmente de manera diferente, pero otras personas quieren hacerlo simple.

Lo diré de nuevo, demasiada lógica en las plantillas es un antipatrón. En lugar de tener que aprender un DSL (filtros) específico, debe aprender Javascript.

@thelinuxlich Simplemente use JSX y obtendremos React con enlace bidireccional y algunas otras cosas.

Pero con Vue tenemos, gente que no sabe javascript, pero con google puede hacer algo y si no te gusta el pipe, no lo uses. Solo podemos agregar algo como

Vue.config.pipeFuncCall = true

Y puedes encenderlo/apagarlo, pero para algunas personas es fácil.

_Lo diré nuevamente, no solo los desarrolladores de JS pueden usar Vue, es el lado más fuerte de Vue._

Se necesitan filtros comunes estándar, pero es mejor que estén en lib separados y sean fáciles de agregar a vue y usar.

¿O quieres que Vue sea algo así como ASM y solo los buenos desarrolladores puedan usarlo?

Chicos, creo que la decisión que tomó el equipo central de Vue se ha explicado muy bien. ¿No podemos repetir lo mismo una y otra vez y comentar solo con algo nuevo, valioso, si lo hay?

Si es parte de los principios básicos de Vue ser más fácil para los desarrolladores que no son JS, incluso si daña los principios del lenguaje, entonces estaré de acuerdo con usted, pero probablemente no sea el caso.

Como dije antes, en general estoy de acuerdo con que los filtros estén en desuso, seguramente los extrañaré por su conveniencia, pero estoy más que seguro de que se puede introducir un sistema de filtro muy similar como complemento.

He dado un ejemplo de prueba de concepto un poco antes, que podría usarse en accesorios computados, así como en línea

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

Por otro lado, si alguien quiere la pipa, seguro que se puede hacer, con algo así

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

O tal vez, si hubiera un enlace que permitiera a los complementos analizar expresiones y procesarlas como quisieran, esa también podría ser una forma posible, pero eso depende únicamente de cuán complejo sea implementarlo y qué efectos tendría. en el marco (rendimiento / tamaño), y si @ yyx990803 realmente querría ir en esta dirección o no.

Siento que, si nos dan alternativas elegantes, que sean fáciles de usar (complementos o algo en el núcleo), nos acostumbraremos con bastante rapidez.

@ rigor789 para filtrar matrices y ordenarlas, etc., mejor uso computado, es mucho más limpio. Pero creo que es un problema mostrar datos en formato diff:

si tenemos el campo created_at y necesitamos en la plantilla, renderícelo como dd.mm.YYYY o en enlaces

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

para estos filtros usados ​​bien ahora, ¿qué alternativa podemos obtener de 2.x?

Por ahora solo uso

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

y defina el método de fecha, pero ensucia la plantilla, si almacena 3 campos adicionales, cuesta memoria, y si tiene 100-200 objetos, se vuelve pesado.

Aquí está la decisión final:

1. Los filtros serán compatibles, pero solo dentro de las interpolaciones de texto. Esto los limita a propósitos de formato de texto mientras aplica otra lógica en la tierra de JavaScript.
2. Vue 2.0 se enviará sin filtros incorporados. La comunidad puede crear sus propios paquetes de filtros si es necesario.
3. La sintaxis del filtro cambiará para usar la sintaxis de invocación de funciones para los argumentos en lugar de la delimitación por espacios. Esto lo pone más en línea con JavaScript y otros lenguajes de plantillas populares (Jinja2, swig, twig...):

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

Gracias por escuchar Evan. Eso es lo que hace que Vue sea genial. Tiene un gran líder. :sonrisa:

scott

@yyx990803 y @chrisvfritz

Una cosa que parece haber quedado enterrada en esta discusión son los filtros bidireccionales. Los filtros bidireccionales son los más difíciles de replicar con otras soluciones propuestas.

1. Considere este ejemplo simple , que publiqué en ese hilo del foro. El uso de propiedades calculadas para esto tendría 2 inconvenientes principales:
   
   
   
   1. Tendrá que crear una nueva propiedad calculada para cada valor, lo que dará como resultado una tonelada de código repetitivo.
   
   
   2. Para empeorar las cosas, las propiedades calculadas ni siquiera se pueden anidar . Si tiene un gráfico de objeto más complejo, todas sus propiedades calculadas deberán estar en el nivel superior. Terminaría con nombres de propiedad largos y detallados que requieren más sobrecarga cognitiva para realizar un seguimiento constante de qué propiedad calculada rastrea qué valor anidado.
   
   

Descartar este caso de uso como "trivial" o "menos complicado" es contraproducente. Lo he usado en aplicaciones de mediana y gran escala. ¡Ha funcionado de maravilla! La demostración es necesariamente simple, pero la técnica es sólida.

1. Esto se confunde aún más cuando se trata de una matriz en v-for , como en este ejemplo (nuevamente, intencionalmente simple). Al iterar sobre una matriz, no encontrará ningún recurso en las propiedades calculadas. La única forma de evitar esto es tener un componente separado para cada elemento de la matriz, agregando aún más repetitivo.

Compare este ejemplo con filtros:

``` js
importar moneda de 'algún filtro de moneda';
importar productos de 'products-stub';

nuevo Vue({
el: documento.cuerpo,
datos: { productos },
filtros: { moneda },
});
```

A uno sin filtros:

``` js
importar moneda de 'algún filtro de moneda';
importar productos de 'products-stub';

nuevo Vue({
el: documento.cuerpo,
datos: { productos },
componentes: {
producto: {
accesorios: ['producto'],
calculado: {
precio: {
obtener() {
return moneda.leer(este.producto.precio);
},
valor ajustado) {
este.producto.precio = moneda.escribir(valor)
}
},
Envío: {
obtener() {
return currency.read(this.product.shipping);
},
valor ajustado) {
este.producto.envío = moneda.escribir(valor)
}
},
manejo: {
obtener() {
return currency.read(this.product.handling);
},
valor ajustado) {
este.producto.manejo = moneda.escribir(valor)
}
},
descuento: {
obtener() {
return moneda.leer(este.producto.descuento);
},
valor ajustado) {
este.producto.descuento = moneda.escribir(valor)
}
}
}
}
}
});
```

Sé cuál de los anteriores me gustaría escribir.

_{(esto podría limpiarse un poco creando fábricas de propiedades computarizadas, pero el punto es que son mucho más detallados de lo necesario)}

Dado que el equipo central parece firmemente opuesto a la sintaxis de la tubería de filtro, ¿sería posible introducir un parámetro filter para la directiva v-model ?

Con un parámetro filter podremos mantener la primera versión elegante del JS anterior y simplemente reescribir la plantilla para usar el parámetro en lugar de la sintaxis de canalización mágica:

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

Esto lograría el equilibrio correcto de no tener una sintaxis mágica y al mismo tiempo conservar la capacidad de convertir fácilmente la entrada de un lado a otro sin mucho repetitivo.

Gracias por tu consideración.

Reescribí su ejemplo para incorporar su filtro como una directiva personalizada: jsfiddle .
Aunque no es tan conciso como un filtro, no es tan doloroso como imaginaba que sería. Y no me ha llevado mucho tiempo juntar las piezas con cosas que ya están disponibles para todos nosotros.

@Nirazul se ha propuesto crear directivas dedicadas para cada filtro antes . Necesitar crear una nueva directiva que vuelva a implementar toda la funcionalidad v-model para cada tipo de filtro que usa en su aplicación es simplemente absurdo.

Además, su directiva ni siquiera funciona completamente como filtros; desenfocar el campo después de cambiar el valor no lo vuelve a formatear. Además, v-model hace mucho más de lo que hace en esa directiva.

Obviamente, la directiva se puede modificar con más características y correcciones, pero el punto permanece: todas estas son curitas además de algo que debería ser realmente simple desde el primer momento.

No he visto ninguna propuesta en este hilo que mencione directivas personalizadas. ¿Podría señalarme este comentario?

Como puede imaginar, no lo he escrito ni probado para que lo use en su aplicación. Solo quería mostrar lo que es posible en este momento como una alternativa. Si esto es posible tan fácilmente, tal vez haya espacio para un complemento para automatizar el proceso aún más.
Es obvio que esta directiva escrita rápidamente carece de la funcionalidad completa de v-model. Tal vez una directiva de filtro personalizada combinada con parámetros y/o modificadores sería suficiente para reemplazar los filtros.

Sigamos siendo constructivos, como lo he intentado para resolver su problema. Siempre es más fácil criticar una solución en lugar de hacer una contribución y seguir adelante.

@JosephSilber necesitas relajarte. "absurdo" es una palabra fuerte.

Hola, ¿la eliminación del filtro está motivada por reducir el desorden de plantillas o está afectando seriamente
la implementación técnica de 2.0? Si se trata de un problema de efectos visuales anteriores, ¿qué tal si permitimos
filtrar como ahora (pero con el nuevo formulario javascript)
pero limitándolo solo para uno por expresión, como v-for="i of list | orderBy('key')", (no más de un signo de canalización)
esto podría hacer que el procesamiento de filtros en 2.0 sea más simple y predecible y visualmente menos desordenado.
Dado que habrá análisis de filtro para {{}}, permitirlo en otras expresiones tendría sentido.
esto acomodaría todos los casos de uso/funciones existentes (como filtrado bidireccional, elemento dentro de v-for).
Cualquier uso existente de más de un filtro podría fusionarse/actualizarse fácilmente en uno por parte de los propietarios.

@tomsmithgroup Se ha decidido que lo que ha sugerido (y más que eso) seguirá siendo compatible en 2.0.

A @yyx990803 y @chrisvfritz les encantaría conocer su opinión sobre los filtros bidireccionales .

@JosephSilber Entonces, con la fábrica de propiedades computarizadas a la que aludió, ni siquiera hay mucho repetitivo:

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

Aunque personalmente, no crearía una fábrica para este ejemplo, porque cada una de estas propiedades son en realidad preocupaciones separadas que solo _parecen_ iguales en este momento. Cuando elimina los filtros, se vuelve mucho más obvio cuán complejo era ese componente. Eso es lo que estás viendo como repetitivo.

Y esta es una gran razón por la cual los componentes _existen_. Dividir la complejidad en preocupaciones manejables. Cuando miro un componente, todo lo que está haciendo debe encajar fácilmente en mi memoria de trabajo o, de lo contrario, el desarrollo se vuelve mucho más lento y más propenso a errores. Ocultar la complejidad detrás de la sintaxis de los filtros no elimina esa complejidad.

Para demostrar esto, veamos qué sucede cuando el problema cumple con los requisitos cambiantes del mundo real: supongamos que decide que no se debe permitir que el descuento sea mayor que el precio + envío + manejo. O el manejo no debe exceder X cantidad. O el campo de descuento debe ser un porcentaje, en lugar de una moneda. O si el total supera una cierta cantidad, se debe aplicar automáticamente un descuento mínimo.

Puede sentirse tentado a hacer que el filtro sea más complejo con opciones adicionales y lógica condicional. A medida que actualice la API y la lógica interna del filtro, ahora debe pensar en cómo sus cambios podrían afectar cualquier otra cosa que consuma el filtro, posiblemente incluso fuera del componente actual, si se trata de un filtro compartido. Entonces, ahora se encuentra en una situación en la que hacer cambios en su aplicación comienza a ser desalentador. Y todo se debe a que un filtro compartido de dos le ha permitido delegar el estado del componente interno fuera del componente, violando los límites del componente, aumentando el acoplamiento y ocultando la complejidad en la que aún debe pensar cada vez que trabaja en el componente.

Al dividir las cosas en múltiples componentes individualmente menos complejos, con propiedades calculadas definidas por separado o accesorios enlazados, a menudo actualiza una línea para ajustarse a un requisito cambiante. Sin opciones adicionales ni condicionales. Sin refactorización para satisfacer la complejidad de escalado. No tiene que pensar en nada fuera del componente _o incluso fuera de esa única propiedad_. Su aplicación fue desde el principio y sigue siendo fácil de pensar y actualizar.

Creo que lo que hace que los filtros sean inicialmente seductores en este caso es que son una cura fácil de alcanzar para la duplicación. Pero la duplicación no es repetitiva cuando es incidental (es decir, el código resulta ser el mismo en este momento, antes de que los problemas del mundo real inevitablemente comiencen a aparecer).

Y no puedo decirlo mejor que Sandi Metz:

la duplicación es mucho más barata que la abstracción incorrecta

@chrisvfritz Los filtros no tienen absolutamente nada que ver con los requisitos comerciales. Los filtros solo dan formato a los datos. Eso es. No lo manipulan de ninguna manera, forma o forma. filter="currency" es conceptualmente lo mismo que el number . Obviamente, los requisitos comerciales nunca deben manejarse en los filtros.

Supongamos que decide que no se debe permitir que el descuento sea mayor que el precio + envío + manejo. O el manejo no debe exceder X cantidad.

Entonces usaría algún módulo de validación adecuado, a la vue-validator . El filtro de moneda permanecerá en su lugar independientemente, simplemente mostrando el valor subyacente.

el campo de descuento debe ser un porcentaje, en lugar de una moneda.

Entonces obviamente su tipo ya no es moneda. No es diferente a si cambia type="text" por type="email" cuando cambian los requisitos del nombre de usuario. O incluso cuando elimina el parámetro number cuando un campo ya no es un número.

si el total supera una cierta cantidad, se debe aplicar automáticamente un descuento mínimo.

Nuevamente, se aplicará el mínimo, pero el filtro de moneda permanecerá en su lugar. Todavía querrá mostrarlo como moneda.

A medida que actualiza la API del filtro y la lógica interna, ahora debe pensar en cómo sus cambios podrían afectar cualquier otra cosa que consuma el filtro [...] dos filtros le han permitido delegar el estado del componente interno fuera del componente

No. Usted _nunca_ pone ninguna lógica o estado en el filtro mismo. El filtro es una función idempotente estrictamente para formatear valores. Idealmente, ni siquiera debería ejecutarse en el contexto de la VM ; no debería tener this de donde extraer datos adicionales.

la duplicación es mucho más barata que la abstracción incorrecta

... cuando, como dijiste, estás abstrayendo código que resulta ser el mismo en este momento. Los filtros, por otro lado, son funciones idempotentes simples que dan formato a un valor. No son una abstracción en absoluto.

Los filtros tl;dr no son una abstracción y no reemplazan un requisito comercial explícito. Los filtros nunca tienen una lógica interna, y nunca deberían hacerlo. Son conceptualmente similares al atributo type de HTML y al parámetro v-model de number .

El filtro bidireccional es ciertamente una abstracción. El comportamiento actual de los filtros bidireccionales en v-model esconde mucha magia en su interior; específicamente, permite que el valor DOM de la entrada no esté sincronizado temporalmente con el modelo subyacente, y solo los "sincroniza" cuando difuminar el campo. Por cierto, @JosephSilber, este comportamiento se implementó específicamente debido a su solicitud, por lo que puedo entender por qué se siente tan convencido al respecto.

Sin embargo, el mayor problema que veo con los filtros bidireccionales es que la lógica subyacente es una caja negra, y el usuario no tiene forma de personalizarla más que solicitar funciones. Para mí, la mejor opción es proporcionar los componentes básicos adecuados para implementar ese comportamiento usted mismo. Y déjame mostrarte cómo eso es posible en 2.0:

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

Aquí tenemos un componente base CustomInput que implementa el comportamiento "fuera de sincronización hasta que se desenfoque" de los filtros bidireccionales actuales. Debido a los cambios en 2.0, puede usar v-model directamente en componentes personalizados, siempre que el componente acepte un apoyo de value y $emita eventos de input . Además, también formatea el valor de los eventos change , lo que actualmente no es posible con los filtros bidireccionales . Puede modificar aún más este componente para obtener el comportamiento deseado sin estar atado a cómo el marco implementa los filtros bidireccionales.

El componente base no implementa la lógica de análisis/formato: lo amplía con los métodos parse y format para obtener componentes de entrada personalizados adaptados a casos de uso específicos. En este caso, un componente CurrencyInput .

El componente base es más complejo que los filtros de dos vías, porque ahora nosotros mismos estamos implementando el comportamiento mágico anterior. Sin embargo, solo necesita definir este componente una vez. A cambio, obtienes control total sobre cómo debería comportarse en caso de que quieras cambiarlo más tarde. Creo que este es un intercambio digno.

Este es un ejemplo de cómo debemos pensar más en los componentes porque es una abstracción unificada para la reutilización que le brinda el mayor control. Vea también el ejemplo de 2.0 v-model .

Para mí, la mejor opción es proporcionar los componentes básicos adecuados para implementar ese comportamiento usted mismo.

Esto es genial y definitivamente lo que Vue necesita, sin embargo, me hubiera gustado leer esto.

Para mí, la mejor opción es proporcionar los componentes básicos adecuados para comenzar con Vue y también para ampliar Vue con un nuevo comportamiento de filtrado.

En otras palabras, ¿no podrían ser parte de Vue el componente de entrada de moneda junto con una serie de otros componentes de filtrado predeterminados? Porque todos usan monedas en algún momento, ¿verdad? ¿Por qué dejar que los demás hagan el mismo trabajo una y otra vez? El formato de moneda es lo suficientemente estándar como para que forme parte de la bolsa de herramientas de componentes de filtrado de Vue y son un excelente ejemplo básico para que otros también aprendan a crear sus propios componentes de filtrado.

Y ... solo falta una cosa en el ejemplo para ser un componente de entrada de moneda terminado y esa es una función i18n, que creo que Vue también debería incluir. El formato del número de moneda debe cambiar según la configuración regional seleccionada por la persona (el espectador). Me refiero a los datos locales, es decir. "DE_de" para formatear la moneda y otros números como se muestra en este Locale Explorer (que proviene de un estándar). Agregue eso a Vue y tendrá un excelente sistema de componentes de formato de moneda/número integrado directamente en Vue, que los miles de otros desarrolladores que usan Vue no necesitan crearse ellos mismos, sino que pueden usarlo en el acto, cuando obtienen Vue. . ¡Esto convierte a Vue en un poderoso sistema de plantillas!

Si el uso de este "componente de formato i18n" no se puede usar de forma encadenable como un filtro como en 1.0, debería ser conectable. Eso también estaría bien. Eso es lo que está haciendo Aurelia y también lo hace Twig con sus extensiones . El componente de entrada de moneda aún podría ser <currency-input> .

Este i18n y otros filtros de plantilla estándar realmente necesitan ser algo que otros no necesiten reproducir constantemente, si no es necesario. Si me muestra cómo hacer un complemento de este tipo, incluso haría el complemento i18n por usted. ¡Estoy tan interesado en esto como un todo! :smile:

scott

Porque todos usan monedas en algún momento, ¿verdad?

No, realmente no. Yo, por mi parte, nunca lo he usado realmente :) Lo mismo se aplicaría a todos los demás filtros incorporados: algunos de ellos son útiles para algunos de nosotros, mientras que otros son simplemente inútiles. Mientras estamos en este tema, la mayoría de las veces que quería usar un filtro integrado, terminé escribiendo mi propia versión de todos modos, haciendo que la versión integrada fuera un código muerto.

una función i18n, que creo que Vue también debería incluir.

Esto es, de nuevo, muy discutible. Un soporte completo de i18n puede ser bastante complejo, y IMO no pertenece a Vue, especialmente cuando la mayoría de los usuarios no lo necesitarán de todos modos.

Ahora, me gustaría plantear esto: cada vez que intentamos hacer una comparación entre Vue y otra plantilla/marco, hay algo fundamental a tener en cuenta: a diferencia de Django/Laravel/Twig, Vue es esencialmente una biblioteca cliente y, por lo tanto, tiene que ser lo más ligero posible. Tendría más sentido mantenerlo lo suficientemente simple, conservando todas las funciones _principales, por supuesto, en lugar de agregar "características" y "utilidades" solo por el bien de la llamada "utilidad" o "elegancia". Si desea algo más que funciones básicas, la forma más preferida sería usar un complemento o incluso desarrollar el suyo propio. Tome esto como un ejemplo: para un SPA comúnmente visto, ¿i18n/currency es más vital que un enrutador o un administrador de estado? No lo creo. Y, sin embargo, vue-router y vuex no pertenecen a Vue, pero tienen sus propios repositorios. En otras palabras, Vue es progresivo .

Si me muestra cómo hacer un complemento de este tipo, incluso haría el complemento i18n por usted. ¡Estoy tan interesado en esto en su conjunto!

Creo que este es un enfoque más sensato, y gracias por su interés :)

si mucho necesitará usar i18n en algunas áreas)) Creo que puedo ingresar al código y cambiar manualmente algunos nombres de algunas cosas, por belleza.
Por ejemplo: hace solo unas horas, me tomó butstrap.datepikker: no me conecto, i18n a pesar de que existe tal posibilidad. Rápido 60 segundos. "Manualmente" reemplazó los nombres de los días de la semana y los meses, y todo, ¡está bien! ))

@phanan : su argumentación es la razón por la que mencioné "complementos". Estoy de acuerdo, no todos querrán la moneda o la funcionalidad i18n y aquellos que no quieran pueden mantener su aplicación liviana, pero como sistema de plantillas, creo (y esta es en gran medida mi opinión personal) Vue también debería tener esa funcionalidad estándar disponible. también. Más importante aún, y mi preocupación, es que no debería ser que todos tengan que reinventar las ruedas de componentes del filtro i18n o de moneda. En otras palabras, al igual que Vue-Router y Vuex son adiciones disponibles para Vue, una buena cantidad de filtros estándar como moneda e i18n también podrían serlo.

Ah, y curiosamente, Angular tiene i18n incorporado al parecer.

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

Angular admite i18n/l10n para filtros de fecha, número y moneda.

Ember y React parecen haber tomado la ruta de "dejar que el mundo de desarrollo lo haga por su cuenta".
video interesante
https://www.youtube.com/watch?v=Sla-DkvmIHY

¿Quizás Vue solo necesita una integración con FormatJS? VueIntl? :sonrisa:

Editar: No puede ser tan simple, ¿verdad? https://github.com/learningequality/vue-intl/blob/master/index.js

scott

Parece que Angular tiene i18n incorporado.

Angular también viene con ng-router que, por lo que he escuchado, es rechazado por ng-community a favor de ui-router.

Ahora, si el equipo Angular reemplaza ng-router con ui-router, resultará en cambios importantes y dolor.

si intentan mejorar ng-router, están perdiendo el tiempo porque ya existe una mejor solución (ui-router).

Si Vue comenzó a admitir i18n, moneda, etc. en su núcleo, la misma situación también le sucederá a vue.

Encuentro convenientes los filtros incorporados, pero en este asunto estoy de acuerdo con el equipo de vuejs.

Entonces todos estamos de acuerdo en que los filtros no están en el núcleo de Vue. También soy un fanático de la creación de componentes en realidad. Pero, ¿no podría Vue ofrecer los filtros como complementos principales también? ¿Te gusta Vuex y Vue-Router?

scott

Pero, ¿no podría Vue ofrecer los filtros como complementos principales también? ¿Te gusta Vuex y Vue-Router?

Eso es exactamente lo que @blake-newman compartió antes.

Hola: la página de decisión final indica que solo permite el filtro de texto
mostrar {{}} (texto v)
no para otras expresiones como v-for="item of list | sortBy"
¿O entendí mal?
Lo que quise decir fue mantener el filtro como en 1.0 pero limitando solo un filtro
por expresión

El domingo 1 de mayo de 2016 a las 22:24, Phan An [email protected] escribió:

@tomsmithgroup https://github.com/tomsmithgroup Lo que has sugerido
(y más que eso) han sido decididos
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 para
siguen siendo compatibles en 2.0.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment-216093937

@ yyx990803 ¿ Puedo concluir de su respuesta que los filtros bidireccionales no serán compatibles con 2.0?

@fnlctrl eso es correcto. Simplemente construya sus propios componentes.

Me desviaré un poco del tema: ¿esos filtros bidireccionales son realmente tan útiles en la producción?
Quiero decir, ¿está realmente bien dejar que el usuario escriba cualquier cosa en una entrada y luego reformatearlo después de que esté borroso?
Mi equipo de negocios siempre exige nuestras entradas para actuar así : simplemente no puedes escribir nada mal. Entonces, incluso ahora con Vue , usamos jquery.inputmask para ese propósito, ya que el cambio bidireccional instantáneo quedó obsoleto (ese que realmente extraño...)
Quiero decir, ¿hay realmente un problema con esos filtros bidireccionales o la gente simplemente lo piensa demasiado? :)

@fullfs Los filtros bidireccionales se utilizan ampliamente en nuestra aplicación de producción (muchos <input> s) por conveniencia, pero tal como lo veo ahora, ¿por qué filtrar los valores en tiempo real en lugar de filtrarlos una vez antes de que sean POST-ed al servidor? Tomará algún tiempo refactorizar el código, pero creo que no los extrañaré: D

Si desea una actualización optimista de la interfaz de usuario (que es la norma hoy en día, en mi humilde opinión, especialmente para dispositivos móviles), querrá que la entrada se formatee correctamente prácticamente en el momento en que se proporcionó la entrada.

scott

Los filtros de 2 vías son realmente agradables en vue. Siempre puede crear sus propios componentes personalizados, con o sin filtros disponibles, pero eso lleva tiempo. La biblioteca debe proporcionar flexibilidad pero también una forma más rápida y conveniente de hacer las cosas. La inclusión de filtros bidireccionales no impediría que las personas construyeran sus propios componentes si es necesario, pero permitiría un desarrollo más rápido cuando la funcionalidad existente se ajuste a las necesidades, que es la mayor parte del tiempo. Siempre es un compromiso entre la superficie API y la conveniencia. Hay que encontrar el equilibrio, y Vue ya tenía uno excelente. Deshacerse de los filtros parece ser un paso atrás desde el punto correcto de equilibrio. La biblioteca se vuelve más pequeña, pero la base de código y el modelo de todos los proyectos que la usan crecen.

Si los filtros realmente van a ser obsoletos, tal vez sería bueno proporcionar una alternativa capaz de especificar un analizador y formateadores para las directivas de v-model, de una manera fácil. Con los filtros, puede escribir solo esta parte del ejemplo proporcionado por @yyx990803 :

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

Sin filtros de 2 vías uno también tiene que escribir

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

Entonces, más flexibilidad, pero también más código para el mismo resultado.

@aristidesfl : los filtros no están en desuso. Ganamos la batalla, parcialmente. ¡JAJAJA! Se limitarán a usarse solo en interpolaciones de texto. Ver aquí: https://github.com/vuejs/vue/issues/2873

scott

Gracias @smolinari . Sin embargo, me refería particularmente a los filtros de 2 vías.

¡por favor regrese! lo necesitamos, estoy de acuerdo con todo lo que dijiste. pero es tan fácil, somos usuarios perezosos, solo queremos una manera fácil y perezosa. al igual que mantener vivo.

Puede haber una forma de agregar modificadores de modelo v personalizados (http://rc.vuejs.org/guide/forms.html#Modifiers)

Funcionan como filtros de dos vías.

@ecmel estuvo de acuerdo. Este es el camino a seguir.

Abra un problema de solicitud de función entonces :)

@ecmel se discutió aquí una idea similar, aunque descrita como modificadores de tipo.

@rpkilby Esa discusión también está cerrada, tal vez deberíamos abrir una nueva para modificadores personalizados de modelos en V.

Ya no puedo hacer esto:

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

Limitar los filtros a {{ }} parece extraño, hay muchas veces en las que querrás usar un filtro en un enlace de atributo (sin pasar una propiedad) y ya no podemos usar {{ }} en los atributos. !

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

Limitar los filtros a {{ }} parece extraño, hay muchas veces en las que querrás usar un filtro en un enlace de atributos (sin pasar una propiedad) y ya no podemos usar {{ }} en los atributos. !

Se eliminaron porque pueden reemplazarse fácilmente por propiedades y métodos computados, mientras que ellos mismos tienen una API más limitada y no tienen posibilidad de almacenar en caché los resultados.

Entonces:

• una API menos
• use los mismos métodos en la plantilla y el código JS, no es necesario duplicar el comportamiento del filtro para usarlo en el código de la aplicación.
• los accesorios computados se pueden almacenar en caché
• más flexibilidad porque es solo JS

pseudocódigo por delante:

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

Lo siento, solo soy "nuevo".
Pero viniendo de Angular 1, no tener filtros se siente realmente extraño y contrario a la intuición, ¿por qué sería mejor que cada desarrollador desarrolle su propio conjunto de filtros y configure las entradas computadas, etc., mejor que tenerlo incorporado?
Y lo que ahora se considera la mejor práctica para filtrar una matriz realmente grande, por objetos en el elemento. Con angular, esto era solo una línea de código. Era posible filtrar una matriz para una entrada de búsqueda y haría toda la magia, que debería ser la función de un marco.

Y lo que ahora se considera la mejor práctica para filtrar una matriz realmente grande

¿Qué es una matriz realmente grande? En teoría, una propiedad calculada también sería buena para filtrar.

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

¿Por qué sería mejor que cada desarrollador desarrollara su propio conjunto de filtros y configurar las entradas calculadas, etc. mejor que tenerlo integrado?

Solía ​​​​pensar de la misma manera (y por qué comencé el hilo), pero desde que aprendí que es básicamente pan comido crear este tipo de filtros por su cuenta, y que hay tantas cosas que cada desarrollador podría querer. como filtro (o propiedad calculada), me di cuenta de que no es tan importante no tener filtros incorporados.

scott

En mi caso, equivale a> 10.000 líneas en json proporcionadas por una base de datos de firebase.
Veo por qué podría pensar de esa manera y decidir abandonar la función, sin embargo, es una molestia adicional para los desarrolladores.

Bifurqué el violín para estar en línea con mi estructura de datos:
https://jsfiddle.net/nw5yhLwv/
Entonces, ¿necesito codificar la búsqueda de una cadena en mi objeto a mano?

no entiendo tu pregunta Lo siento. El violín se parece al que publiqué.

scott

Calculado vs. filtros

Los filtros son posiblemente malos para el rendimiento, ya que se calculan para cada procesamiento (al igual que los métodos) y las propiedades calculadas son fáciles de hacer, y solo se vuelven a calcular cuando es necesario; de lo contrario, los resultados se almacenan en caché, lo que significa que Vue puede volar.

Oh. y tenemos los dos. 😄

scott

Oye, hice algunos cambios y ahora lo entiendo, ¡es un gran concepto! 😄

Cerraré este hilo ahora, ya que la discusión sobre esto terminó hace mucho tiempo: Vue 2.0 ha estado fuera durante un par de meses y las críticas sobre la caída de los filtros han disminuido en gran medida.

La discusión adicional en este hilo no es productiva. Si ve un nuevo ángulo del tema que cree que necesita discusión, abra una nueva edición.