Vue: [提案] Vue2.0-フィルターを戻してください

Gitterチャットから最初に得られたポイントを明確にする： debounceはフィルターではなく、人々が失うことに興奮していなかった2.0の変更の1つにすぎませんでした。

@JosephSilberの好意によるdebounceは、フィルターであり、 v-modelパラメーターでもあります。

@ agc93に感謝します。 その点を削除しました。

スコット

最悪の場合、これに対処するための小さなプラグインを考え出します。 フィルタについては、 https：//www.npmjs.com/package/babel-plugin-pipe-operatorがあり
問題は、これはbabelコンパイルなしでは機能しないことです

いくつかの変更についても、私はあまり興奮していません。 フィルタの場合、グローバルミックスインを登録することで簡単な代替手段があるようです。 ただし、複数化などの非常に単純なタスクのために、コンポーネントのすべてのメソッドスコープを汚染するという考えはあまり好きではありません。 ただし、双方向フィルターを使用したことはありません。

フィルターはとても便利で美しいものでした。 vueが常に正しく行った2つのこと（これまでのところ）。

vue 2.0の投稿を読んだとき、すべての新しい可能性（特に、仮想domとサーバーレンダリング）に驚きましたが、フィルターがなくなったことにも驚き、少し悲しくなりました。

それらは、簡単に使用できてチェーン可能であるだけでなく、主に簡単に拡張でき、テンプレートで直接使用できる美しい構文を備えているため、vueの私のお気に入りの部分の1つでした。 特にv-forループと組み合わせると、完全に一致しました。

計算されたプロパティを使用して、必要なすべての小道具のフィルタリングを置き換える必要があると考えて、将来的に多くの定型文を作成するのではないかと心配しています。 ミックスインは問題の一部を軽減するかもしれませんが、それでも私はエレガンスの一部であり、vueの使いやすさが失われているように感じます。

同意する方は、説明の下にある親指をクリックしてください。 +1で17000人をスパムするよりはましです。 さらに良いことに、いくつかの意味のあるユースケースを考え出します。

私は双方向フィルターを使用したことがありませんが、フィルターが本当に恋しいです！ 計算されたプロパティを使用できます（場合によっては使用します）が、単純なケースでは、ワークフローを実際に高速化するのに便利です。

この非常に単純な例を考えてみましょう

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

2つ目は書きにくいと言っているわけではありませんが、多くの場所で使用すると、繰り返し始めることになり、他のより便利な機能で使用できるようになるまで、少し時間がかかります。

いずれにせよ、私は幸せなVueユーザーであり続け、廃止されたフィルターについての私の意見を共有します！

フィルタは再利用可能です。 データを一度フォーマットしてフィルターとして登録し、すべてのインスタンスから使用する関数を作成できます。 2.0でどうすればよいですか？

2.0でどうすればよいですか？

• 混入します
• メソッドでモジュールを分離する
• 計算されたプロップ関数を備えた個別のモジュール

アナウンススレッドにコメントを残したので、ここですべてを複製するのではなく、単にリンクします。

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

とても便利なものがあなたから奪われているという感覚を完全に理解しています。 ただし、最初に、上記のフォーラムスレッドで@chrisvfritzのコメントを読んでください。 議論を容易にするために、ここにコピーして貼り付けています。

@theotherzach Vueに情熱を注いでくれてありがとう！ 非推奨についてもう少し詳しく説明したいと思いますが、最初に自己紹介をします。 私はVueコアチームのメンバーであり、フリーランスのUIとデータの視覚化作業に常にVueを使用しています。また、他のWebテクノロジーの中でも特にVueとRailsの使用法を人々に教える教育者でもあります。 私はコードスクールを運営しているので、人々がこれらのツールの使い方を学ぶ（そして一緒に使う）のをほぼ_毎日_支援しています。

私はまた、Vue2.0でフィルターを削除することの大きな支持者の1人でした。

Vueの初心者向けのフィルターの問題

私がフィルターの廃止に賛成した理由の大部分は、実際には初心者向けでした。 学生と一緒に仕事をするとき、これは何度も出てくる会話です：

• 学生：「それで、フィルターは基本的に機能ですか？」
• メンター：「はい！」
• 学生：「わかりました。関数の括弧を付けて通常どおりに使用できますか？」
• メンター：「いや、いや、それは特別な種類の機能だ」
• 学生：「他の場所で使用できますか？計算値のように？」
• メンター：「いいえ、テンプレートでのみ使用でき、特別なパイプ構文でのみ使用できます。」
• 学生：「...なぜ？」

初心者をつまずかせる大きなことの1つは、_例外_です。 フィルタは単なる関数ですが、特別な構文が必要であり、どこでも使用できるわけではありません。 また、 ES7に統合される可能性のあるパイプ構文とは異なるパイプ構文を使用します。つまり、2つの非常に類似した演算子を使用して非常に類似したことを実行するまで、長くはかかりませんが、まったく同じではありません。 そして、そのうちの1つだけが実際にはJavaScriptです。

Utilライブラリは便利ですが、Vueは1つではありません

filterBy 、文字列と数値の変換、およびその他の特定のフィルターの場合、そうです、それらが出現するアプリケーションで役立ちます。 一般的にUtilライブラリは便利です。 また、選択できる優れたutilライブラリは数十ありますが、Vueはユーティリティライブラリではありません。 そして率直に言って、私たちが提供したユーティリティはどれもクラス最高のものではありませんでした。

通貨、日付、さらにはフィルタリング配列の処理-これらは私たちの焦点では​​ありません。 多くのアプリはそれらを必要とせず、私が取り組んだほとんどのアプリはこれらの問題に直面し、Vueが現在提供しているよりも堅牢なソリューションを必要とします（または大幅な肥大化と車輪の再発明を導入せずに提供できます）。

私のアプリでは、Accounting.jsは通貨をうまく処理し、Moment.jsは（あなたが言ったように）日付と時刻を処理し、 pluralizeは多くの複数形をうまく処理しないため、カスタム計算値がより望ましいことがよくあります。 jsonはJSON.stringifyより少し大きいです。

計算されたプロパティの利点

フィルタの代わりに計算されたプロパティを使用すると、処理された値をコンポーネントのどこでもDRYの方法で簡単に再利用できるという利点もあります。 私は自分のアプリでこれを常にしなければならないことに気づきます。 計算されたプロパティは、実装の詳細をテンプレートから移動し、コンポーネントの機能の明確な説明のみを残します。 また、グローバルに定義されたフィルターに対する利点は、そのコンピューター値の関数を確認するだけで、その機能を正確に確認および調整できることです。 配列では、JavaScriptのmap $メソッドとfilterメソッドをチェーンすると、パイプと同じ線形の処理リストが提供されますが、さらに宣言的で簡単に操作できます。

グローバルに定義されたものの有用性

すべてのコンポーネントでアクセスできる関数などを定義する必要がある場合は、 Vue.prototype.whateverIWant = mySuperCoolFunctionが最適な方法です。 個人的に、私はそれをしたくありませんでした。 私はいつもヘルパーメソッドをモジュールに入れて、必要な場所にそのモジュールをインポートすることを好みました。 ただし、グローバルの登録（あらゆる種類の）が難しくなることはないことに注意することは依然として重要です。

debounceディレクティブの場合

私は言わなければなりません、私は実際にこれであなたと一緒です！ 私は最近、すべてのVueプロジェクトを調べましたが、どこかにinputがあるすべてのプロジェクトでもdebounceを使用していました。 実際、私の過去のアプリケーションの1つだけがデバウンスを使用していませんでした。 技術的にはユーティリティ（lodashや他の多くの堅牢なプロジェクトがデバウンスソリューションを提供します）ですが、この問題は、あらゆる種類のアプリのUI開発にかなり普遍的です。 独自のデバウンス関数を作成することも簡単ではないので、ほぼすべてのプロジェクトにlodashの実装を使用したいと思います。

これについては内部的な議論が残っているので、それがどこに行くのかを見ていきます。 しかし、はい、個人的にはそうですが、他の人もそうですが、デバウンスを削除すると、 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'],
    }
  },
}

どうやら、フィルターがサポートされていれば、簡単なコードを書くことはできませんでした。
個人的には、コーディングをより楽しくするvue1.0の方法が好きです。

ボイラープレートの懸念については、それに対処する方法がいくつかあります。

1.明示的にインポート/エクスポート

上で示した@raywillのように。 もう少し冗長ですが、利点は次のとおりです。

1. Vueの機能を理解するために、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プロトタイプのアプローチが好きですが、複数のフィルターが必要な場合はどうでしょうか。

filterBy $に沿って$ orderByを使用することはかなり一般的です

<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は、現在の統合フィルターのユーティリティパッケージを提供するオプションについて話し合っています。 コードベース用のユーティリティツールを提供するリソースはたくさんあります。

コアフィルターを削除することの良い点の1つは、自分でフィルターをカスタマイズ/実装できることです。 これにより、柔軟性が大幅に向上します。

@ 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 " ect

計算されたプロパティとして割り当てる方がはるかに再利用可能であり、子コンポーネントに渡すこともできます。 フィルタリングされたデータを2か所で使用したい場合はどうなりますか？ 式に連鎖フィルターを使用する場合と比較して、テンプレートで単純な式を使用する方が、簡単で、シンプルで、信頼性が高く、読みやすくなります。

フォローしている人のために、私はここで@chrisvfritzに答えました： http ：//forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

以下は、グローバルに利用可能な少数の純粋なビューヘルパー関数のユースケースを解決します。 フィルターの取り外しに関する懸念を撤回します。 燃やす！ 🔥インターネット上の誰かの心（私の）を変えて@ 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です

コアフィルターを削除することの良い点の1つは、自分でフィルターをカスタマイズ/実装できることです。 これにより、柔軟性が大幅に向上します。

あなたはいつでも自分でそれらをカスタマイズ/実装することができました。

Vueはユーティリティライブラリではありません。 そして率直に言って、私たちが提供したユーティリティはどれもクラス最高のものではありませんでした。

私たちが懸念しているのは、テンプレートのフィルター機能を削除することです。 組み込みのフィルターを削除することは非常に理にかなっています。アンダースコアやその他のutilライブラリにプロキシすることで簡単に再作成できます。 次に、誰かが現在のすべての組み込みフィルターを再作成する単一のプラグインをリリースすることさえできます。

フィルタの代わりに計算されたプロパティを使用すると、処理された値をコンポーネント内のどこでもDRY方式で簡単に再利用できるという利点もあります。

もちろん、他の場所で再利用する必要がある場合は、計算されたプロパティを使用できます。 ただし、そうでない場合でも、フィルターの方がはるかに便利です。

私が上で共有したそのリンクに私が投稿した他のいくつかのポイントがあります。

ES7で提案された構文のように動作するフィルターの構文をサポートしてみませんか？ それは人々が彼らの最愛のフィルターを使い続けることを可能にし、そしてそれを未来が保持するかもしれないものと一致させるでしょう。 最終的に、ES7パイプがある場合、APIを変更せずに内部実装を切り替えることができます。

ES7パイプは承認されていますか、それとも多くの変更が加えられていますか？

理論的には変更される可能性がありますが、安定しているようです。
ステータス：mindeavor / es-pipeline-operator＃33

@JosephSilber @ young-steveo @thelinuxlichパイプ全般の価値については、同じページにいると思います。 😃2.0の新しいコンパイラの利点の1つは、生成されたレンダリング関数コードをBabel経由でパイプできることです。 これについてはさらに調査する必要がありますが、 |>が勢いを増し、そのためのBabelプラグインが開発されると、アプリ内のどこでもパイプを使用してメソッドを幸せにチェーンできるようになることは想像に難くありません。 LiveScriptやその他の関数型言語の大ファンとして、私は間違いなくその価値を認識しています。

このパイプライン演算子はステージ0でもありません

@thelinuxlichはい、彼らはまだTC39のチャンピオンを待っていると思います。 😞

@ rigor789それは私も言及したかった選択肢の1つです！ JavaScriptのパワーにより、選択した表現力を実現できます。テンプレート内にフィルタリングロジックを配置するよりも、JavaScriptの方が優れています。

@ yyx990803 1人のユーザーの名前が更新された場合、次の場合に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);
    },
  },
});

前者は1つのオブジェクトのみを再レンダリングし、後者はリスト全体を再計算するように見えますか？

@rpkilbyは同等ではないようです。 それはもっと似ているでしょう：

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

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

それでも、メソッドをフィルターとして使用するというアイデアは好きではありません（直感的には間違っているように見えますが、実際には説明できません）。 いずれにせよ、フィルターを利用可能にする他の方法について話し合ったので、+ 1します。

このスレッドで提案されているものは、フィルターの表現力と簡潔さにさえ近づいていません。 そうではありません。

そしてそれは私を本当に悲しくさせます。 フォーラムのスレッドで言ったように、私にとって、これはVueVueを作るものの大きな塊を取り除きます。

あなたが私を探しているなら、あなたは私が聞こえるようにすすり泣いている隅にいるのを見つけることができます😟

まさか、この変更は優れたJavascriptコーディングを促進します。それに対処してください:)

それで、私は@ yyx990803と長い議論をし

<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の魅力の1つは、（いくつかの）バッテリーが含まれていることです。 これらのいずれかを失うことは本当に悲しいことです-私の意見では、両方ともVueを際立たせます。

スレッドを読むと、フィルターに関する懸念のほとんどは、Vueにデフォルトのフィルターがあり、実際には関数自体ではないという事実であるように思われます（または、そうではありませんか？まだわかりません）。

@ blake-newmanのフィルタープラグインの考え方が好きで、事前に作成された例があるはずです。 他の人が他のフィルターを思いついた場合、それらはプラグアンドプレイである必要があります。 それは素晴らしいことです。 私は、フィルターの作成がユーザーランドの責任であることに完全に同意します。

まだ必要なのは、パイプとチェーンの機能、および元のフィルター機能のグローバル性です。 グローバル性に関する懸念は@ yyx990803でカバーされました。 パイプとの連鎖はどうですか？ これは、テンプレートを読み、出力として何が期待されるかを理解するのに役立ちます。 パイプとチェーンについては上記で説明しました。 それでもできますか？ なぜそれはまったく悪いことなのですか？ デザイナーにとってはゴールドです！ フィルタは設計者のツールであり、JSプログラマーのツールではありません。 ですから、私の本では、より良いJSを書くという議論はボードから外れていますが、なぜそれが望まれるのかは理解できます。 しかし、デザイナーとして、私もより良いコードを書きたいと思っています。フィルターを使用すると、美しくできます。 ：笑顔：

スコット

連鎖に関することは次のとおりです。フィルターは主に2つの目的で使用されます。

1. テキストのフォーマット;
2. 配列の処理。

テキストをフォーマットする場合、90％以上の場合、単一のユーティリティメソッドのみが使用されます。 この場合、連鎖はそれほど問題にはなりません。

配列について：配列処理は実際にはロジックであり、JavaScriptに適していることをすでに指摘しました。 複数の連鎖配列フィルターを使用すると、単純な場合は問題ないように見えますが、それぞれに複数の引数を使用すると見苦しくなります。 また、実際にはすべきでないときに、テンプレートにあまりにも多くのロジックを入れることをお勧めします。 また、柔軟性がありません（処理された値を簡単に取得することはできません）。 比較すると、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-あなたの例は問題を例示していると思います。 繰り返しになりますが、私は最高のJSプログラマーではありませんが、 filteredThingsが実際に何をしているのかを知るためにJSプログラマーである必要はありません。 私にとって、それは悪い習慣です。 ：smile：フィルタリングメソッドがグローバルであるという事実は、メソッドが何をするかを見つけるために、ドキュメント、コードを検索するか、出力を解読する必要があることも意味します。 あまりエレガントではありません。 右？

じゃあ良いよ。 `filterByOrderByAndLimit 'のようなメソッド名を持つことができます。 議論はどうですか？

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

それは正しいでしょうか？

もしそうなら、それは実行可能かもしれません。 それでも、見栄えは良くありません。

そして、今はfilterByとOrderByだけが必要です。 それを行うために別の方法も必要ですか？ 次に、通貨の書式を追加します。 別の方法？ テンプレートのフィルターチェーンにより、プレゼンテーションの操作が柔軟で表現力豊かになります。 この懸念は、メソッドではまだ適切に対処されていません（そして、知識が不足しているため、メソッドをよりよく理解することができません）。

これは可能ですか？

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

テンプレートであまりにも多くのロジックを実行することは避けるべきものであることに同意します。 ただし、フィルターチェーンと、アプリのコンポーネント/テンプレートの任意の場所にフィルターを簡単に挿入できる機能は素晴らしいコンセプトであり、最初からフィルターを追加したのには理由があります。 その理由は何でしたか？ あなたがそれらに名前を付けることができれば、私は彼らが「しかしそれは悪い習慣を助長する」よりも1マイル多くのお金を賭けるでしょう。

Vue自体と同じように、柔軟性を可能にするものはすべて不適切に使用される可能性があります。 inline-templateの主な論拠は、柔軟性があり、Vueをさまざまな方法で使用できるようにすることでした。 フィルタは、Vueの内部であり、Vueの外部での使用方法に影響を与えないことを除けば、それほど違いはありません。 それでも、それはその重要性を切り下げません。 多くの人が、これはアップグレードするのはダメだと言っていることを忘れないでください。 それはとても重要です！ ：笑顔：

新しい方法には、古い方法と同じ属性が必要です。

• 連鎖可能
• グローバル
• テンプレートに追加して、テンプレート内のデータがどのように操作されるかをうまく表現します

（私は何かを忘れましたか？）

それがすべてできるなら、私は誰もがかなり満足するだろうと確信しています。 私は個人的にそれがメソッドで起こっているのを見ることができません（まだ）。

スコット

@smolinari

1. テンプレートに入れるロジックを少なくする必要があることを明確に述べました。 これはあなたがそれを好むかどうかにかかわらず私の意見です。 明らかに、あなたは自由に反対することができますが、推奨されるベストプラクティスに反して作業したい場合は、私はあなたを助けることができません。
2. 与えられた（1）-複雑なロジックはJavaScriptで実行する必要があるため、チェーンが問題にならない理由を説明しました。
3. また、グローバルに利用可能なメソッドを追加する方法の例も示しました。
4. 必要なものと同様のカスタムチェーン構文については、 @ rigor789の例を参照してください。
5. フレームワークの目標は、すべての人を喜ばせるのではなく、フロントエンドアプリケーションを開発するための最良の方法であると_I_が信じているものを提供することです。 したがって、「この機能を返送しないとアップグレードしません」は使用しないでください。機能しません。

この新しいアルファリリースを1週間試してから、（あなたの練習に基づいて）本当に価値のあるコメントを付けてみませんか？ たぶん、既存のアプリをリファクタリングして、何が不可能だったか、何が改善されたか、何が悪化したかを知らせてください。そうすれば、よりよく話し合うことができます。 それは私が思うすべての人にとって役立つでしょう。

@ yyx990803-1に同意しました。同意します。 ：smile：私はそれがとても多くの愛を得た何かを取り出すための適切な理由であることに同意しません。

では、時間の経過とともに、実用的なJSは実用的なHTMLよりも優れていると判断したと思いますか？

アップグレードしないことのノーゴーの議論は、他の人が言ったことです。 私はただそれを伝え、軽減しようとしています。

私からの最後の議論。 これをユーザーの目から見てください。 Laravelのようなシステム、またはVueを組み込んだ他のMVCまたはMVVMシステムがあるとします。これにより、そのシステムのユーザーは独自のコンポーネントを構築することもできます。 このフィルターは、いわば学習曲線を単純化し、そのシステムのユーザーがJSに触れることなく多くのことを実行できるようにします。 私はVueのファンです。なぜなら、JS以外のプログラマーがまだ多くのことを成し遂げることができたからです。 これは私がReactとJSXが好きではないのと同じ理由です。 その組み合わせは、時間が経つにつれて、Vueよりもはるかに小さなユーザーベースになります。 私はそれにお金を賭けます。

また、本当の柔軟性はJSにあることも理解しています。 それでも、Vueの柔軟性をJSだけに頼らないでください。 誰もがキラーJSプログラマーであるとは限らないことを覚えておいてください。 実際、ほとんどの人はそうではありません。 フィルターはそれらの人々のために多くのことを成し遂げるための素晴らしい方法であり、それはさらなるJS操作への素晴らしい足がかりでした。 フィルターはそれを成し遂げることができませんか？ JSメソッドについて詳しく説明します。

Ok。 私からは十分です.....私は終わりました。 そして、とにかく聞いてくれてありがとう。 Vueはまだ素晴らしいです！ ：笑顔：

@ azamat-sharapov-良い点。

スコット

JS内の悪い習慣を正当化しようとしている人々を見ると、私は悲しくなります。 本当に、あなたはプロである必要はありません、ただ基本的な宿題をするだけです（またはそれは最近もう基本的ではありませんか？）

私がfilters-inside-methodsで抱えている問題は、セマンティクスです。

おっと、フィルターは静的関数のようなものですが、メソッドは非静的関数です。

フィルタは、メソッドとは非常に異なるセマンティクスを伝達します。 最大の違いは、フィルターはthis使用できないことですが、メソッドは使用できます。

Vue.prototype.filtersを使用しているときの@ yyx990803は機能しますが、 Vue変更すること

グローバルは良い習慣ではないので、それは良い習慣のようには見えません。 推奨されるアプローチは、ヘルパーメソッドを明示的にインポートすることです。 プロトタイプへのアタッチは、メソッドを明示的にインポートしたくない場合の回避策です。

セマンティクスに関しては、フィルターはとにかく造られた概念です。 JavaScriptでは、文字列を大文字にするためだけに別のセマンティクスを発明することはありません。関数を呼び出します。 そして、それがJavaScript関数です。

主に「JS内の悪い慣行を正当化しようとしている」というコメントのために、私の個人的なポイントを明確にするためにもう1つコメントをします。 私は確かにそうしようとはしていません。

Vueは単なるテンプレートシステムではありませんが、テンプレートシステムでもあり、その役割から離れようとしているのではないかと思います。 したがって、テンプレートエンジン/システムとして、テンプレートシステムに期待できることの非常に成功した例としてTwigテンプレートエンジンを取り上げます。 ドキュメントに「テンプレートデザイナー向け」セクションと「開発者向け」セクションがあります。 テンプレートシステムとして、Twigは、フィルターを含むデフォルトの動作がぎっしり詰まっているため、テンプレートデザイナーにとっても強力です。 これにより、開発者以外の人は、PHPを直接知らなくても、テンプレートシステムを大量に使用できます。 彼らは、Twigが提供するものとその使用方法を学ぶ必要があります。 私もVueでこれを探しています。 ドキュメントの「Vuefortemplatedesigners」セクションも見たいです。 ：笑顔：

また、Twigの拡張性も非常に重要です。 ストックバージョンで入手できないものがある場合は、追加することができます。 それが開発者が介入するときです。素晴らしいことは、拡張機能を共有できることです。つまり、1回だけ実行する必要があります。

これらの2つのレベルのデザイナー/開発者のもう1つの優れた点は、はるかに幅広いユーザーベースを獲得できることです。 はるかに広く、これは。と同じです。 そして、振る舞いのデフォルトが十分でないとき、それは彼らが進んで基礎となる言語を学び始めるときです。 そして、それは彼らがベストプラクティスと残りを学ぶときです。

VueはJSを学ばなければテンプレートエンジンにはなれないと言っているのなら、それは市場価値をかなり下げていると言えます。 あなたが言うなら、あなたは他の人がプラグインとしてテンプレートエンジンのためのそれらのツールを素晴らしいものにすることができるようにドアを開いたままにします。 しかし、その後、誰もがテンプレートシステムにあるべきもののために戦うことになります。 それは逆効果の私見でもあります。

フィルタの例であるEvanについて話している生徒の中で、JSを学んでいる人ですか、それともテンプレートエンジンを学んでいる人ですか。 後者の場合、会話は違ったものになるでしょう。

いずれにせよ。 私はまだVueが勝利のシステムだと思います。 私の考えが、他の人にVueの役割について何らかの形で違った考えをさせるかもしれないことを願っています。 ：笑顔：

スコット

@ yyx990803フィルターが造られた概念である場合、なぜそれらは最初に造られたのですか？

<template>の内部では、 $dataやabcなどのすべての外部変数がthis.$dataとthis.abcに変換され、プレーンなjs関数が定義されているためだと思いますコンポーネントの外部は参照できません。 この制限を克服するためにフィルターが導入されました。

その制限はまだ存在します---私は正しいと思います---制限を削除するには、開発者がthis.abcを参照するためにthis.abcを明示的にコーディングし、で参照されるようにjs関数にアクセスする必要がありますjs。

しかし、それはあまりにも強力な機能であり、悪用されやすく、古いコードを移行するのは苦痛になります。 現在の構文は私にはそれよりずっと良く見えます。

フィルタは基本的にjs関数であり、コンポーネントにインポートする必要があることに同意します。 メソッドと同じ場所で定義されているのが好きではありません。

皆さんこんにちは。 私はスレッド全体を読みました、そしてこれは私が思うものです。

• orderBy filterByやその他の組み込みフィルターを見逃すことはありません
• 誰もがまだ持ちたいのは、テンプレートのパイプ演算子です
• コアチームは、パイプ演算子を備えたes7機能が追加されることに加えて、ロジックはテンプレートではなくjavascriptに保持する必要があると述べています。

簡単な要約として、 jsがネイティブのパイプ演算子を実装するまでは良い解決策になると思いますが、パイプ演算子をプラグインとして使用し、2.0バージョンをそのままにしておくことです。 だから、ユーザーはすることができます

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

新機能の実装を待つ間、廃止されるなどの警告が含まれる可能性があります。 誰でもそのプラグインを実装できることは知っていますが、Vueチームによって提供され、維持されていれば、それは可能でしょうか？

私は間違っているかもしれませんが、Vueがプラグインをコンパイラーに混乱させることはないと思います。

@ azamat-sharapovもちろん違います。 私はそれがVueコンパイラを台無しにするだろうとは思っていませんでした：open_mouth：

@YerkoPalma私は絶対にパイプ演算子を_大好き_です。 関数型言語で執拗に使用しており、JavaScriptで使用するのが待ちきれません！ _しかし_、Vueにフィルターがなかったと想像してみてください。 フロントエンドフレームワークがJavaScriptの構文を拡張することを要求しますか？ これは、UIフレームワークではなく、BabelまたはJSへのコンパイル言語のドメインです。 私がよく使うように、LiveScriptのような言語を使用したい場合は、使用できます。 しかし、ここでの問題はVueではありません。 それはJavaScript自体にあり、私たちはそれを修正するためにここにいるわけではありません。

さらに、2.0でのレンダリングの結果をBabelを介して希望どおりにパイプできる場合は、必要に応じて、TC39で追跡されていないプラグインを使用することもできます。これは、JavaScriptのどこでも、代わりに一貫して使用できます。テンプレートだけです。 したがって、パイプが必要な場合は、パイプを使用できる可能性があります。 そして、今日1.xでそれを使用することができます。テンプレートで使用するパイプは、Babelのものとは異なる優先順位と動作を持つ可能性があることに注意してください。

@smolinari他。 私が聞き続けている2つのフレーズ（およびそのバリエーション）があります：

• 「開発者のこと/ユーザーの視点」
• 「初心者のことを考えて」

どちらも、私たちがこれらのグループについて考えていないという仮定を暗示しています。

これについては前に述べましたが、繰り返しが必要だと思います。 コアチームの_全員_は、デザイナー、フロントエンド開発者、または両方の組み合わせのいずれかです。 私たちは毎日これらのツールを自分の仕事に使用しています。 Vue2.0も使用します。 私を信じてください、私たちはそのことを考えています。 😉

初心者の方はこちらでケースを作りましたが、もう少し詳しく説明していきたいと思います。 私は教育者です。 そして、私はフィルターを排除することの支持者であり、_初心者のことを考えています_。 私は個人的に何百人もの人々、おそらくは千人以上の人々に、通常はゼロからWeb開発を実践する方法を教えてきました。 以前のコーディング経験はありません。 私はこれを中学生、高校生、大学生、プロの大人、そして高齢者と一緒に行いました。

その観点から、フィルターは最初は刺激的な魔法のように見えるかもしれませんが、限られた利便性のためにより複雑なものを導入することにより、最終的には学生の学習を遅くします。 彼らがAngularやVueに参加したことがなく、この会話が逆転した場合（2.0でそれらを_紹介_しようとしていた）、なぜそれらが必要なのか、いつ使用すべきかを説明するのは難しいでしょう。

2.0で非推奨の話が出る前は、コードスクールのカリキュラムからフィルターを削除していました。これは、フィルターが初心者にとって良いことよりも害を及ぼしているという十分な証拠を集めたためです。 むしろ、メソッドや計算されたプロパティなど、より用途の広いVue機能の経験を積んでほしいと思います。 フィルターを使用すると、悪い習慣を見つけやすくなるため、フィルターの使用をお勧めしませんでした。

それがこれらの2つの苦情を寝かしつけることを願っています。 わかります。 😃

しかし、Vueにフィルターがなかったと想像してみてください。 フロントエンドフレームワークがJavaScriptの構文を拡張することを要求しますか？

もちろん、前述のTwigのように、フィルターは_templates_にとって非常に自然なので、私はそうします。 パイプ演算子を使用することは、テンプレートに口ひげの構文を使用することと同じくらい自然なことだと思います。つまり、口ひげはhtmlではなく、javascriptでもないので、削除しますか？ パイプ演算子との違いは何ですか？

「子供たちについて考える」という議論はばかげている。 私の知る限り、VueはJavaScriptを教えるために設計されたものではなく、フロントエンドの開発者がやり遂げるために設計されたものです。 後者の場合、フィルターは素晴らしいです。

彼らがAngularやVueに参加したことがなく、この会話が逆転した場合（2.0で紹介しようとしていた）、なぜそれらが必要なのか、いつ使用すべきかを説明するのは難しいでしょう。

私は非常に同意しません。 私は2005年からDjangoと呼ばれるPythonフレームワークを使用しており、そのテンプレート言語（後に生まれたほとんどのテンプレート言語のインスピレーションとなっています）には、最初からフィルターがあります。 10年以上フロントエンドの開発者と一緒に使用した後、私はそれらの美しさと有用性に感謝するようになりました。 この構文がなくなるのを見るのは悲しいでしょう。

（Djangoがフィルターで行うことは次のとおりです：https：//docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference）

@Uninenはあなたの口調に

サーバー側のテンプレート言語に類似している場合、注意すべき重要な点の1つは、サーバー側のテンプレート言語には、Vueテンプレートと同じ量の柔軟性がないことです（計算されたプロパティがなく、式が制限されています）。 また、静的な文字列を出力するというまったく異なる目的で構築されています。 Vueテンプレートは、インタラクティブDOMの表現です。双方向バインディング、イベントハンドラー、コンポーネントプロップなどがあります。 フィルタは、Vueコンテキストの非常に限られたユースケースにのみ適合します。今日、どこにでもフィルタを許可することは悪い考えだと思います。たとえば、v-model、v-for、v-onのフィルタは、良いよりも複雑になります。

考えられる代替案の1つは、フィルターを保持することですが、テキストの補間にのみ使用できます。つまり、ディレクティブではなく、 {{ }}内でのみ使用できます。

興味深い参考資料として：Angular 2にはまだフィルター（「パイプ」に名前が変更されています）がありますが、リストフィルターフィルターも意図的に削除されています。

私の言葉で申し訳ありませんが、誰かを侮辱するつもりはありません。

私にとって、フレームワークの目的は、難しいことを実行し、これらのツールを使用する開発者が簡単に見えるようにすることです。 私はまだ構文を打ち負かすことはできないと主張しており、繰り返しになりますが、それがうまくいくのを見るのは悲しいことです。

私は内部のメカニズムの多くを知りませんし、理解していませんが、ユーザーの観点からは、実用性は純粋さを上回ります:)

関連するメモでは、このコミュニティにどれほどの情熱があるように見えるかを見るのは興味深いことです。 私にとって、Vueは新鮮で活気に満ちたツールでした。おそらくそれが、私自身がこの特定の小屋の塗装に参加しなければならなかった理由です:)

別のデータポイントの場合、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にはdeveloperstemplateデザイナー用のutilsが必要なので、lodashやmomentなどを常に必要とする必要はありません。npmからutilsをインストールするだけで使いやすくなりますが、古い呼び出し構文は保存されます。テンプレート。
しかし、フィルターについて1つの重要な考えを行う必要があります。つまり、vuexのゲッターのような純粋関数が必要です。

サポートが簡単で、usereuseextendも簡単で、テンプレートをよく見ることができます。

必要なのは、明確なアップグレードパスと、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の初心者向けのフィルターを完全に除外するのは悪いことです。 なぜVueのようなLaravelコミュニティなのか？ シンプルでパワフルだからです。

フィルタを完全に削除する場合は、_ "テンプレートデザイナ" _の代わりに、配列を並べ替えたりフィルタリングしたりする必要はありません。コードフォームの例を入力して結果を取得するだけです。

プログラマーは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)
  }
}

ですから、このタイプの人々のために複雑なことをする必要はありません。そこに簡単な解決策を与えることができ、開発者にとってそれが良いのであれば。

考えられる代替案の1つは、フィルターを保持することですが、テキストの補間にのみ使用できます。つまり、ディレクティブではなく、{{}}内でのみ使用できます。

これは非常に良い妥協案だと思います。 すべての人を満足させるわけではありませんが、これまでにフィルターを使用したのはそれだけであり、現在、フィルターがそれ以上のことを実行できるのは奇妙なことです。

フィルタを使用し、双方向フィルタを効果的に削除することで複雑さを軽減したい場合は、便利なテキストフォーマットが可能になります。

私の意見では、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のようにちょうど一般的なlibとして使われます。

パイプについては、シンタックスシュガーです

物事の事| filterBy'foo '| orderBy'bar '| limitBy 5

にとって

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

読みやすいですか？

2つのdiffテンプレートにデータを渡す必要がある場合、1つのデータに対して2つまたは3つの変更を保存しますか？

それが次のようなものである場合：

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

私は状況を抽象化しませんが、1つまたは2つのテンプレートで使用する場合はどうなりますか？ 10個または100個のオブジェクトのデータを保存する必要がありますか？ メモリ使用量を増やしますか？ はい、ヘルパーメソッドを使用してテンプレートで使用できますが、JavaScriptから遠く離れた_ "テンプレートデザイナー向け" _の場合は、タイトルのようなものを使用します。 padLeft 10であり、関数呼び出しに変換する必要があります。簡単で機能的です。

差分の人について考えてみてください。開発者は差分の方法でそれを簡単に行うことができますが、他の人はそれを簡単にしたいと思っています。

もう一度言いますが、テンプレートのロジックが多すぎるとアンチパターンになります。 特定のDSL（フィルター）を学ぶ代わりに、Javascriptを学ぶ必要があります。

@thelinuxlich JSXを使用するだけで、双方向バインディングやその他のいくつかの機能でReactを取得できます。

しかし、Vueを使用すると、javascriptを知らない人でも、googleを使用すると何かを実行できます。パイプが嫌いな場合は、使用しないでください。 次のようなものを追加できます

Vue.config.pipeFuncCall = true

そして、あなたはそれをオン/オフにすることができます、しかし何人かの人々にとってそれは簡単です。

_もう一度言いますが、JS開発者はVueを使用できるだけでなく、Vueの最も強力な側面です。_

標準の一般的なフィルターが必要ですが、別のlibにあり、vueに追加して使用するのが簡単です。

または、VueをASMのようなものにし、優れた開発者だけがそれを使用できるようにしたいですか？

皆さん、Vueコアチームが下した決定は非常によく説明されていると思います。 同じことを何度も繰り返して、もしあれば、何か新しい価値のあるものだけでコメントすることはできませんか？

たとえそれが言語の原則を傷つけたとしても、非JS開発者にとってより簡単であることがVueのコア原則の一部であるなら、私はあなたに同意しますが、おそらくそうではありません。

前にも言ったように、フィルターは廃止されても大丈夫ですが、便宜上それらを見逃すことは間違いありませんが、非常によく似たフィルターシステムをプラグインとして導入できることは間違いありません。

少し前に概念実証の例を示しました。これは、計算された小道具やインラインで使用できます。

<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つは、双方向フィルターです。 双方向フィルターは、他の提案されたソリューションで複製するのが最も難しいフィルターです。

1. そのフォーラムスレッドに投稿したこの簡単な例を考えてみましょう。 これに計算されたプロパティを使用すると、2つの主な欠点があります。
   
   
   
   1. 値ごとに新しい計算プロパティを作成する必要があり、その結果、大量の定型コードが生成されます。
   
   
   2. さらに悪いことに、計算されたプロパティはネストすることさえできません。 より複雑なオブジェクトグラフがある場合は、計算されたすべてのプロパティが最上位にある必要があります。 どの計算されたプロパティがどのネストされた値を追跡するかを常に追跡するために、より多くの認知的過負荷を必要とする長くて冗長なプロパティ名になってしまいます。
   
   

このユースケースを「些細な」または「それほど複雑ではない」として却下することは逆効果です。 私はこれを中規模および大規模のアプリケーションの両方で使用しました。 それは驚異的に機能しました！ デモは必然的にシンプルですが、テクニックはしっかりしています。

1. これは、この例のようにv-forの配列を処理する場合、さらに混乱します（ここでも意図的に単純です）。 配列を反復処理しても、計算されたプロパティに頼ることはできません。 これを回避する唯一の方法は、配列内のアイテムごとに個別のコンポーネントを用意し、さらにボイラープレートを追加することです。

この例をフィルターと比較してください。

`` `js
'some-currency-filter'から通貨をインポートします。
'products-stub'から製品をインポートします。

新しいVue（{
el：document.body、
データ：{製品}、
フィルタ：{通貨}、
}）;
`` `

フィルタのないものへ：

`` `js
'some-currency-filter'から通貨をインポートします。
'products-stub'から製品をインポートします。

新しいVue（{
el：document.body、
データ：{製品}、
コンポーネント：{
製品： {
小道具：['製品']、
計算：{
価格： {
得る（） {
戻り通貨.read（this.product.price）;
}、
set（value）{
this.product.price = currency.write（value）
}
}、
運送： {
得る（） {
通貨を返します。read（this.product.shipping）;
}、
set（value）{
this.product.shipping = currency.write（value）
}
}、
取り扱い：{
得る（） {
戻り通貨.read（this.product.handling）;
}、
set（value）{
this.product.handling = currency.write（value）
}
}、
割引： {
得る（） {
戻り通貨.read（this.product.discount）;
}、
set（value）{
this.product.discount = currency.write（value）
}
}
}
}
}
}）;
`` `

上記のどれを書きたいか知っています。

_{（これは、計算されたプロパティファクトリを作成することで少しクリーンアップできる可能性がありますが、これらは必要以上に冗長であるという点が残っています）}

コアチームはフィルターパイプ構文に断固として反対しているように見えるので、 v-modelディレクティブにfilterパラメーターを導入することは可能でしょうか？

filter paramを使用すると、上記のJSの最初のエレガントなバージョンを維持し、マジックパイプ構文の代わりにparamを使用するようにテンプレートを書き直すことができます。

<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の完全な機能を欠いていることは明らかです。 フィルタを置き換えるには、パラメータや修飾子を組み合わせた1つのカスタムフィルタディレクティブで十分な場合があります。

私はあなたの問題を解決するためにそれを試みたので、建設的なままにしましょう。 貢献して前進するよりも、解決策を打ち明ける方が常に簡単です。

@JosephSilberあなたはリラックスする必要があります。 「とんでもない」というのは強い言葉です。

こんにちは、テンプレートの乱雑さを減らすことによって動機付けられたフィルターを削除していますか、それとも深刻な影響を及ぼしていますか
2.0の技術的な実装？ 以前の視覚効果の問題である場合は、許可するのはどうですか
今のようにフィルタリングします（ただし、新しいjavascriptフォームを使用します）
ただし、v-for = "i of list | orderBy（ '​​key'）"のように、式ごとに1つだけに制限します（パイプ記号は1つだけ）
これにより、2.0でのフィルター処理がより簡単で予測可能になり、視覚的にすっきりします。
{{}}のフィルター解析があるので、他の式でそれを許可することは理にかなっています。
これは、既存のすべてのユースケース/関数（双方向フィルタリング、v-for内のアイテムなど）に対応します。
複数のフィルターの既存の使用法は、所有者によって簡単に1つにマージ/アップグレードできます。

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

個人的には、この例のファクトリは作成しません。これらの各プロパティは実際には個別の関心事であり、現時点では同じようにしか見えないためです。 フィルタを削除すると、その1つのコンポーネントがどれほど複雑であったかがはるかに明確になります。 それはあなたが定型文として見ているものです。

そして、これがコンポーネントが_存在する_理由の大きな理由です。 複雑さを管理可能な懸念に分割すること。 コンポーネントを見ると、コンポーネントが実行しているすべてのものが作業メモリーに簡単に収まる必要があります。そうしないと、開発がはるかに遅くなり、エラーが発生しやすくなります。 フィルタの構文の背後に複雑さを隠しても、その複雑さは取り除かれません。

これを実証するために、問題が実際の変化する要件を満たしている場合に何が起こるかを見てみましょう。割引が価格+送料+処理よりも大きくなることを許可しないと決定したとします。 または、取り扱いはX量を超えてはなりません。 または、割引フィールドは通貨ではなくパーセンテージにする必要があります。 または、合計が一定額を超える場合は、最小割引が自動的に適用されます。

追加のオプションと条件付きロジックを使用して、フィルターをより複雑にしたくなるかもしれません。 フィルタのAPIと内部ロジックを更新するときは、変更がフィルタを消費する他の何かにどのように影響するかを考える必要があります。これが共有フィルタの場合は、現在のコンポーネントの外部でも可能です。 そのため、アプリに変更を加えることは困難を感じ始める状況にあります。 そして、それはすべて、共有の2つのフィルターにより、内部コンポーネントの状態をコンポーネントの外部に委任し、コンポーネントの境界に違反し、結合を増やし、コンポーネントで作業するたびに考慮する必要のある複雑さを隠すことができるためです。

個別に定義された計算プロパティまたはバインドされた小道具を使用して、物事を複数の個別に複雑でないコンポーネントに分割することにより、変化する要件に合わせて1行を更新することがよくあります。 追加のオプションや条件はありません。 スケーリングの複雑さを満たすためのリファクタリングはありません。 コンポーネントの外側、またはその単一のプロパティの外側でさえ、何も考える必要はありません。 アプリケーションは最初から作成されたものであり、今でも簡単に考えて更新できます。

この場合、フィルターを最初に魅力的なものにしているのは、複製の治療法として手が届きやすいことだと思います。 しかし、それが偶発的である場合、複製は定型的ではありません（つまり、実際の問題が必然的に発生し始める前に、コードはたまたま同じです）。

そして、私はそれをサンディメッツよりも良くすることはできません：

複製は間違った抽象化よりもはるかに安価です

@chrisvfritzフィルタは、ビジネス要件とはまったく関係ありません。 フィルタはデータをフォーマットするだけです。 それでおしまい。 彼らはそれをいかなる方法、形、形でも操作しません。 filter="currency"は、概念的にはnumberパラメーターと同じです。 ビジネス要件は、明らかにフィルターで処理されるべきではありません。

割引が価格+送料+手数料よりも大きくならないようにする必要があると判断したとします。 または、取り扱いはX量を超えてはなりません。

次に、適切な検証モジュール、àla vue-validatorを使用します。 通貨フィルターは、基本的な値を表示するだけで、関係なくそのまま残ります。

割引フィールドは、通貨ではなくパーセンテージにする必要があります。

そして明らかにそのタイプはもはや通貨ではありません。 ユーザー名の要件が変更されたときにtype="text"をtype="email"に交換する場合と同じです。 または、フィールドが数値でなくなったときにnumberパラメータを削除した場合でも。

合計が一定額を超える場合は、最小割引が自動的に適用されます。

この場合も、最小値が適用されますが、通貨フィルターはそのまま残ります。 それでも、通貨として表示する必要があります。

フィルタのAPIと内部ロジックを更新するときは、変更がフィルタを消費する他の何かにどのように影響するかを考える必要があります[...] 2-フィルタにより、内部コンポーネントの状態をコンポーネントの外部に委任できます

いいえ。ロジックや状態をフィルター自体に入れることは_決して_ありません。 フィルタは、値をフォーマットするためのべき等関数です。 理想的には、VMのコンテキストで実行することすらすべきではありません。 追加のデータをプルするためのthisがないはずです。

複製は間違った抽象化よりもはるかに安価です

...あなたが言ったように、あなたがたまたま同じであるコードを抽象化しているとき。 一方、フィルターは、値をフォーマットする単純なべき等関数です。 それらはまったく抽象化ではありません。

tl; drフィルターは抽象化ではなく、明示的なビジネス要件の代わりにはなりません。 フィルタに内部ロジックが含まれることはなく、必要になることもありません。 これらは、概念的にはHTMLのtype属性とv-modelのnumberパラメーターに似ています。

双方向フィルターは確かに抽象化です。 v-model双方向フィルターの現在の動作は、内部に多くの魔法を隠します。具体的には、入力のDOM値を一時的に基になるモデルと同期させず、次の場合にのみ「同期」します。フィールドをぼかします。 ところで、 @ JosephSilberこの動作は、特にあなたの要求のために実装されたので、なぜあなたがそれについてとても強く感じているのか理解できます。

ただし、双方向フィルターで私が目にする最大の問題は、基になるロジックがブラックボックスであり、ユーザーが機能要求を行う以外にそれをさらにカスタマイズする方法がないことです。 私にとって、より良いオプションは、そのような動作を自分で実装するための適切なビルディングブロックを提供することです。 そして、それが2.0でどのように可能であるかをお見せしましょう。

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

ここに、現在の双方向フィルターの「非同期になるまでぼやける」動作を実装する基本のCustomInputコンポーネントがあります。 2.0での変更により、コンポーネントがvalueプロップを受け入れ、 inputイベントを放出する限り、カスタムコンポーネントでv-modelを直接使用できます。 さらに、 changeイベントの値もフォーマットします。これは、現在、双方向フィルターでは不可能です。 このコンポーネントをさらに微調整して、フレームワークによる双方向フィルターの実装方法に縛られることなく、必要な動作を実現できます。

基本コンポーネントは解析/フォーマットロジックを実装していません。 parseおよびformatメソッドを使用して拡張し、特定のユースケースに合わせたカスタム入力コンポーネントを取得します。 この場合、 CurrencyInputコンポーネントです。

以前の魔法の動作を自分で実装しているため、基本コンポーネントは双方向フィルターよりも複雑です。 ただし、このコンポーネントを定義する必要があるのは1回だけです。 その見返りとして、後で変更したい場合に備えて、どのように動作するかを完全に制御できます。 これは価値のあるトレードオフだと思います。

これは、再利用性のための統一された抽象化であり、ほとんどの制御が可能であるため、コンポーネントについてより深く考える必要がある例です。 2.0 select2の例も参照してください。以前は1.0でこれはディレクティブとして実装されていましたが、現在は同じv-modelインターフェイスを持つコンポーネントになっています。

私にとって、より良いオプションは、そのような動作を自分で実装するための適切なビルディングブロックを提供することです。

これは素晴らしく、間違いなくVueが必要としているものですが、これを読みたかったのですが

私にとって、より良いオプションは、Vueで開始するための適切なビルディングブロックを提供し、新しいフィルタリング動作でVueを自分で拡張することです。

言い換えれば、通貨入力コンポーネントと他の多くのデフォルトのフィルタリングコンポーネントをVueの一部にすることはできませんでしたか？ なぜなら、誰もがいつか通貨を使うからですよね？ 同じ仕事を何度も繰り返すのはなぜ他の人に任せるのですか？ 通貨の書式設定は、Vue独自のフィルタリングコンポーネントツールバッグの一部にするのに十分な標準であり、他の人が独自のフィルタリングコンポーネントを作成する方法を学ぶための優れた基本的な例です。

そして.....完成した通貨入力コンポーネントであるという例から欠落しているのは1つだけであり、それはi18n機能であり、Vueにも必要であると私は信じています。 通貨番号のフォーマットは、その人（視聴者）が選択したロケールに応じて変更する必要があります。 つまり、ロケールデータを意味します。 「DE_de」は、このロケールエクスプローラー（標準に由来）に表示されるように通貨およびその他の数値をフォーマットします。 これをVueに追加すると、Vueに組み込まれた優れた通貨/数値フォーマットコンポーネントシステムが得られます。Vueを使用する他の何千人もの開発者は、自分で作成する必要はなく、Vueを入手したときにその場で使用できます。 。 これにより、Vueは強力なテンプレートシステムになります。

この「i18nフォーマットコンポーネント」を1.0のようにフィルターとして連鎖的に使用できない場合は、プラグイン可能である必要があります。 それもいいでしょう。 それがAureliaが行っていることであり、Twigもその拡張機能を使って行っていることです。 通貨入力コンポーネントは、引き続き<currency-input>である可能性があります。

このi18nおよびその他の標準テンプレートフィルターは、必要がなければ、他の人が常に再現する必要のないものである必要があります。 そのようなプラグインの作り方を教えていただければ、i18​​nプラグインもお届けします。 私はこれ全体に興味があります！：smile：

スコット

なぜなら、誰もがいつか通貨を使うからですよね？

そうではありません。 私は、実際にそれを使用したことはありません:)同じことが他のすべての組み込みフィルターにも当てはまります-他のフィルターが役に立たないときに、それらのいくつかは私たちの一部に役立ちます。 このトピックに取り組んでいる間、ほとんどの場合、組み込みのフィルターを使用したかったのですが、とにかく独自のバージョンを作成して、組み込みのバージョンのデッドコードをレンダリングすることになりました。

i18n機能。Vueにも必要だと思います。

これもまた、非常に議論の余地があります。 包括的なi18nサポートはかなり複雑になる可能性があり、IMOはVueに属していません。特に、ほとんどのユーザーがとにかくそれを必要としない場合はそうです。

ここで、これを提起したいと思います。Vueと別のテンプレート/フレームワークを比較するたびに、覚えておくべき重要なことが1つあります。Django/ Laravel / Twigとは異なり、Vueは本質的にクライアントライブラリであるため、できるだけ軽量にする必要があります。 いわゆる「有用性」または「エレガンス」のためだけに「機能」と「ユーティリティ」を追加するのではなく、もちろんすべての_core_機能を保持しながら、十分に単純に保つ方が理にかなっています。 コア機能以外のものが必要な場合は、プラグインを使用するか、独自のプラグインを開発することをお勧めします。 これを例として取り上げます。一般的に見られるSPAの場合、i18n / currencyはルーターや状態管理者よりも重要ですか？ そうは思いません。 それでも、vue-routerとvuexはVueに属していませんが、独自のリポジトリを持っています。 言い換えれば、 Vueはプログレッシブです。

そのようなプラグインの作り方を教えていただければ、i18​​nプラグインもお届けします。 私はこれ全体に興味があります！

これはより賢明なアプローチだと思います。ご関心をお寄せいただきありがとうございます:)

一部の領域でi18nを使用する必要がある場合））美しさのために、コードを調べて、いくつかの名前を手動で変更できると思います。
例：ほんの数時間前、私はbutstrap.datepikkerを取りました-そのような可能性があるという事実にもかかわらず、私は接続しません、i18n。 クイック60秒。 「手動で」曜日と月の名前を置き換えました。すべて-OK！ ））

@ 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-text）
v-for = "item of list | sortBy"のような他の式ではありません
それとも私は誤解しましたか？
私が意味したのは、1.0のようにフィルターを使い続けることでしたが、フィルターを1つだけ制限しました
式ごと

2016年5月1日午後10時24分、 PhanAnnotifications @ github.comは次のように書いています。

@tomsmithgrouphttps ：//github.com/tomsmithgroupあなたが提案したこと
（そしてそれ以上）が決定されました
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 to
2.0でも引き続きサポートされます。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@ yyx990803返信から

@fnlctrlそれは正しいです。 独自のコンポーネントを作成するだけです。

少し話題を外します。これらの双方向フィルターは、本番環境で本当に役立つのでしょうか。
つまり、ユーザーが入力に何かを入力し、ぼやけた後にそれを再フォーマットできるようにすることは本当に大丈夫ですか？
私のビジネスチームは常に、このように動作するように入力を要求します。間違ったものを入力することはできません。 したがって、 Vueを使用する場合でも、即時の双方向変更が非推奨になったため、その目的でjquery.inputmaskを使用します（これは私が本当に見逃しているものです...）
つまり、これらの双方向フィルターに本当に問題があるのでしょうか、それとも人々がそれを考えすぎているのでしょうか。 :)

@fullfs双方向フィルターは、便宜上、本番アプリ（多くの<input> s）で広く使用されていますが、今のところ、値を1回だけフィルターするのではなく、リアルタイムでフィルターするのはなぜですか。サーバーにPOSTされましたか？ コードのリファクタリングには少し時間がかかりますが、見逃すことはないと思います：D

UIを楽観的に更新する場合（特にモバイルの場合、今日のIMHOの標準です）、入力が提供された時点で実際に適切にフォーマットされた入力が必要になります。

スコット

2ウェイフィルターはvueで本当に素晴らしいです。 フィルタの有無にかかわらず、いつでも独自のカスタマイズされたコンポーネントを作成できますが、それには時間がかかります。 ライブラリは柔軟性を提供するだけでなく、物事を行うためのより速くて便利な方法を提供する必要があります。 2ウェイフィルターを含めることで、必要に応じて独自のコンポーネントを作成することを妨げることはありませんが、既存の機能がニーズに合っている場合は、ほとんどの場合、開発を迅速化できます。 それは常にAPIの表面と利便性の間の妥協点です。 バランスを見つける必要があり、Vueにはすでに素晴らしいバランスがあります。 フィルタを取り除くことは、バランスのとれた適切なポイントから一歩後退しているようです。 ライブラリは小さくなりますが、それを使用するすべてのプロジェクトのコードベースとボイラープレートは大きくなります。

フィルタが実際に非推奨になる場合は、v-modelディレクティブのパーサーとフォーマッターを簡単に指定できる代替手段を提供するとよいでしょう。 フィルタを使用すると、提供されている例@ 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)
    }
  }
})

双方向フィルターがなければ、1つも書く必要があります

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 。 私は特に2ウェイフィルターについて言及していました。

戻って来てください！ 私たちはそれが必要です、私はあなたが言ったことすべてに同意します。 しかし、それはとても簡単です、私たちは怠惰なユーザーです、私たちはただ怠惰で簡単な方法を望んでいます。 キープアライブのように。

カスタム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が1つ少ない
• テンプレートと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の場合、これは1行のコードでした。 検索入力用に配列をフィルタリングすることは可能であり、それはフレームワークの機能であるはずのすべての魔法を実行します。

そして、非常に大きな配列をフィルタリングするためのベストプラクティスと現在考えられていること

本当に大きな配列とは何ですか？ 理論的には、計算されたプロパティはフィルタリングにも役立ちます。

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

すべての開発者に独自のフィルターのセットを開発させ、計算されたエントリを自分で設定するなど、それを組み込むよりも優れているのはなぜですか？

以前は同じように考えていましたが（そしてなぜスレッドを始めたのか）、基本的にこれらの種類のフィルターを自分で作成するのは簡単なことであり、各開発者が望むものはたくさんあることを学びましたフィルタ（または計算されたプロパティ）として、フィルタが組み込まれていないことはそれほど大きな問題ではないことに気づきました。

スコット

私の場合、Firebaseデータベースによって提供されるjsonの> 10.000行に相当します。
なぜあなたがそのように考え、機能を削除することを決定するのかがわかりますが、それでも開発者にとってはかなり面倒です。

私はフィドルを私のデータ構造と一致するようにフォークしました：
https://jsfiddle.net/nw5yhLwv/
だから私は手で私のオブジェクトの文字列の検索をコーディングする必要がありますか？

私はあなたの質問を理解していません。 ごめん。 フィドルは私が投稿したもののように見えます。

スコット

計算されたフィルターとフィルター

フィルタは、レンダリングごとに計算され（メソッドと同じように）、計算されたプロパティは簡単に実行でき、必要な場合にのみ再計算されるため、パフォーマンスが低下する可能性があります。それ以外の場合は、結果がキャッシュされます。つまり、Vueが飛ぶことができます。

ああ。 両方あります。 😄

スコット

ねえ、私はいくつかのいじりをしました、そして今私はそれを手に入れました、それは素晴らしいコンセプトです！ 😄

これについての議論は長い間終わっているので、私は今このスレッドをロックします-Vue 2.0は数ヶ月間リリースされており、フィルターのドロップに関する批判はおおむねおさまりました。

このスレッドでのこれ以上の議論は生産的ではありません。 話し合いが必要だと思われるトピックに新しい角度が見られる場合は、新しい問題を開いてください。