Vue: [Предложение] Vue 2.0 - верните фильтры, пожалуйста

Уточнение момента, который первоначально пришел из чата Gitter: debounce — это не фильтр, а просто еще одно изменение версии 2.0, от потери которого люди не были в восторге.

Исправление предоставлено @JosephSilber : debounce — это и фильтр, и параметр v-model .

Спасибо @agc93. Я убрал этот пункт.

Скотт

В худшем случае мы придумаем крошечные плагины, чтобы справиться с этим. Про фильтры тут https://www.npmjs.com/package/babel-plugin-pipe-operator
Проблема в том, что это не будет работать без компиляции babel.

Я тоже не в восторге от некоторых изменений. Для фильтров есть простая альтернатива регистрации глобальных миксинов . Однако мне не очень нравится идея загрязнять область видимости методов всех моих компонентов сверхпростыми задачами, такими как множественное число и так далее. Однако я никогда не использовал двусторонние фильтры.

Фильтры были просто удобны и красивы. Две вещи, которые vue всегда делал правильно (пока).

Когда я прочитал пост о vue 2.0, я был в восторге от всех новых возможностей (особенно виртуальный дом и серверный рендеринг), но также был удивлен и немного опечален тем, что фильтров больше нет.

Они были одной из моих любимых частей vue не только потому, что их было легко использовать и связывать, но главным образом потому, что они были легко расширяемы и имели красивый синтаксис для непосредственного использования в шаблоне. Особенно в сочетании с петлями v-for они были идеальной парой.

Думая, что мне придется использовать вычисляемые свойства, чтобы заменить фильтрацию для каждого свойства, которое я хочу, я беспокоюсь, что в будущем мне придется писать много шаблонов. Хотя примеси могут смягчить часть проблемы, я все еще чувствую, что часть элегантности и простоты использования vue будет отсутствовать.

Все, кто с этим согласен, можете поставить палец вверх под описанием? это лучше, чем спамить 17 тысяч человек +1 . Еще лучше, придумайте несколько осмысленных вариантов использования.

Я никогда не использовал двусторонние фильтры, но мне бы их очень не хватало! Я могу (и иногда использую) использовать вычисляемые свойства, но в некоторых простых случаях это удобство, которое действительно ускоряет рабочий процесс.

Рассмотрим этот очень простой пример

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

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

Вышеприведенное намного проще написать в тех случаях, когда не требуется более сложная фильтрация.

Теперь сравните его со следующим

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

Я не говорю, что вторую сложно написать, но когда вы будете использовать ее во многих местах, вы начнете повторяться, и это займет некоторое дополнительное время, которое вы, возможно, могли бы использовать для некоторых других, более полезных функций!

В любом случае я останусь счастливым пользователем Vue, просто поделившись своим мнением о устаревших фильтрах!

Фильтры многоразовые. Я могу создать функцию для форматирования моих данных один раз, зарегистрировать ее как фильтр и просто использовать из всех экземпляров. Как мне это сделать в 2.0?

Как мне это сделать в 2.0?

• Миксин
• Отдельный модуль с методом
• Отдельный модуль с вычисляемой опорной функцией

Я только что оставил комментарий в ветке объявлений, поэтому вместо того, чтобы дублировать все это здесь, я просто дам на него ссылку:

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

Я полностью понимаю чувство, когда у тебя отнимают что-то очень удобное. Но сначала, пожалуйста, найдите минутку, чтобы прочитать комментарий @chrisvfritz в ветке форума выше. Чтобы упростить обсуждение, я просто скопирую это сюда:

@theotherzach Спасибо за вашу страсть к Vue! Я хотел бы немного лучше объяснить устаревание, но сначала я должен представиться. Я являюсь членом основной команды Vue, я все время использую Vue для внештатной работы с пользовательским интерфейсом и визуализацией данных, а также являюсь преподавателем, который учит людей использовать Vue и Rails среди других веб-технологий. У меня есть школа кодирования, поэтому я помогаю людям научиться использовать эти инструменты (и использовать их вместе) почти _каждый день_.

Я также был одним из ярых сторонников удаления фильтров в Vue 2.0.

Проблема с фильтрами для новичков во Vue

Большая часть причины, по которой я выступал за устаревшие фильтры, была на самом деле _для_ начинающих. При работе со студентами не раз возникал такой разговор:

• Ученик: «Значит, фильтр — это, по сути, функция?»
• Наставник: «Да!»
• Ученик: «Хорошо, так что я могу использовать его нормально с функциональными круглыми скобками?»
• Наставник: «Ну, нет. Это особый вид функции».
• Ученик: «Могу ли я использовать его в других местах? Например, в вычисляемом значении?»
• Наставник: «Нет, вы можете использовать его только в шаблонах и только со специальным синтаксисом канала».
• Ученик: "...почему?"

Одна из важных вещей, которая сбивает с толку новичков, — это _исключения_. Фильтры — это просто функции, за исключением того, что они требуют специального синтаксиса и не могут использоваться повсеместно. И они используют синтаксис канала, который отличается от синтаксиса канала, который может быть интегрирован в ES7 , а это означает, что скоро у людей появятся два очень похожих оператора, чтобы делать что-то очень похожее, но они не совсем одинаковы. И только один из них на самом деле является JavaScript.

Библиотеки Util _являются_ полезными, но Vue не является одной из них

В случае с filterBy преобразованиями для строк и чисел и другими специфическими фильтрами да, они полезны в приложениях, где они возникают. Библиотеки Util в целом полезны. И есть десятки отличных библиотек на выбор, но Vue не является служебной библиотекой. И, честно говоря, ни одна из предложенных нами утилит не была лучшей в своем классе.

Обработка валют, дат или даже фильтрация массивов — это не наша задача. Многим приложениям они не требуются, и большинство приложений, над которыми я работал, _делают_ сталкиваются с этими проблемами, требуют более надежного решения, чем предлагает Vue в настоящее время (или _могло бы_ предложить без существенного раздувания и переизобретения колеса).

В моих приложениях Accounting.js превосходно обрабатывал валюту, Moment.js (как вы упомянули) обрабатывает даты и время, pluralize не очень хорошо обрабатывает множественные формы, поэтому обычное вычисляемое значение часто более желательно, и json чуть больше, чем JSON.stringify .

Преимущества вычисляемых свойств

Использование вычисляемых свойств вместо фильтров также дает то преимущество, что обработанное значение можно легко повторно использовать СУХИМ способом _где угодно_ в компоненте. Мне постоянно приходится делать это в своих приложениях. Вычисляемое свойство также перемещает больше деталей реализации из шаблона, оставляя только четкое описание того, что делает компонент. Преимущество по сравнению с глобально определенными фильтрами состоит в том, что достаточно посмотреть на функцию для этого компьютерного значения, чтобы точно увидеть и настроить, как она работает. В массивах объединение методов JavaScript map и filter даже обеспечивает тот же линейный список обработки, что и конвейеры, но в еще более декларативном и легко управляемом виде.

Полезность глобально определенного чего бы то ни было

Если вам нужно определить функцию или что-то еще, что вы хотите сделать доступным во всех ваших компонентах, Vue.prototype.whateverIWant = mySuperCoolFunction — отличный способ сделать это. Лично я никогда не _хотел_ этого делать. Я всегда предпочитал помещать вспомогательный метод в модуль и импортировать этот модуль туда, где он мне нужен. Но все же важно отметить, что регистрация глобальных переменных — любого вида — не усложняется.

Случай с директивой debounce

Должен сказать, я на самом деле с вами в этом вопросе! Недавно я просмотрел все свои проекты Vue, и каждый из них, у которого где-то был input , также использовал debounce . На самом деле, только одно из моих прошлых приложений _не_ использовало debounce. Хотя технически это утилита — lodash и многие другие надежные проекты предлагают решения для устранения отказов — эта проблема довольно универсальна для разработки пользовательского интерфейса для _любого_ приложения. Написание собственной функции устранения дребезга также достаточно нетривиально, поэтому я, вероятно, захочу использовать реализацию lodash почти для каждого проекта.

Остаются некоторые внутренние дебаты по этому поводу, так что посмотрим, куда это пойдет. Но да, лично для меня и, кажется, для некоторых других удаление debounce лишает большинства удобств, предлагаемых v-model .

Еще раз спасибо за ваше увлечение!

Серьезно, нам нравится, как сильно вы любите Vue, и мы очень рады, что вы выражаете свои опасения, особенно в такой доброй и уважительной форме! Мы слышим вас. Основная команда состоит из дизайнеров, фронтенд-разработчиков и специалистов по визуализации данных. Мы все используем Vue для нашей собственной работы, которая довольно разнообразна, поэтому мы определенно стремимся выпускать пробную версию, которую мы сами захотим съесть. :-)

Говорить дешево, давайте код, чтобы увидеть, если без фильтра, как мы применяем filterBy и наоборот:

напишите глобальные чистые функции фильтра в отдельном файле для повторного использования кода

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

использовать фильтры в шаблоне 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>

посмотреть результат здесь http://raywill.github.io/vuefilter/

Если используется фильтр, следующий код vue будет делать то же самое:

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

Очевидно, с поддержкой фильтра мы могли бы написать менее тривиальный код.
Лично я предпочитаю vue 1.0, что делает программирование более приятным.

Что касается проблем с шаблонами - есть несколько способов справиться с ними.

1. Явный импорт/экспорт

Как @raywill продемонстрировал выше. Это немного более подробно, но преимущества в том, что:

1. Вам не нужно искать документацию по фильтрам Vue, чтобы понять, как они работают. Совершенно ясно, откуда берутся функции и как они реализованы.
2. Сами функции — это просто JavaScript. Вы можете изменить/составить их, чтобы они соответствовали особым случаям использования, в отличие от встроенных фильтров, которые вы не можете трогать.
3. Вы можете импортировать и программно повторно использовать эти функции в методах, вычисляемых свойствах и везде, где вы пишете JavaScript.

2. Прикрепите их к Vue.prototype

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

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

3. Перейти на функционал (для опытных пользователей)

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

Где вспомогательные функции выглядят так:

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

Опять же, очень важным соображением при проектировании является то, что встроенные фильтры могут быть полезны, но им не хватает гибкости чистого JavaScript . Когда встроенная функция не соответствует вашим потребностям, вы либо заново реализуете что-то похожее (и добавляете и то, и другое в свой окончательный код, где встроенная функция становится бесполезной, мертвым кодом), либо вам приходится ждать, пока Vue запустится. обновить их и выпустить новую версию.

@ yyx990803 Мне нравится подход прототипа, но как насчет случаев, когда вам нужно несколько фильтров?

Довольно часто используется orderBy вместе с filterBy

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

Как насчет случаев, когда вы также добавили бы limitBy ?

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

Делает ли такой подход код менее читаемым?

Да, по крайней мере, на мой взгляд.

Я думаю, мы могли бы объединить фильтры, такие как filterAndOrderBy , но это тоже не кажется правильным.

Я открыт для изменений, просто хочу придумать почти такой же простой способ справиться с этим!

Кроме того, возможность использовать фильтры в любом месте также является очень хорошим моментом.

Просто отметим, что @vuejs/collaborators обсуждали возможность предоставления пакета утилит для текущих интегрированных фильтров. Существует множество ресурсов, которые предоставят вам полезные инструменты для вашей кодовой базы.

Хорошая вещь об удалении основных фильтров заключается в том, что теперь вы можете настроить/внедрить их самостоятельно. Что дает вам гораздо больше гибкости.

Выражения шаблона @rigor789 должны быть максимально простыми. В идеале так же, как <div v-for="filteredData"> </div> . Это может быть вычисляемая опора, которая может содержать логику для создания отфильтрованных данных. Это более читабельно и лучше, чем что-то вроде:

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

Гораздо удобнее повторно использовать его как вычисляемое свойство, и его даже можно передать дочерним компонентам. Что, если вы хотите использовать отфильтрованные данные в двух местах? Для шаблонов проще, проще, надежнее и читабельнее иметь простые выражения по сравнению со связанными фильтрами в выражениях.

Для тех, кто следит за мной, я ответил @chrisvfritz здесь: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17.

Следующее решает мой вариант использования _очень_ нескольких глобально доступных вспомогательных функций чистого представления. Я снимаю свои опасения по удалению фильтра. Сожги их! 🔥 Поздравляю @chrisvfritz и @yyx990803 с изменением чьего-то (моего) мнения в Интернете!

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

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

Я полностью согласен с @yyx990803 , удалите фильтры и придерживайтесь простых функций JS.

@blake-newman Это очень хороший момент, на данный момент я в основном убежден, и, думая о читабельности, я думаю, что что-то подобное можно достичь

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

Вот быстрый jsfiddle концепции

Хорошая вещь об удалении основных фильтров заключается в том, что теперь вы можете настроить/внедрить их самостоятельно. Что дает вам гораздо больше гибкости.

Вы всегда могли настроить/внедрить их самостоятельно.

Vue не является служебной библиотекой. И, честно говоря, ни одна из предложенных нами утилит не была лучшей в своем классе.

Что нас беспокоит, так это удаление функции фильтрации в шаблонах. Удаление встроенных фильтров имеет большой смысл — их можно легко воссоздать, проксировав их на подчеркивание/другие библиотеки утилит. Затем кто-то может даже выпустить отдельный плагин, воссоздающий все текущие встроенные фильтры.

Использование вычисляемых свойств вместо фильтров также дает то преимущество, что обработанное значение можно легко повторно использовать СУХИМ способом в любом месте компонента.

Конечно, вы можете использовать вычисляемые свойства, если вам нужно повторно использовать их в другом месте. Но если вы этого не сделаете, фильтр все же гораздо удобнее.

Есть некоторые другие моменты, которые я разместил в этой ссылке, которой я поделился выше.

Почему бы не поддерживать синтаксис для фильтров, который работает подобно синтаксису, предлагаемому ES7? Это позволило бы людям продолжать использовать свои любимые фильтры и привести их в соответствие с тем, что может быть в будущем. В конце концов, когда у нас появятся каналы ES7, вы сможете переключать внутреннюю реализацию без изменения API.

Трубы ES7 одобрены или подлежат большому количеству изменений?

Теоретически он может измениться, но кажется... стабильным?
Статус: mindeavour/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Я думаю, что мы на одной волне в отношении ценности труб в целом. 😃 Одним из преимуществ нового компилятора в версии 2.0 является то, что мы можем передавать сгенерированный код функции рендеринга через Babel. Это все еще нуждается в дальнейшем изучении, но не исключено, что как только |> наберет больше оборотов и будет разработан плагин Babel для него, вы сможете с радостью снова связать методы с конвейерами - _везде_ в своем приложении. Как большой поклонник LiveScript и других функциональных языков, я определенно признаю ценность !

этот оператор трубопровода даже не находится на стадии 0

@thelinuxlich Да, я думаю, они все еще ждут чемпиона на TC39. 😞

@rigor789 это одна из альтернатив, которую я тоже хотел упомянуть! Сила JavaScript позволяет вам добиться выразительности по вашему выбору, и это лучше, чем помещать логику фильтрации в шаблоны.

@ yyx990803 Как Vue работает в следующих случаях, когда обновляется имя одного пользователя?

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

Кажется, что первый будет перерисовывать только один объект, а второй будет пересчитывать весь список?

@rpkilby ,

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

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

Все еще не нравится идея использования методов в качестве фильтров (внутри это кажется неправильным, но не может объяснить это). В любом случае вы обсуждали другие способы предоставления фильтров, поэтому +1.

Ничто из предложенного в этой ветке и близко не приближается к выразительности и лаконичности фильтров. Это просто не так.

И это меня очень огорчает. Как я уже сказал в ветке форума: для меня это удаляет большую часть того, что делает Vue Vue.

Если ты меня ищешь, то можешь найти меня в углу громко рыдающей 😟

Ни в коем случае, это изменение поощряет хорошее кодирование Javascript, смиритесь с этим :)

Итак, у меня только что состоялась долгая дискуссия с @yyx990803 , где я — с точки зрения пользователя — предложил сохранить поддержку _syntax_, потому что она кажется элегантной и естественной. Мое воображение было примерно таким:

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

У меня сложилось впечатление, что это приблизит лучшее из обоих миров.

В конце концов, однако, я убежден, что удаление фильтров в целом на самом деле лучше: как только что сказал @thelinuxlich , это способствует лучшему JavaScript и логическому мышлению. Мы не вводим логику в Laravel Blade или любом другом слое представления фреймворка, и мы не должны этого делать в шаблонах Vue.

Тем не менее, @JosephSilber, если вы посмотрите на другой угол, вы найдете меня там.

Для меня фильтры кажутся очень красивыми, синтаксис именно такой, каким должен быть синтаксис фильтра.

Еще одна привлекательная особенность Vue для меня заключается в том, что он поставляется с (некоторыми) батареями. Было бы очень грустно потерять любую из этих вещей — и то, и другое, по моему мнению, выделяет Vue.

Читая ветку, кажется, что большая часть проблем с фильтрами была связана с тем, что у Vue были фильтры по умолчанию, а не сама функция (или это так? Я до сих пор не уверен).

Мне нравится идея плагина фильтра от @blake-newman, и должны быть готовые примеры. Если другие люди придумывают другие фильтры, они должны быть готовы к работе. Это было бы прекрасно. Я абсолютно согласен с тем, что создание фильтров является обязанностью пользователя.

Что все еще требуется, так это возможности канала и цепочки, а также глобальность исходной функции фильтра. Опасения по поводу глобальности были освещены @yyx990803. Как насчет цепи с трубой? Это очень помогает в чтении шаблонов и понимании того, что следует ожидать в качестве результата. Труба и цепочка обсуждались выше. Можно еще сделать? Почему это вообще плохо? Для дизайнера это золото! Фильтр — это инструмент дизайнера, а не JS-программиста. Итак, аргумент написания лучшего JS отпадает в моей книге, но я могу понять, почему это нужно. Но, как дизайнер, я тоже хочу писать более качественный код, и фильтры позволяют мне красиво. :улыбка:

Скотт

Вот что касается цепочки — фильтры в основном используются для двух целей:

1. форматирование текста;
2. обработка массива.

В случае форматирования текста в 90% и более случаев используется только один служебный метод. Цепочка в данном случае не такая уж большая проблема.

Что касается массивов: я уже указывал, что обработка массивов на самом деле является логикой и лучше подходит для JavaScript. Наличие нескольких объединенных в цепочку фильтров-массивов может выглядеть нормально, когда это просто, но может стать уродливым, когда вы используете более 1 аргумента для каждого. Это также побуждает вас вкладывать в свой шаблон слишком много логики, хотя на самом деле этого делать не следует. Они также негибкие (не могут легко получить обработанное значение). По сравнению с ES2015 исходный пример

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

можно записать как:

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

Это просто JavaScript, в нем нет магии, нет альтернативного синтаксиса и API-интерфейса для конкретных фильтров, который нужно изучать. И вы можете получить доступ к обработанному значению (которое разумно кэшируется). Вы также можете добавить сахар поверх этого, как показано в предыдущих комментариях. Кроме того, ваш шаблон выглядит чище:

<div v-for="filteredThings">

Я знаю, что это похоже на то, как если бы убрали удобную вещь, но, честно говоря, аргументы в пользу фильтров прямо сейчас кажутся мне просто попыткой сохранить синтаксис ради синтаксиса. На мой взгляд, чтобы оправдать функцию, нужно нечто большее, чем просто «потому что это элегантно» — она должна обеспечивать объективную ценность. Это имело место для inline-templates , но я не вижу этого для фильтров.

@ yyx990803 - filteredThings ничего не говорит о том, что он на самом деле делает. Для меня это плохая практика. :smile: Тот факт, что метод фильтрации является глобальным, также означает, что я должен искать в документах, коде или расшифровывать вывод, чтобы узнать, что делает метод. Не очень элегантно. Правильно?

Итак, хорошо. у нас могло бы быть имя метода вроде `filterByOrderByAndLimit'. А аргументы?

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

Это было бы правильно?

Если да, то это возможно. Тем не менее, это не выглядит хорошо.

И теперь я хочу только filterBy и OrderBy. Нужен ли мне для этого отдельный метод? А потом я хочу добавить форматирование валюты. Другой метод? Цепочка фильтров в шаблонах делает управление презентацией гибким и очень выразительным. Эту проблему еще предстоит должным образом решить с помощью методов (и недостаток моих знаний не позволяет мне понять, что методы могут быть лучше).

Возможно ли это?

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

Я согласен, что слишком много логики в шаблоне следует избегать. Но цепочка фильтров и возможность просто вставить фильтр в любом месте в компонентах/шаблонах приложения — это фантастическая концепция, и была причина, по которой вы добавили ее с самого начала. Что это было за причина или причины? Если вы можете назвать их, то я держу пари, что они перевешивают «но это продвигает плохие методы» на милю.

Все, что допускает гибкость, можно использовать неправильно, как и сам Vue. Главный аргумент в пользу inline-template заключался в том, что он был гибким и позволял использовать Vue по-разному. Фильтры не сильно отличаются, за исключением того, что они являются внутренними для Vue и не влияют на то, как Vue может использоваться извне. Тем не менее, это не умаляет его значения. Помните, что многие люди также говорили, что им не стоит обновляться. Это так важно! :улыбка:

Новому способу просто нужны те же атрибуты, что и у старого.

• цепочка
• Глобальный
• добавить в шаблоны, чтобы красиво выразить, как будут манипулировать данными в шаблонах

(я ничего не забыл?)

Если он сможет все это сделать, то я уверен, что все будут в значительной степени удовлетворены. Я лично не вижу, чтобы это происходило с методами (пока).

Скотт

@smolinari

1. Я ясно сказал, что вы должны помещать меньше логики в свои шаблоны. Это мое мнение, нравится вам это или нет. Очевидно, вы можете не соглашаться, но я не могу вам помочь, если вы хотите работать против рекомендуемой передовой практики.
2. Учитывая (1) — я объяснил, почему цепочка не является проблемой, потому что сложная логика должна выполняться в JavaScript.
3. Я также привел примеры того, как вы можете добавить глобально доступные методы.
4. См. пример @rigor789 в пользовательском синтаксисе цепочки, похожем на то, что вы хотите.
5. Цель фреймворка — предоставить то, что, по моему мнению, является лучшим способом разработки клиентских приложений, а не угодить всем. Поэтому, пожалуйста, не используйте фразу «Я не буду обновляться, если вы не вернете мне эту функцию» — это не работает.

Почему бы вам, ребята, не попробовать этот новый альфа-релиз в течение недели, а затем оставить несколько действительно ценных комментариев (на основе вашей практики)? Может быть, вы попытаетесь провести рефакторинг вашего существующего приложения и сообщите нам, что было невозможно, что было улучшено, а что стало хуже, чтобы мы могли лучше обсудить это. Это было бы полезно для всех, я думаю.

@ yyx990803 - Я согласился на 1. Итак, мы согласны. :smile: Я просто не согласен, что это уважительная причина для изъятия чего-то, что снискало столько любви.

Итак, я полагаю, со временем вы решили, что прагматичный JS лучше, чем прагматичный HTML?

Аргумент отказа от обновления - это то, что говорили другие. Я просто пытаюсь общаться и смягчить это.

Последний аргумент от себя. Посмотрите на это глазами пользователя. Скажем, у меня есть система вроде Laravel или какая-то другая система MVC или MVVM, которая включает Vue, что также позволяет пользователю этой системы создавать свои собственные компоненты. Фильтр, как это было раньше, упрощает процесс обучения и позволяет пользователям этой системы многое сделать, не касаясь JS. Я поклонник Vue, потому что он позволяет программистам, не использующим JS, по-прежнему делать многое. По той же причине я не люблю React и JSX. Со временем эта комбинация будет иметь намного меньшую базу пользователей по сравнению с Vue. Ставлю на это деньги.

Я также понимаю, что настоящая гибкость заключается в JS. Тем не менее, пожалуйста, не полагайтесь исключительно на JS из-за гибкости Vue. Имейте в виду, что не каждый программист-убийца JS. На самом деле, большинство людей не такие. Фильтр был хорошим способом сделать многое для этих людей, и это был хороший шаг к дальнейшим манипуляциям с JS. Фильтры не могут сделать это? Углубитесь в методы JS.

В порядке. Хватит с меня..... Я закончил. И, спасибо, что выслушали в любом случае. Vue по-прежнему великолепен! :улыбка:

@azamat-sharapov - хорошее замечание.

Скотт

Мне грустно видеть, как люди пытаются оправдать плохие практики внутри JS. На самом деле, вам не нужно быть профессионалом, просто сделайте базовую домашнюю работу (или в наши дни это уже не так?)

Проблема, с которой я столкнулся с методами filter-inside, связана с семантикой.

С точки зрения oops, фильтры похожи на статические функции, а методы — на нестатические.

Фильтры передают совершенно другую семантику, чем методы. самая большая разница в том, что фильтры не могут использовать this , а методы могут.

@ yyx990803 при использовании Vue.prototype.filters может работать, но изменение Vue мне не кажется хорошей практикой. Я бы предпочел создать отдельный (глобальный) объект, который будет содержать все фильтры.

Это не похоже на хорошую практику, потому что глобалы не являются хорошей практикой. Рекомендуемый подход — явный импорт вспомогательных методов. Присоединение к прототипу — обходной путь для тех, кто не хочет явно импортировать методы.

Что касается семантики, фильтры в любом случае являются придуманной концепцией. В JavaScript вы не стали бы изобретать другую семантику только для того, чтобы прописать строку — вы вызываете функцию. И это то, что они есть, функции JavaScript.

Я собираюсь сделать еще один комментарий, чтобы попытаться прояснить мою личную точку зрения, в основном из-за комментария «попытка оправдать плохие практики внутри JS». Я, конечно, не пытаюсь это сделать.

Я понимаю, что Vue — это больше, чем просто система шаблонов, но это тоже система шаблонов, и я боюсь, что она пытается отойти от этой роли, чего, по моему мнению, делать не следует. Итак, в качестве механизма/системы шаблонов возьмем механизм шаблонов Twig как очень успешный пример того, что можно ожидать от системы шаблонов. У них есть разделы " Для дизайнеров шаблонов " и " Для разработчиков " в их документах. Как система шаблонов, Twig удобен и для дизайнера шаблонов, потому что он битком набит стандартными поведениями, включая фильтры . Это позволяет не разработчикам делать массу вещей с системой шаблонов, не зная PHP напрямую. Им просто нужно узнать, что может предложить Twig и как его использовать. Я тоже ищу это в Vue. Я также хотел бы видеть в документации раздел «Vue для дизайнеров шаблонов». :улыбка:

Также очень важна расширяемость Twig. Если чего-то нет в стоковой версии, это можно добавить. Именно тогда в дело вступает разработчик. Приятно то, что расширениями можно делиться, а это значит, что это нужно сделать только один раз.

Другая приятная особенность этих двух уровней дизайнера/разработчика заключается в том, что вы получаете гораздо более широкую базу пользователей. Гораздо шире, и это то же самое, что и . И когда поведенческих установок по умолчанию недостаточно, тогда они начинают охотно изучать лежащий в их основе язык. И именно тогда они изучают лучшие практики и все остальное.

Если вы говорите, что Vue не может быть шаблонизатором без изучения JS, то я бы сказал, что это значительно снижает его рыночную стоимость. Если вы скажете, что оставите дверь открытой, чтобы позволить другим делать эти инструменты для механизма шаблонов в виде плагинов, отлично. Но тогда все будут бороться за то, что должно быть в системе шаблонов. Это тоже контрпродуктивно ИМХО.

В вашем примере студента, говорящего о фильтрах, Эван, кто-то изучал JS или кто-то изучал механизм шаблонов? Если бы это было второе, держу пари, разговор пошел бы по-другому.

Во всяком случае. Я по-прежнему считаю Vue выигрышной системой. Я надеюсь, что мои мысли могут каким-то образом заставить других думать о ролях Vue по-другому. :улыбка:

Скотт

@ yyx990803 yyx990803, если фильтры - это придуманная концепция, то почему они были придуманы в первую очередь?

Я считаю, что это потому, что внутри <template> все внешние переменные, такие как $data или abc , преобразуются в this.$data и this.abc и, следовательно, определяются простые функции js вне компонента нельзя ссылаться. Для преодоления этого ограничения были введены фильтры.

Это ограничение все еще существует --- я предполагаю, что я прав --- чтобы снять ограничение, разработчикам потребуется явно закодировать this.abc для ссылки на this.abc и получить доступ к функциям js, как они будут указаны в js.

Но это будет слишком мощная функция, подверженная злоупотреблениям, и миграция старого кода будет болезненной. текущий синтаксис выглядит намного лучше, чем это для меня.

Я согласен с вами, что фильтры в основном являются функциями js и должны быть импортированы в компонент. Мне просто не нравится, что они определены там же, где и методы.

Всем привет. Прочитал всю ветку и вот что думаю.

• Никто не пропустит встроенные фильтры типа orderBy filterBy и любые другие.
• Что все хотят иметь под рукой, так это оператор канала в шаблонах.
• Основная команда говорит, что логика должна храниться в javascript, а не в шаблонах, кроме того, в es7 появится функция с оператором канала.

Имея это в качестве краткого резюме, я думаю, что это может быть хорошим решением, пока js не реализует собственный оператор канала , будет иметь оператор канала в качестве плагина и сохранить версию 2.0 как есть. Итак, пользователи могут сделать

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

Пока мы ждем реализации новой функции, ее можно было бы включить с некоторым предупреждением о предстоящем устаревании или что-то в этом роде. Я знаю, что любой может реализовать этот плагин, но я думаю, что было бы лучше, если бы он был предоставлен и сохранен командой Vue, возможно ли это?

Я могу ошибаться, но я не думаю, что Vue позволяет плагинам связываться со своим компилятором.

@azamat-sharapov Конечно, нет. Я просто не думал, что это испортит компилятор Vue :open_mouth:

@YerkoPalma Я абсолютно _люблю_ оператора трубы. Я одержимо использую его в функциональных языках и не могу дождаться, когда он появится в JavaScript! _Но_ представьте себе, что во Vue никогда не было фильтров. Хотели бы вы, чтобы внешний интерфейс расширил синтаксис JavaScript? Это область применения Babel или языка компиляции в JS, а не UI-фреймворка. Если вы предпочитаете использовать такой язык, как LiveScript, как я часто делаю, вы можете. Но проблема здесь не в Vue. Это связано с самим JavaScript, и мы здесь не для того, чтобы это исправлять.

Кроме того, если мы сможем передавать результаты рендеринга в версии 2.0 через Babel, как мы надеемся, то вы даже сможете использовать отслеживаемый плагин, не относящийся к TC39, если хотите — последовательно, везде в вашем JavaScript, вместо только в шаблоне. Так что, если вам просто нужна трубка, скорее всего, вы сможете ее получить. И вы _можете_ иметь его сегодня в 1.x - просто имейте в виду, что канал, который вы будете использовать в своих шаблонах, вероятно, будет иметь другой приоритет и поведение, чем в вашем Babel.

@smolinari и другие. Я постоянно слышу две фразы (и их варианты):

• «Думайте о разработчиках / о точке зрения пользователя»
• «Думай о новичках»

Оба подразумевают предположение, что мы _не_ думаем об этих группах.

Я упоминал об этом раньше, но я думаю, что это нуждается в повторении. _Каждый_ в основной команде является либо дизайнером, либо разработчиком интерфейса, либо комбинацией того и другого . Мы используем эти инструменты каждый день для нашей собственной работы. Мы также будем использовать Vue 2.0. Поверьте, мы _are_ думаем об этом. 😉

Что касается новичков, то здесь я сделал кейс , но, пожалуй, остановлюсь подробнее. Я педагог. И я был сторонником устранения фильтров, _думая о новичках_. Я лично научил сотни людей — может быть, даже больше тысячи — как практиковать веб-разработку, обычно с нуля. Нет предыдущего опыта кодирования. Я делал это со школьниками средних и старших классов, студентами университетов, взрослыми специалистами и пожилыми людьми.

С этой точки зрения я могу сказать вам, что, хотя фильтры поначалу могут показаться захватывающей магией, в конечном итоге они замедляют обучение учащегося, усложняя его для ограниченного удобства. Если бы их никогда не было в Angular или Vue и этот разговор был обратным — мы пытались _ввести_ их в 2.0 — нам было бы трудно объяснить, зачем они нужны и когда их следует использовать.

Еще до того, как заговорили об устаревании в версии 2.0, я исключил фильтры из учебного плана в нашей школе кодирования, потому что мы собрали достаточно доказательств того, что они приносят новичкам больше вреда, чем пользы. Мы бы предпочли, чтобы они получили опыт работы с более универсальными функциями Vue, такими как методы и вычисляемые свойства. Мы даже не рекомендовали использовать фильтры, потому что они облегчали выявление плохих практик.

Надеюсь, что эти две жалобы улеглись. Посмотрим. 😃

Но представьте, что у Vue никогда не было фильтров. Хотели бы вы, чтобы внешний интерфейс расширил синтаксис JavaScript?

Конечно, я буду, так как фильтры очень естественны для _templates_, как в Twig, упомянутом ранее. Я чувствую, что иметь оператор канала так же естественно, как иметь синтаксис усов в шаблонах, я имею в виду, что усы - это не html и не javascript, вы, ребята, тоже собираетесь их удалить? в чем разница с трубным оператором?

Аргумент "подумай о детях" просто глуп. Насколько я знаю, Vue предназначен не для обучения JavaScript, а для фронтенд-разработчиков. Для последнего отлично подходят фильтры.

Если бы их никогда не было в Angular или Vue и этот разговор был бы обратным — мы пытались ввести их в 2.0 — нам было бы трудно объяснить, зачем они нужны и когда их следует использовать.

Я очень не согласен. Я использую фреймворк Python под названием Django с 2005 года, и его язык шаблонов, который послужил источником вдохновения для большинства появившихся позже языков шаблонов, имел фильтры с самого первого дня. После десяти лет их использования с фронтенд-разработчиками я оценил их красоту и полезность. Было бы грустно, если бы этот синтаксис исчез.

(Вот что Django делает с фильтрами: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference)

@Uninen, пожалуйста, следите за своим тоном - называть аргументы других глупыми - неконструктивный способ участвовать в обсуждении.

Для тех, кто проводит аналогии с языками шаблонов на стороне сервера, следует отметить один важный аспект: языки шаблонов на стороне сервера не обладают такой же гибкостью, как шаблоны Vue (нет вычисляемых свойств, ограниченные выражения). Также - они созданы для совершенно разных целей: вывод статических строк. Шаблоны Vue — это представления интерактивной модели DOM — есть двусторонние привязки, обработчики событий, реквизиты компонентов и многое другое. Фильтры подходят только для очень ограниченного варианта использования в контексте Vue: сегодня я считаю плохой идеей разрешать фильтры везде, например, фильтры на v-model, v-for и v-on привносят больше сложности, чем пользы.

Одной из возможных альтернатив является сохранение фильтров, но только для интерполяции текста, т.е. вы можете использовать их только внутри {{ }} , а не в директивах.

В качестве интересной ссылки: в Angular 2 все еще есть фильтры (переименованные в «каналы»), но они также намеренно удалили фильтры списка.

Извините за мой язык, не хотел никого оскорбить.

Для меня цель фреймворка _ состоит_ в том, чтобы делать сложные вещи и сделать так, чтобы разработчики, использующие эти инструменты, выглядели простыми. Я все еще утверждаю, что синтаксис просто не может быть лучше, и, опять же, было бы грустно видеть, как он исчезает.

Я не знаю и не понимаю большую часть механизмов под капотом, но с точки зрения пользователя практичность важнее чистоты :)

В соответствующей заметке было интересно посмотреть, сколько страсти в этом сообществе. Для меня Vue был свежим и бодрящим инструментом, может поэтому мне самому пришлось принять участие в покраске именно этого сарая :)

Для другой точки данных Ember не имеет ни фильтров, ни методов компонентов, хотя и имеет вычисляемые свойства.

Для случая использования чистых функций, выполняющих преобразования в шаблоне, вы должны зарегистрировать помощник руля / помощник Ember.
http://emberjs.com/api/classes/Ember.Helper.html

Помощники руля синтаксически отличаются от вещей, которые не являются помощниками руля, поэтому я поднимаю эту тему. У них есть что-то общее с синтаксисом фильтра конвейера. Однако шаблоны рулей не содержат логики, что означает, что они требуют специального синтаксиса для вызова функции в шаблоне. Проблема, которой нет у Vue.

Фильтры просты для новичков, вы увидите немного волшебства, используя для красивого вывода или filter\ordersearch в массивах

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

и легко определить его

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

это просто, понятно в шаблонах, для 2.x вы определяете фильтры во внешнем модуле и в шаблонах получаете

import moment from 'moment'

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

и в шаблоне

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

Как предложение, почему бы не оставить старые фильтры в шаблоне, а переместить фильтры в отдельный модуль и использовать его из раздела методов?

Так что, если вам это нужно, просто сделайте

npm install vue-utils

и используйте специальные фильтры из пакета utils

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

methods:{
   moment, price
}

и использовать как общий фильтр

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

в результате это будет переведено в простой вызов функции

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

_Примечание_
Для меня фильтры чаще всего используются для форматирования данных, таких как даты, числа или строки . Для фильтрации массивов\объектов, я думаю, лучше использовать вычисление и функцию из общего модуля vue:

import _ from 'vue-utils/array'

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

Преимущества:
Новички могут легко использовать старые фильтры, но в вычисляемых и использовать красивые функции в своих шаблонах для форматирования вывода данных, а программисты могут написать для них собственные модули функций и упростить их использование.

_Зачем отдельный модуль?_
Я думаю, что это не обязательно должно быть в ядре Vue, но Vue должен иметь некоторые утилиты для конструктора шаблонов разработчиков, поэтому нет необходимости все время требовать lodash, момент или что-то еще, просто установите утилиты из npm и упростите их использование, но сохраните старый синтаксис вызова для шаблоны.
Но для фильтров необходимо сделать одно важное соображение: должны быть чистые функции, такие как геттеры в vuex.

Его легко поддерживать, легко использовать повторно и расширять, а шаблоны хорошо видны.

Что вам, ребята, нужно, так это четкий путь обновления и желание научиться модульности вашего кода Javascript.

@thelinuxlich Мы говорим о фильтрах.

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

просто синтаксический сахар для

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

Но полностью исключать фильтры для новичков в Vue\javascript — это плохо. Почему сообщество Laravel любит Vue? Потому что это просто и мощно.

Если полностью убрать фильтры, нужно дать альтернативу _"Для дизайнеров шаблонов"_, не нужно знать, как сортировать массив или фильтровать его, нужно просто ввести пример формы кода и получить результат.

Программисты должны знать, как _модулировать_ код Javascript, но остальным, кто использует его для мелких вещей, знать это не обязательно.

Если говорить о _"Для дизайнеров шаблонов"_ то можно просто поставить

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

и использование внутреннего кода

Vue.use(VueUtils)

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

из примера и гордимся собой, нет необходимости знать js для фильтрации и сортировки массивов, многие люди хотят что-то делать, но есть трудный для понимания код, например

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

так что нет необходимости делать сложные вещи для таких людей, если мы можем дать простое решение, и это будет хорошо для разработчиков.

Одной из возможных альтернатив является сохранение фильтров, но только для интерполяции текста, то есть вы можете использовать их только внутри {{ }}, а не в директивах.

Я думаю, что это может быть очень хорошим компромиссом. Хотя это не удовлетворит всех, это все, для чего я когда-либо использовал фильтры, и мне действительно кажется странным, что в настоящее время они могут делать больше.

Это позволит удобно форматировать текст, если вы хотите использовать фильтры и уменьшить сложность, эффективно удаляя двусторонние фильтры.

На мой взгляд, ваш пример фильтра momentjs уже передает шаблонам слишком много логики.

Серьёзно, всю эту "пайп-любовь" надо направлять в репозиторий спецификаций, пока не дойдёт до TC39 :)

Мне нравится то, что предложили @yyx990803 и @VitaliyLavrenko . Это может быть хорошей золотой серединой.

Скотт

Мне нравится предложение @VitaliyLavrenko , но когда я говорю что-то подобное, о наличии оператора канала в плагине, @azamat-sharapov сказал, что плагины не должны связываться с компилятором... Так что я запутался, возможно ли это вообще или если я просто не понял комментарий?

@thelinuxlich

Что вам лучше читать?

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

или

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

Думайте как разработчик и спросите кого-нибудь, кто не знает javascript.

Как по мне, для _не разработчиков_ лучше как-то так:

Vue.use(VueUtils)

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

Он средний и используется как vue-resource, просто обычная библиотека.

О трубе, я синтаксический сахар

вещь в вещах | filterПо 'foo' | заказПо 'бару' | limitBy 5

за

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

Какая легкость чтения?

Если вам нужно передать данные в 2 шаблона различий, вы храните 2 или 3 модификации для одних данных?

Если это будет что-то вроде:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

Это абстрактная ситуация, но если ее использовать в одном или двух шаблонах? Вам нужно хранить данные для 10 или 100 объектов? Увеличить использование памяти? Да, мы можем использовать вспомогательный метод и использовать его в шаблоне, но для _"Для дизайнеров шаблонов"_, которые далеки от javascript, лучше что-то вроде title | padLeft 10 и его нужно перевести в вызов функции, это просто и функционально.

Подумайте о разных людях, разработчики могут легко сделать это разными способами, но другие люди хотят сделать это проще.

Повторюсь, слишком много логики в шаблонах — это анти-шаблон. Вместо того, чтобы изучать конкретный DSL (фильтры), вы должны изучить Javascript.

@thelinuxlich Просто используйте JSX, и мы получим React с двусторонней привязкой и несколькими другими вещами.

Но с Vue мы получаем, что люди, которые не знают javascript, но с google могут что-то сделать, и если вам не нравится pipe, не используйте его. Мы можем просто добавить что-то вроде

Vue.config.pipeFuncCall = true

И вы можете включить\выключить его, но для некоторых людей это будет легко.

_Я еще раз скажу, что Vue могут использовать не только разработчики JS, это самая сильная сторона Vue._

Нужны стандартные общие фильтры, но лучше чтобы они были в отдельной библиотеке и чтобы их было проще добавить в vue и использовать.

Или вы хотите, чтобы Vue был чем-то вроде ASM, и его могли использовать только хорошие разработчики?

Ребята, я думаю, что решение, принятое основной командой Vue, было очень хорошо объяснено. Можем ли мы не повторять снова и снова одно и то же и комментировать только что-то новое, ценное, если таковое имеется?

Если частью основных принципов Vue является упрощение для разработчиков, не использующих JS, даже если это вредит принципам языка, то я соглашусь с вами, но, вероятно, это не так.

Как я уже говорил, я в основном согласен с устаревшими фильтрами, я, конечно, буду скучать по ним из-за их удобства, но я более чем уверен, что очень похожая система фильтров может быть представлена ​​в виде плагина.

Чуть ранее я привел пример доказательства концепции , который можно использовать как в вычисляемых свойствах, так и во встроенных.

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

С другой стороны, если кто-то хочет трубу, я уверен, что это можно сделать, с чем-то вроде этого

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

Или, возможно, если бы был хук, который позволил бы плагинам анализировать выражения и обрабатывать их так, как они хотят, это тоже могло бы быть возможным способом, но это зависит исключительно от того, насколько сложно это реализовать и какие эффекты это будет иметь. о структуре (производительность/размер), и действительно ли @yyx990803 захочет идти в этом направлении или нет!

Я чувствую, что если нам дадут элегантные альтернативы, которые просты в использовании (плагины или что-то в ядре), мы довольно быстро к этому привыкнем.

@rigor789 для фильтрации массивов, их сортировки и т. д., лучше использовать вычисление, оно намного чище. Но я думаю, проблема с отображением данных в формате diff:

если у нас есть поле created_at и нужно в шаблоне отображать его как dd.mm.YYYY или в ссылках

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

для этого фильтры используются хорошо сейчас, какую альтернативу мы можем получить от 2.x?

Пока используйте только

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

и определить метод даты, но это делает шаблон грязным, если хранить дополнительные 3 поля, это требует памяти, а если это 100-200 объектов, это становится тяжелым.

Вот окончательное решение:

1. Фильтры будут поддерживаться, но только внутри текстовых интерполяций. Это ограничивает их целями форматирования текста, в то же время применяя другую логику в области JavaScript.
2. Vue 2.0 будет поставляться без встроенных фильтров. При необходимости сообщество может создавать свои собственные пакеты фильтров.
3. Синтаксис фильтра будет изменен, чтобы использовать синтаксис вызова функции для аргументов вместо разделенных пробелами. Это делает его более совместимым с JavaScript и другими популярными языками шаблонов (Jinja2, swig, twig...):

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

Спасибо, что выслушал Эвана. Вот что делает Vue великолепным. У него есть великий лидер. :улыбка:

Скотт

@yyx990803 и @chrisvfritz

Одна вещь, которая, кажется, была похоронена в этом обсуждении, — это двусторонние фильтры. Двусторонние фильтры труднее всего воспроизвести с другими предлагаемыми решениями.

1. Рассмотрим этот простой пример , который я разместил в той ветке форума. Использование для этого вычисляемых свойств будет иметь 2 основных недостатка:
   
   
   
   1. Вам придется создать новое вычисляемое свойство для каждого значения, что приведет к тонне шаблонного кода.
   
   
   2. Что еще хуже, вычисляемые свойства нельзя даже вкладывать друг в друга . Если у вас есть более сложный граф объектов, все ваши вычисляемые свойства должны быть на верхнем уровне. В итоге вы получите длинные, многословные имена свойств, требующие большей когнитивной нагрузки, чтобы постоянно отслеживать, какое вычисляемое свойство отслеживает какое вложенное значение.
   
   

Отклонение этого варианта использования как «тривиального» или «менее сложного» контрпродуктивно. Я использовал это как в средних, так и в крупных приложениях. Это творит чудеса! Демонстрация обязательно проста, но техника надежна.

1. Это еще больше сбивает с толку при работе с массивом в v-for , например, в этом примере (опять же, намеренно просто). Перебирая массив, вы не найдете помощи в вычисляемых свойствах. Единственный способ обойти это — иметь отдельный компонент для каждого элемента в массиве, добавляя еще больше шаблонов.

Сравните этот пример с фильтрами:

```js
импортировать валюту из фильтра «некоторые валюты»;
импортировать продукты из 'products-stub';

новый Vue({
эл: документ.тело,
данные: { продукты },
фильтры: {валюта},
});
```

К одному без фильтров:

```js
импортировать валюту из фильтра «некоторые валюты»;
импортировать продукты из 'products-stub';

новый Vue({
эл: документ.тело,
данные: { продукты },
компоненты: {
продукт: {
реквизит: ['продукт'],
вычислено: {
цена: {
получить() {
вернуть валюту.прочитать(этот.продукт.цена);
},
установить (значение) {
this.product.price = валюта.записать (значение)
}
},
перевозки: {
получить() {
вернуть валюту.прочитать(этот.продукт.доставка);
},
установить (значение) {
this.product.shipping = валюта. запись (значение)
}
},
умение обращаться: {
получить() {
return currency.read(this.product.handling);
},
установить (значение) {
this.product.handling = валюта.запись (значение)
}
},
скидка: {
получить() {
вернуть валюту.прочитать(этот.продукт.скидка);
},
установить (значение) {
this.product.discount = валюта.записать (значение)
}
}
}
}
}
});
```

Я знаю, что из вышеперечисленного я хотел бы написать.

_{(это можно было бы немного почистить, создав фабрики вычисляемых свойств, но дело в том, что они гораздо более подробные, чем нужно)}

Поскольку основная команда, похоже, категорически против синтаксиса канала фильтра, можно ли ввести параметр filter для директивы v-model ?

С параметром filter мы сможем сохранить первую элегантную версию JS выше и просто переписать шаблон, чтобы использовать параметр вместо синтаксиса магической трубы:

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

Это обеспечит правильный баланс отсутствия волшебного синтаксиса, сохраняя при этом возможность легко преобразовывать ввод туда и обратно без особого шаблона.

Спасибо за внимание.

Я переписал ваш пример, чтобы включить ваш фильтр в качестве пользовательской директивы: jsfiddle .
Хотя это не так лаконично, как фильтр, это не так болезненно, как я себе представлял. И мне не потребовалось много времени, чтобы собрать воедино то, что уже доступно всем нам.

@Nirazul, создание специальных директив для каждого фильтра , предлагалось ранее . Необходимость создания новой директивы, повторно реализующей всю функциональность v-model для каждого типа фильтра, который вы используете в своем приложении, просто абсурдна.

Кроме того, ваша директива даже не полностью работает как фильтры; размытие поля после изменения значения не переформатирует его. Кроме того, v-model делает гораздо больше , чем вы делаете в этой директиве.

Директива, очевидно, может быть дополнена дополнительными функциями и исправлениями, но суть остается: все это вспомогательные средства поверх чего-то, что должно быть действительно простым прямо из коробки.

Я не видел ни одного предложения в этой теме, в котором упоминались бы пользовательские директивы. Не могли бы вы указать мне на этот комментарий?

Как вы понимаете, я не писал и не тестировал его для использования в вашем приложении. Я просто хотел показать, что возможно прямо сейчас в качестве альтернативы. Если это возможно так просто, может быть, есть место для плагина, чтобы автоматизировать процесс еще больше.
Очевидно, что этой наспех написанной директиве не хватает полной функциональности v-model. Возможно, одной пользовательской директивы фильтра в сочетании с параметрами и/или модификаторами будет достаточно, чтобы заменить фильтры.

Давайте оставаться конструктивными, как я и пытался решить вашу проблему. Всегда проще ругать решение, чем вносить свой вклад и двигаться вперед.

@JosephSilber , тебе нужно расслабиться. "нелепо" - это сильно сказано.

Привет, Мотивировано ли удаление фильтра уменьшением загромождения шаблона или это серьезно влияет на
техническая реализация 2.0? Если это бывшая проблема с визуальным эффектом, как насчет разрешения
фильтровать как сейчас (но с новой формой javascript)
но ограничивая его только одним выражением, например v-for="i of list | orderBy('key')", (не более одного знака вертикальной черты)
это может сделать обработку фильтров в версии 2.0 более простой и предсказуемой, а также визуально менее загроможденной.
Поскольку для {{}} будет выполняться синтаксический анализ фильтра, его использование в других выражениях имело бы смысл.
это будет соответствовать всем существующим вариантам использования/функциям (таким как двусторонняя фильтрация, элемент в v-for).
Любое существующее использование более чем одного фильтра может быть легко объединено/обновлено в один владельцами.

@tomsmithgroup То, что вы предложили (и многое другое), было решено оставить в версии 2.0.

@yyx990803 и @chrisvfritz хотели бы услышать ваше мнение о двусторонних фильтрах .

@JosephSilber Итак, с фабрикой вычисляемых свойств, о которой вы упомянули, даже не так много шаблонов:

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

Хотя лично я бы не стал создавать фабрику для этого примера, потому что каждое из этих свойств на самом деле является отдельной задачей, которая только _выглядит_ одинаковой прямо сейчас. Когда вы удаляете фильтры, становится гораздо более очевидным, насколько сложным был этот компонент. Это то, что вы видите как шаблон.

И это огромная причина, по которой компоненты _существуют_. Разделить сложность на управляемые проблемы. Когда я смотрю на компонент, все, что он делает, должно легко помещаться в моей рабочей памяти, иначе разработка становится намного медленнее и более подверженной ошибкам. Сокрытие сложности за синтаксисом фильтров не устраняет эту сложность.

Чтобы продемонстрировать это, давайте посмотрим, что происходит, когда проблема сталкивается с изменяющимися требованиями реального мира: допустим, вы решаете, что скидка не должна превышать цену + доставку + обработку. Или обработка не должна превышать сумму X. Или поле скидки должно быть в процентах, а не в валюте. Или, если общая сумма превышает определенную сумму, должна автоматически применяться минимальная скидка.

У вас может возникнуть соблазн сделать фильтр более сложным с дополнительными параметрами и условной логикой. Когда вы обновляете API фильтра и внутреннюю логику, вам теперь нужно подумать о том, как ваши изменения могут повлиять на что-либо еще, использующее фильтр — возможно, даже за пределами текущего компонента, если это общий фильтр. Итак, теперь вы находитесь в ситуации, когда внесение изменений в ваше приложение начинает казаться пугающим. И все потому, что общий двойной фильтр позволяет вам делегировать внутреннее состояние компонента за пределы компонента, нарушая границы компонентов, увеличивая связанность и скрывая сложность, о которой вам все еще нужно думать каждый раз, когда вы работаете над компонентом.

Разбивая вещи на несколько отдельных менее сложных компонентов с отдельно определенными вычисляемыми свойствами или связанными реквизитами, вы часто обновляете одну строку, чтобы приспособиться к меняющимся требованиям. Никаких дополнительных опций или условий. Нет рефакторинга для удовлетворения сложности масштабирования. Вам не нужно думать ни о чем за пределами компонента _или даже за пределами этого единственного свойства_. Ваше приложение было с самого начала и до сих пор остается простым для обдумывания и обновления.

Я думаю, что в данном случае фильтры изначально привлекательны, так это то, что они являются легкодоступным лекарством от дублирования. Но дублирование не является шаблонным, когда оно случайно (т. е. код оказывается таким же прямо сейчас, до того, как неизбежно начнут возникать реальные проблемы).

И я не могу выразить это лучше, чем Санди Мец:

дублирование намного дешевле, чем неправильная абстракция

@chrisvfritz Фильтры не имеют абсолютно никакого отношения к бизнес-требованиям. Фильтры просто форматируют данные. Вот и все. Они не манипулируют им ни в каком виде, ни в форме, ни в форме. filter="currency" концептуально совпадает с параметром number . Бизнес-требования, очевидно, никогда не должны обрабатываться в фильтрах.

Скажем, вы решили, что скидка не должна быть больше, чем цена + доставка + обработка. Или обработка не должна превышать сумму X.

Затем вы должны использовать какой-нибудь правильный модуль проверки, а-ля vue-validator . Валютный фильтр останется на своем месте, просто отображая базовое значение.

поле скидки должно быть в процентах, а не в валюте.

Тогда, очевидно, его тип больше не является валютой. Это ничем не отличается от того, если вы замените type="text" на type="email" , когда изменятся требования к имени пользователя. Или даже когда вы удаляете параметр number , когда поле больше не является числом.

если общая сумма превышает определенную сумму, должна автоматически применяться минимальная скидка.

Опять же, будет применен минимум, но фильтр валюты останется на месте. Вы все еще хотите отображать его как валюту.

Когда вы обновляете API фильтра и внутреннюю логику, вам теперь нужно подумать о том, как ваши изменения могут повлиять на что-либо еще, использующее фильтр [...] два фильтра позволили вам делегировать внутреннее состояние компонента за пределы компонента.

Нет. Вы _никогда_ не вводите никакую логику или состояние в сам фильтр. Фильтр — это идемпотентная функция, предназначенная исключительно для форматирования значений. В идеале его даже не следует выполнять в контексте виртуальной машины ; у него не должно быть this , из которых можно извлечь дополнительные данные.

дублирование намного дешевле, чем неправильная абстракция

... когда, как вы сказали, вы абстрагируете код, который сейчас один и тот же. С другой стороны, фильтры — это простые идемпотентные функции, которые форматируют значение. Они вовсе не абстракция.

Фильтры tl;dr не являются абстракцией и не заменяют явных бизнес-требований. Фильтры никогда не имеют никакой внутренней логики и никогда не должны. Концептуально они аналогичны HTML-атрибуту type и параметру v-model number .

Двухсторонний фильтр, безусловно, является абстракцией. Текущее поведение двухсторонних фильтров на v-model скрывает внутри много волшебства — в частности, оно позволяет входному значению DOM временно не синхронизироваться с базовой моделью и «синхронизирует» их только тогда, когда вы размыть поле. Кстати , @JosephSilber это поведение было реализовано специально по вашему запросу, поэтому я могу понять, почему вы так сильно к этому относитесь.

Тем не менее, самая большая проблема, которую я вижу с двусторонними фильтрами, заключается в том, что лежащая в основе логика представляет собой черный ящик, и у пользователя нет возможности дополнительно настроить его, кроме как запрашивать функции. На мой взгляд, лучший вариант — предоставить правильные строительные блоки для самостоятельной реализации такого поведения. И позвольте мне показать вам, как это возможно в 2.0:

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

Здесь у нас есть базовый компонент CustomInput , который реализует поведение «вне синхронизации до размытия» текущих двусторонних фильтров. Из-за изменений в версии 2.0 вы можете напрямую использовать v-model в пользовательских компонентах, если компонент принимает свойство value и $генерирует события input . Кроме того, он также форматирует значение для событий change , что в настоящее время невозможно с двусторонними фильтрами . Вы можете дополнительно настроить этот компонент, чтобы получить любое желаемое поведение, не привязываясь к тому, как двусторонние фильтры реализованы фреймворком.

Базовый компонент не реализует логику синтаксического анализа/форматирования — вы расширяете его с помощью методов parse и format , чтобы получить настраиваемые компоненты ввода, адаптированные для конкретных случаев использования. В данном случае компонент CurrencyInput .

Базовый компонент более сложен, чем двухсторонние фильтры, потому что теперь мы сами реализуем предыдущее магическое поведение. Однако вам нужно определить этот компонент только один раз. Взамен вы получаете полный контроль над тем, как он должен себя вести, если вы захотите изменить его позже. Я считаю, что это достойный компромисс.

Это пример того, как мы должны больше думать о компонентах, потому что это унифицированная абстракция для повторного использования, которая дает вам максимальный контроль. Также см . пример select2 версии 2.0 — ранее в версии 1.0 это было реализовано как директива, но теперь это компонент с тем же интерфейсом v-model .

На мой взгляд, лучший вариант — предоставить правильные строительные блоки для самостоятельной реализации такого поведения.

Это здорово и определенно то, что нужно Vue, однако мне бы хотелось прочитать это.

На мой взгляд, лучший вариант — предоставить правильные строительные блоки для начала работы с Vue, а также самостоятельно расширить Vue новым поведением фильтрации.

Другими словами, не может ли компонент ввода валюты вместе с рядом других компонентов фильтрации по умолчанию быть частью Vue? Потому что каждый использует валюту в какой-то момент, верно? Зачем оставлять другим делать одну и ту же работу снова и снова? Форматирование валюты достаточно стандартно, чтобы сделать его частью собственного пакета инструментов Vue для компонентов фильтрации, и они являются отличным базовым примером для других, чтобы научиться создавать свои собственные компоненты фильтрации.

И… в этом примере не хватает только одной вещи, чтобы быть готовым компонентом ввода валюты, и это функция i18n, которую, я считаю, Vue также должен повлечь за собой. Формат номера валюты должен меняться в зависимости от выбранной пользователем (зрителем) локали. Я имею в виду данные локали, т.е. «DE_de» для форматирования валюты и других чисел, как показано в этом Locale Explorer (который вытекает из стандарта). Добавьте это во Vue, и вы получите отличную систему компонентов форматирования валюты/числа, встроенную прямо в Vue, которую тысячам других разработчиков, использующих Vue, не нужно создавать самим, а можно использовать прямо на месте, когда они получают Vue. . Это делает Vue мощной системой шаблонов!

Если использование этого «компонента форматирования i18n» не может быть использовано в виде цепочки в качестве фильтра, как в 1.0, он должен быть подключаемым. Это тоже было бы хорошо. Это то, что делает Aurelia, и то же самое делает Twig со своими расширениями . Компонент ввода валюты все еще может быть <currency-input> .

Этот i18n и другие стандартные шаблонные фильтры действительно должны быть чем-то, что другим не нужно постоянно воспроизводить, если в этом нет необходимости. Если вы покажете мне, как сделать такой плагин, я даже сделаю для вас плагин i18n. Меня это интересует в целом! :smile:

Скотт

Потому что каждый использует валюту в какой-то момент, верно?

Не на самом деле нет. Я, например, никогда им не пользовался :) То же самое относится и ко всем другим встроенным фильтрам — некоторые из них полезны для некоторых из нас, тогда как другие просто бесполезны. Пока мы обсуждаем эту тему, в большинстве случаев я хотел использовать встроенный фильтр, но в итоге я все равно писал свою собственную версию, отображая встроенную версию мертвым кодом.

функция i18n, которую, как мне кажется, должен иметь и Vue.

Это, опять же, очень спорно. Всесторонняя поддержка i18n может быть довольно сложной, и IMO не принадлежит Vue, особенно когда большинству пользователей она все равно не понадобится.

Теперь я хотел бы поднять этот вопрос: каждый раз, когда мы пытаемся провести сравнение между Vue и другим шаблоном/фреймворком, нужно помнить одну важную вещь: в отличие от Django/Laravel/Twig, Vue по сути является клиентской библиотекой, и поэтому должен быть максимально легким. Было бы разумнее сделать его достаточно простым — при сохранении, конечно, всех основных функций — вместо того, чтобы добавлять «функции» и «утилиты» только ради так называемой «полезности» или «элегантности». Если вам нужно что-то кроме основных функций, более предпочтительным способом будет использование плагина или даже разработка собственного. Возьмем это в качестве примера: для часто встречающегося SPA i18n/currency более важен, чем маршрутизатор или менеджер состояния? Я так не думаю. И все же, vue-router и vuex не принадлежат Vue, но имеют свои собственные репозитории. Другими словами, Vue является прогрессивным .

Если вы покажете мне, как сделать такой плагин, я даже сделаю для вас плагин i18n. Меня это интересует в целом!

Я считаю, что это более разумный подход, и спасибо за ваш интерес :)

если сильно надо будет использовать i18n в некоторых областях)) думаю можно зайти в код и вручную изменить несколько названий некоторых вещей, для красоты.
Например: буквально несколько часов назад прошился butstrap.datepikker - не подключается, i18n несмотря на то, что есть такая возможность. Быстрые 60 секунд. "Вручную" заменил названия дней недели и месяцев, и все - ок! ))

@phanan - Именно из-за вашей аргументации я упомянул «плагины». Я согласен, не всем нужна валюта или функциональность i18n, а те, кто этого не хочет, могут поддерживать легкость своего приложения, но я считаю (и это во многом мое личное мнение), что Vue как система шаблонов также должна иметь такие стандартные функции. слишком. Что еще более важно, и меня это беспокоит, это не должно быть так, что всем приходится заново изобретать колеса компонентов i18n или валютного фильтра. Другими словами, так же, как Vue-Router и Vuex являются доступными дополнениями к Vue, также может быть большое количество стандартных фильтров, таких как валюта и i18n.

О, и, что интересно, в Angular, похоже, встроен i18n.

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

Angular поддерживает i18n/l10n для фильтров даты, числа и валюты.

Ember и React, похоже, пошли по пути «пусть мир разработчиков сделает это сам».
Интересное видео.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Может быть, Vue нужна только интеграция с FormatJS? VueIntl? :улыбка:

Редактировать: Это не может быть так просто, не так ли? https://github.com/learningequality/vue-intl/blob/master/index.js

Скотт

Кажется, в Angular встроен i18n.

Angular также поставляется с ng-router, который, насколько я слышал, избегает ng-community в пользу ui-router.

Теперь, если команда Angular заменит ng-router на ui-router, это приведет к серьезным изменениям и проблемам.

если они пытаются улучшить ng-router, они тратят свое время впустую, так как лучшее решение (ui-router) уже существует.

Если Vue начал поддерживать i18n, валюту и т. д. в своем ядре, то такая же ситуация произойдет и с vue.

Я нахожу встроенные фильтры удобными, но в этом вопросе я согласен с командой vuejs.

Тогда мы все согласны с тем, что фильтров нет в ядре Vue. Я также поклонник компонентизации на самом деле. Но разве Vue не может предложить фильтры в качестве основных плагинов? Нравится Vuex и Vue-Router?

Скотт

Но разве Vue не может предложить фильтры в качестве основных плагинов? Нравится Vuex и Vue-Router?

Это именно то, чем ранее поделился @blake-newman.

Привет: на странице окончательного решения указано, что разрешен только фильтр для текста
отображать {{}} (v-текст)
не для других выражений, таких как v-for="item of list | sortBy"
Или я неправильно понял?
Я имел в виду, что нужно оставить фильтр, как в 1.0, но ограничиться только одним фильтром.
за выражение

В воскресенье, 1 мая 2016 г., в 22:24, Phan An [email protected] написал:

@tomsmithgroup https://github.com/tomsmithgroup Что вы предложили
(и более того) было решено
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 для
по-прежнему поддерживается в версии 2.0.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@ yyx990803 Могу ли я сделать вывод из вашего ответа , что двусторонние фильтры не будут поддерживаться в версии 2.0?

@fnlctrl это правильно. Просто создайте свои собственные компоненты.

Я немного отойду от темы: действительно ли эти двухсторонние фильтры так полезны в производстве?
Я имею в виду, действительно ли нормально позволять пользователю вводить что-либо в поле ввода, а затем переформатировать его после размытия?
Моя бизнес-команда всегда требует, чтобы наши входные данные действовали следующим образом : вы просто не можете напечатать что-то неправильно. Так что даже сейчас с Vue мы используем jquery.inputmask для этой цели, так как мгновенное двустороннее изменение устарело (по которому я действительно скучаю...)
Я имею в виду, действительно ли есть проблема с этими двухсторонними фильтрами или люди просто слишком много думают об этом? :)

@fullfs Двусторонние фильтры широко используются в нашем производственном приложении (много <input> s) для удобства, но, как я вижу сейчас, зачем фильтровать значения в реальном времени, а не просто фильтровать их один раз, прежде чем они будут POST-ed на сервер? Рефакторинг кода займет некоторое время, но я думаю, что не пропущу их :D

Если вы хотите оптимистично обновлять пользовательский интерфейс (что сегодня является нормой ИМХО, особенно для мобильных устройств), вам нужно, чтобы ввод был правильно отформатирован практически в то время, когда ввод был введен.

Скотт

2-полосные фильтры действительно хороши в vue. Вы всегда можете создавать свои собственные настраиваемые компоненты, с доступными фильтрами или без них, но это требует времени. Библиотека должна обеспечивать гибкость, а также более быстрый и удобный способ работы. Включение двусторонних фильтров не помешает людям создавать свои собственные компоненты, если это необходимо, но позволит ускорить разработку, когда существующая функциональность соответствует потребностям, что происходит в большинстве случаев. Это всегда компромисс между поверхностью API и удобством. Необходимо найти баланс, и у Vue он уже есть. Избавление от фильтров кажется шагом назад от правильной точки баланса. Библиотека становится меньше, но кодовая база и шаблоны каждого проекта, которые ее используют, растут.

Если фильтры действительно устарели, возможно, было бы хорошо предоставить альтернативу, позволяющую простым способом указать синтаксический анализатор и форматировщики для директив v-модели. С помощью фильтров можно записать только эту часть примера @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)
    }
  }
})

Без 2-полосных фильтров также приходится писать

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

Таким образом, больше гибкости, но и больше кода для того же результата.

@aristidesfl - фильтры не устаревают. Мы частично выиграли битву. РЖУ НЕ МОГУ! Они будут ограничены использованием только в текстовых интерполяциях. Смотрите здесь: https://github.com/vuejs/vue/issues/2873

Скотт

Спасибо @smolinari . Я имел в виду, в частности, двухполосные фильтры.

пожалуйста вернись! нам это нужно, я согласен со всем, что вы сказали. но это так просто, мы ленивые пользователи, нам просто нужен ленивый, простой способ. так же, как держать в живых.

Может быть, должен быть способ добавить пользовательские модификаторы v-модели (http://rc.vuejs.org/guide/forms.html#Modifiers)

Они работают как двусторонние фильтры.

@ecmel согласился. Это путь.

Тогда открывайте вопрос с запросом функции :)

@ecmel аналогичная идея, хотя и описанная как модификаторы типов, обсуждалась здесь .

@rpkilby Это обсуждение также закрыто, может быть, нам следует открыть новое для пользовательских модификаторов v-модели.

Больше не умеет:

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

Ограничение фильтров до {{ }} кажется странным, много раз вы хотели бы использовать фильтр в привязке атрибута (без передачи реквизита), и мы больше не можем использовать {{ }} в атрибутах !

@LinusBorg Открыт https://github.com/vuejs/vue/issues/3666

Ограничение фильтров до {{ }} кажется странным, много раз вы хотели бы использовать фильтр в привязке атрибута (без передачи свойства), и мы больше не можем использовать {{ }} в атрибутах !

Они были удалены, потому что их можно легко заменить вычисляемыми свойствами и методами, а сами они имеют более ограниченный API и отсутствие возможности кэширования результатов.

Так:

• одним API меньше
• используйте одни и те же методы в шаблоне и коде JS, нет необходимости дублировать поведение фильтра для использования в коде приложения.
• вычисленные реквизиты могут быть кэшированы
• больше гибкости, потому что это всего лишь JS

псевдокод впереди:

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

Извините, я только "новенький".
Но выход из Angular 1 без фильтров кажется действительно странным и нелогичным, почему было бы лучше, чтобы каждый разработчик разработал свой собственный набор фильтров и устанавливал сами вычисляемые записи и т. Д. Лучше, чем встроенный?
И что сейчас считается лучшей практикой для фильтрации действительно большого массива по объектам в элементе. С angular это была только одна строка кода. Можно было отфильтровать массив для ввода поиска, и это сделало бы всю магию, которая должна быть функцией фреймворка.

И что сейчас считается лучшей практикой для фильтрации действительно большого массива

Что такое действительно большой массив? Теоретически вычисляемое свойство также подходит для фильтрации.

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

почему было бы лучше, если бы каждый разработчик разработал свой собственный набор фильтров и устанавливал сами вычисляемые записи и т. д. лучше, чем встроенный?

Раньше я думал так же (и почему я начал тему), но с тех пор, как я узнал, что создавать такие фильтры самостоятельно несложно, и что есть ооочень много вещей, которые может захотеть каждый разработчик. как фильтр (или вычисляемое свойство), я пришел к выводу, что не так уж и важно не иметь встроенных фильтров.

Скотт

В моем случае это равно> 10 000 строк в json, предоставленных базой данных firebase.
Я понимаю, почему вы можете так подумать и решить отказаться от этой функции, тем не менее это создает дополнительные проблемы для разработчиков.

Я разветвил скрипку, чтобы она соответствовала моей структуре данных:
https://jsfiddle.net/nw5yhLwv/
Итак, мне нужно вручную закодировать поиск строки в моем объекте?

Я не понимаю вашего вопроса. Прости. Скрипка похожа на ту, которую я разместил.

Скотт

Вычисление против фильтров

Фильтры, возможно, плохо влияют на производительность, поскольку они вычисляются для каждого рендеринга (точно так же, как и методы), а вычисляемые свойства очень просты и пересчитываются только тогда, когда это необходимо, иначе результаты кэшируются, что означает, что Vue может летать.

Ой. а у нас есть и то, и другое. 😄

Скотт

Эй, я немного поиграл, и теперь я понял, это отличная идея! 😄

Я закрою эту ветку сейчас, так как дискуссия по этому поводу давно закончена — Vue 2.0 отсутствует уже пару месяцев, и критика по поводу удаления фильтров в значительной степени утихла.

Дальнейшее обсуждение в этой теме непродуктивно. Если вы видите новый взгляд на тему, которая, по вашему мнению, нуждается в обсуждении, пожалуйста, откройте новую тему.