Vue: [Saran] Vue 2.0 - Tolong kembalikan filter

Mengklarifikasi poin yang awalnya berasal dari obrolan Gitter: debounce bukanlah filter, dan hanyalah salah satu dari perubahan 2.0 yang tidak membuat orang senang kehilangannya.

Koreksi atas izin @JosephSilber : debounce adalah filter dan param v-model .

Terima kasih @agc93. Saya telah menghapus titik itu.

skot

Dalam kasus terburuk, kami akan membuat plugin kecil untuk menangani ini. Tentang filter, ada https://www.npmjs.com/package/babel-plugin-pipe-operator
Masalahnya adalah ini tidak akan berhasil tanpa kompilasi babel

Saya juga tidak terlalu tertarik dengan beberapa perubahan. Untuk filter, sepertinya ada alternatif mudah dengan mendaftarkan mixin global . Namun saya tidak terlalu menyukai gagasan mencemari semua cakupan metode komponen saya untuk tugas-tugas yang sangat sederhana seperti pluralisasi dan sebagainya. Namun, saya tidak pernah menggunakan filter dua arah.

Filter hanya nyaman dan indah. Dua hal yang selalu dilakukan vue dengan benar (sejauh ini).

Ketika saya membaca posting di vue 2.0, saya sangat bersemangat tentang semua kemungkinan baru (terutama dom virtual dan rendering server), tetapi saya juga terkejut dan sedikit sedih karena filternya hilang.

Mereka adalah salah satu bagian favorit saya dari vue, bukan hanya karena mereka mudah digunakan dan dirantai, tetapi terutama karena mereka mudah diperluas dan memiliki sintaks yang indah untuk menggunakannya dalam template secara langsung. Terutama dalam kombinasi dengan v-for loop, mereka adalah pasangan yang sempurna.

Berpikir bahwa saya harus menggunakan properti yang dihitung untuk mengganti pemfilteran untuk setiap prop yang saya inginkan, saya khawatir bahwa saya akan menulis banyak boilerplate di masa mendatang. Sementara mixin mungkin mengurangi sebagian dari masalah, saya masih merasa seperti bagian dari keanggunan dan kemudahan menggunakan vue akan hilang.

Semua orang yang setuju dengan itu, bisakah Anda mengklik jempol ke atas di bawah deskripsi? itu lebih baik daripada mengirim spam ke 17 ribu orang dengan +1 . Lebih baik lagi, buat beberapa kasus penggunaan yang berarti.

Saya tidak pernah menggunakan filter dua arah, tetapi saya akan sangat merindukan filternya! Saya dapat (dan terkadang saya melakukannya) menggunakan properti yang dihitung, tetapi dalam beberapa kasus sederhana, kenyamananlah yang benar-benar mempercepat alur kerja.

Pertimbangkan contoh yang sangat sederhana ini

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

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

Di atas jauh lebih mudah untuk ditulis dalam kasus di mana tidak diperlukan pemfilteran yang lebih rumit.

Sekarang bandingkan dengan yang berikut ini

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

Saya tidak mengatakan yang kedua sulit untuk ditulis, tetapi ketika Anda menggunakannya di banyak tempat, Anda akan mulai mengulanginya sendiri, dan itu hanya membutuhkan waktu ekstra yang mungkin dapat Anda gunakan pada beberapa fitur lain yang lebih berguna!

Bagaimanapun saya akan tetap menjadi pengguna Vue yang bahagia, hanya membagikan pendapat saya tentang filter yang tidak digunakan lagi!

Filter dapat digunakan kembali. Saya dapat membuat fungsi untuk memformat data saya sekali, mendaftarkannya sebagai filter dan hanya menggunakan dari semua contoh. Bagaimana saya bisa melakukannya di 2.0?

Bagaimana saya bisa melakukannya di 2.0?

• campuran
• Pisahkan modul dengan metode
• Modul terpisah dengan fungsi prop yang dihitung

Saya baru saja meninggalkan komentar di utas pengumuman, jadi alih-alih menduplikasi semuanya di sini, saya hanya akan menautkannya:

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

Saya benar-benar mengerti perasaan sesuatu yang super nyaman diambil dari Anda. Tapi tolong luangkan waktu sejenak untuk membaca komentar @chrisvfritz di thread forum di atas. Untuk mempermudah pembahasan saya copy paste saja disini:

@theotherzach Terima kasih atas semangat Anda untuk Vue! Saya ingin menjelaskan penghentian sedikit lebih baik, tetapi pertama-tama, saya harus memperkenalkan diri. Saya anggota tim inti Vue, saya menggunakan Vue sepanjang waktu untuk UI lepas dan pekerjaan visualisasi data, dan saya juga seorang pendidik yang mengajarkan orang untuk menggunakan Vue dan Rails, di antara teknologi web lainnya. Saya menjalankan sekolah kode, jadi saya membantu orang belajar menggunakan alat ini (dan menggunakannya bersama-sama) hampir _setiap hari_.

Saya juga salah satu pendukung besar untuk menghapus filter di Vue 2.0.

Masalah dengan filter untuk pemula ke Vue

Sebagian besar alasan saya mendukung filter yang tidak digunakan lagi sebenarnya adalah _untuk_ pemula. Saat bekerja dengan siswa, ini adalah percakapan yang muncul lebih dari sekali:

• Siswa: "Jadi filter pada dasarnya adalah sebuah fungsi?"
• Mentor: "Ya!"
• Siswa: "Oke, jadi bisakah saya menggunakannya secara normal dengan tanda kurung fungsi?"
• Mentor: "Tidak. Ini adalah fungsi khusus."
• Siswa: "Bisakah saya menggunakannya di tempat lain? Seperti di nilai yang dihitung?"
• Mentor: "Tidak, Anda hanya dapat menggunakannya dalam template dan hanya dengan sintaks pipa khusus."
• Murid: "... Kenapa?"

Salah satu hal besar yang membuat pemula tersandung adalah _pengecualian_. Filter hanyalah fungsi, _except_ memerlukan sintaks khusus dan tidak dapat digunakan di mana-mana. Dan mereka menggunakan sintaks pipa yang berbeda dari sintaks pipa yang dapat diintegrasikan ke dalam ES7 , artinya tidak akan lama sampai orang memiliki dua operator yang sangat mirip untuk melakukan sesuatu yang sangat mirip, tetapi mereka tidak _cukup_ sama. Dan hanya satu dari mereka yang benar-benar JavaScript.

Util library _are_ berguna, tetapi Vue bukan salah satunya

Dalam kasus filterBy , transformasi untuk string dan angka, dan filter khusus lainnya, ya, mereka berguna dalam aplikasi tempat mereka muncul. Util perpustakaan pada umumnya berguna. Dan ada lusinan pustaka util yang bagus untuk dipilih, tetapi Vue bukanlah pustaka utilitas. Dan sejujurnya, tidak ada utilitas yang kami tawarkan yang terbaik di kelasnya.

Menangani mata uang, tanggal, atau bahkan memfilter array - ini bukan fokus kami. Banyak aplikasi tidak memerlukannya dan sebagian besar aplikasi yang telah saya kerjakan yang _do_ menghadapi masalah ini memerlukan solusi yang lebih kuat daripada yang ditawarkan Vue saat ini (atau _could_ menawarkan tanpa memperkenalkan pengasapan dan penemuan kembali roda yang signifikan).

Di aplikasi saya, Accounting.js telah menangani mata uang dengan luar biasa, Moment.js (seperti yang Anda sebutkan) menangani tanggal dan waktu, pluralize tidak menangani banyak pluralisasi dengan baik, jadi nilai yang dihitung khusus sering kali lebih diinginkan, dan json sedikit lebih dari JSON.stringify .

Keuntungan dari properti yang dihitung

Menggunakan properti yang dihitung sebagai pengganti filter juga menawarkan keuntungan bahwa nilai yang diproses dapat dengan mudah digunakan kembali dengan cara KERING _di mana pun_ dalam komponen. Saya mendapati diri saya harus melakukan ini di aplikasi saya sepanjang waktu. Properti yang dihitung juga memindahkan lebih banyak detail implementasi dari template, hanya menyisakan deskripsi bersih tentang apa yang dilakukan komponen. Dan keuntungan dari filter yang ditentukan secara global adalah bahwa seseorang hanya perlu melihat fungsi untuk nilai komputer itu untuk melihat dan mengubah cara kerjanya. Pada array, metode chaining JavaScript map dan filter bahkan menyediakan daftar pemrosesan linier yang sama seperti yang dilakukan pipa, tetapi dengan cara yang lebih deklaratif dan mudah dimanipulasi.

Kegunaan dari apa pun yang didefinisikan secara global

Jika Anda perlu mendefinisikan fungsi atau apa pun yang Anda ingin dapat diakses di semua komponen Anda, Vue.prototype.whateverIWant = mySuperCoolFunction adalah cara yang bagus untuk melakukannya. Secara pribadi, saya tidak pernah _ingin_ melakukannya. Saya selalu lebih suka memasukkan metode pembantu ke dalam modul dan mengimpor modul itu di mana saya membutuhkannya. Tetapi tetap penting untuk dicatat bahwa mendaftarkan global - dalam bentuk apa pun - tidak menjadi lebih sulit.

Kasus direktif debounce

Saya harus mengatakan, saya benar-benar dengan Anda yang satu ini! Saya baru-baru ini memeriksa semua proyek Vue saya dan setiap proyek yang memiliki input di suatu tempat juga menggunakan debounce . Faktanya, hanya satu dari aplikasi saya yang lama _tidak_ menggunakan debounce. Sementara secara teknis sebuah utilitas - lodash dan banyak proyek kuat lainnya menawarkan solusi debounce - masalah ini cukup universal untuk pengembangan UI, untuk _any_ jenis aplikasi. Menulis fungsi debounce Anda sendiri juga cukup sepele sehingga saya mungkin ingin menggunakan implementasi lodash untuk hampir setiap proyek.

Masih ada beberapa perdebatan internal mengenai hal ini, jadi kita lihat saja ke mana arahnya. Tapi ya, bagi saya pribadi dan tampaknya juga beberapa orang lain, menghapus debounce menghilangkan sebagian besar kenyamanan yang ditawarkan oleh v-model .

Sekali lagi, terima kasih atas semangat Anda!

Serius, kami sangat menyukai betapa Anda mencintai Vue dan sangat senang Anda menyuarakan keprihatinan Anda - dan terutama dengan cara yang baik dan penuh hormat! Kami mendengarmu. Tim inti terdiri dari semua desainer, pengembang front-end, dan spesialis visualisasi data. Kami semua menggunakan Vue untuk pekerjaan kami sendiri, yang cukup beragam, jadi kami benar-benar berdedikasi untuk mengeluarkan dogfood yang ingin kami makan sendiri. :-)

Bicara itu murah, kode mari untuk melihat apakah tanpa filter, bagaimana kita menerapkan filterBy dan sebaliknya:

tulis fungsi filter murni global dalam file terpisah untuk digunakan kembali kode

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

gunakan filter di template 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>

lihat hasilnya di sini http://raywill.github.io/vuefilter/

Jika filter digunakan, kode vue berikut akan melakukan hal yang sama:

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

Rupanya, dengan dukungan filter, kita bisa menulis kode yang tidak terlalu sepele.
Secara pribadi saya lebih suka cara vue 1.0, yang membuat pengkodean lebih menyenangkan.

Adapun masalah boilerplate - ada beberapa cara untuk menghadapinya.

1. Impor/ekspor secara eksplisit

Seperti yang ditunjukkan @raywill di atas. Ini sedikit lebih bertele-tele, tetapi manfaatnya adalah:

1. Anda tidak perlu mencari dokumentasi filter Vue untuk memahami cara kerjanya. Sangat eksplisit dari mana fungsi itu berasal dan bagaimana mereka diimplementasikan.
2. Fungsinya sendiri hanyalah JavaScript. Anda dapat mengubah/menyusunnya agar sesuai dengan kasus penggunaan khusus tidak seperti filter bawaan yang tidak dapat Anda sentuh.
3. Anda dapat mengimpor dan menggunakan kembali fungsi-fungsi ini secara terprogram dalam metode, properti yang dihitung, dan di mana pun Anda menulis JavaScript.

2. Lampirkan ke Vue.prototype

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

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

3. Berfungsi (untuk pengguna tingkat lanjut)

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

Di mana fungsi pembantu terlihat seperti:

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

Sekali lagi, pertimbangan desain yang sangat penting adalah bahwa filter bawaan dapat berguna, tetapi filter tersebut tidak memiliki fleksibilitas JavaScript murni . Ketika fungsi built-in tidak sesuai dengan kebutuhan Anda, Anda akhirnya mengimplementasikan kembali sesuatu yang serupa (dan mengirimkan keduanya dalam kode akhir Anda, di mana built-in menjadi tidak berguna, kode mati), atau harus menunggu Vue untuk perbarui dan rilis versi baru.

@yyx990803 Saya suka pendekatan prototipe, tetapi bagaimana dengan kasus di mana Anda memerlukan banyak filter?

Sangat umum untuk menggunakan orderBy bersama filterBy

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

Bagaimana dengan kasus di mana Anda akan menambahkan limitBy juga?

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

Apakah pendekatan ini membuat kode kurang mudah dibaca?

Ya, setidaknya menurut saya.

Saya kira kita bisa menggabungkan filter seperti filterAndOrderBy tetapi itu juga tidak terasa benar.

Saya terbuka untuk perubahan, hanya ingin menemukan cara yang hampir mudah untuk menanganinya!

Juga, manfaat dapat menggunakan filter di mana saja adalah poin yang sangat bagus juga.

Sebagai catatan, @vuejs/collaborators telah mendiskusikan opsi untuk menyediakan paket utilitas dari filter terintegrasi saat ini. Ada banyak sumber daya di luar sana yang akan memberi Anda alat utilitas untuk basis kode Anda.

Satu hal yang baik tentang menghapus filter inti, adalah Anda sekarang dapat menyesuaikan/menerapkannya sendiri. Yang memberi Anda lebih banyak fleksibilitas.

@rigor789 ekspresi template harus sesederhana mungkin. Idealnya seperti <div v-for="filteredData"> </div> . Ini bisa menjadi prop yang dihitung, yang dapat menyimpan logika untuk membuat data yang difilter. Ini jauh lebih mudah dibaca, dan lebih baik daripada sesuatu seperti:

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

Jauh lebih dapat digunakan kembali untuk ditetapkan sebagai properti yang dihitung, dan bahkan dapat diturunkan ke komponen anak. Bagaimana jika Anda ingin menggunakan data yang difilter di dua tempat? Lebih mudah, lebih sederhana, andal, dan lebih mudah dibaca untuk templat memiliki ekspresi sederhana, dibandingkan dengan memiliki filter berantai dalam ekspresi.

Untuk siapa pun yang mengikuti, saya menjawab @chrisvfritz di sini: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

Berikut ini memecahkan kasus penggunaan saya dari _very_ beberapa fungsi pembantu tampilan murni yang tersedia secara global. Saya menarik kekhawatiran penghapusan filter saya. Bakar mereka! Selamat kepada @chrisvfritz dan @yyx990803 karena telah mengubah pikiran seseorang (milik saya) di Internet!

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

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

Saya sangat setuju dengan @yyx99803 , hapus filter dan tetap gunakan fungsi JS biasa.

@ blake-newman Itu poin yang sangat bagus, saya sebagian besar yakin pada saat ini, dan memikirkan keterbacaan, saya pikir sesuatu seperti ini dapat dicapai

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

Berikut ini adalah jsfiddle cepat dari konsepnya

Satu hal yang baik tentang menghapus filter inti, adalah Anda sekarang dapat menyesuaikan/menerapkannya sendiri. Yang memberi Anda lebih banyak fleksibilitas.

Anda selalu dapat menyesuaikan/menerapkannya sendiri.

Vue bukan pustaka utilitas. Dan sejujurnya, tidak ada utilitas yang kami tawarkan yang terbaik di kelasnya.

Yang kami khawatirkan adalah menghapus fungsi filter di template. Menghapus filter bawaan memang masuk akal – filter tersebut dapat dengan mudah dibuat ulang dengan mem-proxy-nya ke garis bawah/pustaka util lainnya. Kemudian, seseorang bahkan dapat merilis satu plugin yang membuat ulang semua filter bawaan saat ini.

Menggunakan properti yang dihitung sebagai pengganti filter juga menawarkan keuntungan bahwa nilai yang diproses dapat dengan mudah digunakan kembali dengan cara KERING di mana saja dalam komponen.

Tentu saja Anda dapat menggunakan properti yang dihitung jika Anda harus menggunakannya kembali di tempat lain. Tetapi jika tidak, filter masih jauh lebih nyaman.

Ada beberapa poin lain yang saya posting di tautan yang saya bagikan di atas.

Mengapa tidak mendukung sintaks untuk filter yang beroperasi seperti sintaks yang diusulkan ES7? Itu akan memungkinkan orang untuk tetap menggunakan filter kesayangan mereka, dan menyelaraskannya dengan apa yang mungkin terjadi di masa depan. Akhirnya ketika kami memiliki pipa ES7, Anda dapat mengganti implementasi internal tanpa mengubah api.

Apakah pipa ES7 disetujui atau mengalami banyak perubahan?

Secara teoritis dapat berubah, tetapi tampaknya... stabil?
Status: mindeavor/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich Saya pikir kita berada di halaman yang sama mengenai nilai pipa secara umum. Salah satu keuntungan dari kompiler baru di 2.0 adalah kita dapat menyalurkan kode fungsi render yang dihasilkan melalui Babel. Ini masih perlu dieksplorasi lebih lanjut, tetapi tidak dapat dibayangkan bahwa setelah |> mendapatkan lebih banyak momentum dan plugin Babel untuknya dikembangkan, Anda dapat dengan senang hati menyambungkan metode dengan pipa lagi - _everywhere_ di aplikasi Anda. Sebagai penggemar berat LiveScript dan bahasa fungsional lainnya, saya pasti mengenali nilainya !

operator pipa ini bahkan tidak dalam tahap 0

@thelinuxlich Ya, saya yakin mereka masih menunggu juara di TC39. 😞.

@rigor789 itu salah satu alternatif yang ingin saya sebutkan juga! Kekuatan JavaScript memungkinkan Anda untuk mencapai ekspresi pilihan Anda, dan itu lebih baik daripada menempatkan logika pemfilteran di dalam template.

@yyx990803 Bagaimana kinerja Vue dalam kasus berikut, ketika satu nama pengguna diperbarui?

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

Sepertinya yang pertama hanya akan merender ulang satu objek, sedangkan yang terakhir akan menghitung ulang seluruh daftar?

@rpkilby yang sepertinya tidak setara. Itu akan lebih seperti:

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

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

Masih tidak menyukai gagasan menggunakan metode sebagai filter (karena firasat sepertinya salah, tetapi tidak bisa menjelaskannya). Bagaimanapun, Anda mendiskusikan metode lain untuk menyediakan filter, jadi +1.

Tidak ada yang disarankan di utas ini yang mendekati ekspresif dan ringkas filter. Tidak.

Dan itu membuatku sangat sedih. Seperti yang saya katakan di utas forum: bagi saya, ini menghilangkan sebagian besar dari apa yang membuat Vue Vue.

Jika Anda mencari saya, Anda dapat menemukan saya di sudut sambil menangis tersedu-sedu

Tidak mungkin, perubahan ini mendorong pengkodean Javascript yang baik, tangani :)

Jadi saya baru saja berdiskusi panjang dengan @yyx990803 , di mana saya – dari sudut pandang pengguna – menyarankan untuk tetap mendukung _syntax_, karena memang terasa elegan dan alami. Imajinasi saya kira-kira seperti ini:

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

Saya mendapat kesan bahwa ini akan mendekati yang terbaik dari kedua dunia.

Namun pada akhirnya, saya yakin bahwa menghapus filter secara keseluruhan sebenarnya adalah hal yang lebih baik: seperti yang baru saja dikatakan @thelinuxlich , ini mendorong JavaScript dan pemikiran logika yang lebih baik. Kami tidak memperkenalkan logika di Laravel's Blade atau lapisan tampilan kerangka kerja lainnya, dan kami tidak boleh di template Vue.

Yang mengatakan, @JosephSilber jika Anda melihat ke sudut lain, Anda akan menemukan saya di sana.

Bagi saya filter terasa sangat indah, sintaksnya persis seperti apa seharusnya sintaks filter.

Juga satu hal yang menarik tentang Vue bagi saya adalah ia dilengkapi dengan (beberapa) baterai yang disertakan. Akan sangat menyedihkan jika kehilangan salah satu dari hal ini -- keduanya, yang menurut saya, membuat Vue menonjol.

Membaca utasnya, tampaknya sebagian besar perhatian dengan filter adalah fakta bahwa Vue memiliki filter default, dan bukan fungsi itu sendiri (atau apakah itu? Saya masih tidak yakin).

Saya suka pemikiran plug-in filter dari @blake-newman dan harus ada contoh yang dibuat sebelumnya. Jika orang lain datang dengan filter lain, mereka harus plug and play. Itu bagus. Saya sangat setuju bahwa membuat filter adalah tanggung jawab pengguna.

Apa yang masih diinginkan adalah kemampuan pipa dan rantai dan keglobalan fitur filter asli. Kekhawatiran tentang keglobalan diliput oleh @yyx990803. Bagaimana dengan chaining dengan pipa? Ini membantu banyak dalam membaca template dan memahami apa yang diharapkan sebagai output. Pipa dan rantai dibahas di atas. Apakah masih bisa dilakukan? Mengapa itu hal yang buruk sama sekali? Untuk desainer, itu adalah emas! Filter adalah alat perancang, bukan pemrogram JS. Jadi, argumen menulis JS yang lebih baik jatuh dari papan, dalam buku saya, tapi saya bisa mengerti mengapa itu diinginkan. Tetapi, sebagai seorang desainer, saya juga ingin menulis kode yang lebih baik, dan filter memungkinkan saya melakukannya dengan indah. :senyum:

skot

Inilah hal tentang chaining - filter terutama digunakan untuk dua tujuan:

1. memformat teks;
2. memproses array.

Dalam hal pemformatan teks, 90% atau lebih dari waktu hanya satu metode utilitas yang digunakan. Chaining tidak terlalu menjadi masalah dalam kasus ini.

Adapun array: Saya telah menunjukkan bahwa pemrosesan array sebenarnya adalah logika dan lebih cocok dalam JavaScript. Memiliki beberapa filter array berantai mungkin terlihat baik-baik saja ketika sederhana, tetapi bisa menjadi jelek ketika Anda menggunakan lebih dari 1 argumen untuk masing-masing. Hal ini juga mendorong Anda untuk memasukkan terlalu banyak logika dalam template Anda ketika Anda benar-benar tidak seharusnya melakukannya. Mereka juga tidak fleksibel (tidak dapat dengan mudah mengambil nilai yang diproses). Sebagai perbandingan, dengan ES2015 contoh aslinya

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

dapat ditulis sebagai:

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

Ini hanya JavaScript, tidak memiliki keajaiban, tidak ada sintaks alternatif dan API khusus filter untuk dipelajari. Dan Anda dapat mengakses nilai yang diproses (yang di-cache secara cerdas). Anda juga bebas menambahkan gula di atas ini seperti yang ditunjukkan pada komentar sebelumnya. Plus, template Anda terlihat lebih bersih:

<div v-for="filteredThings">

Saya tahu ini seperti hal yang berguna yang diambil, tapi jujur, argumen untuk filter sekarang terdengar seperti hanya mencoba untuk menjaga sintaks demi sintaks. Menurut pendapat saya, dibutuhkan lebih dari sekadar "karena elegan" untuk membenarkan suatu fitur - ia perlu memberikan nilai objektif. Ini adalah kasus untuk inline-templates , tetapi saya tidak melihatnya untuk filter.

@yyx990803 - Contoh Anda mencontohkan masalah ini, saya pikir. Sekali lagi, saya bukan pemrogram JS terbaik, tetapi saya tidak perlu menjadi pemrogram JS untuk mengetahui bahwa filteredThings tidak menjelaskan apa yang sebenarnya dilakukannya. Bagi saya, itu adalah praktik yang buruk. :smile: Fakta bahwa metode pemfilteran bersifat global juga berarti saya harus mencari di dokumen, kode atau menguraikan output untuk mengetahui apa yang dilakukan metode tersebut. Tidak benar-benar elegan. Benar?

Jadi ok. kita bisa memiliki nama metode seperti `filterByOrderByAndLimit'. Bagaimana dengan argumen?

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

Apakah itu benar?

Jika ya, itu mungkin layak. Tetap saja, itu tidak terlihat bagus.

Dan, sekarang saya hanya ingin filterBy dan OrderBy. Apakah saya memerlukan metode terpisah untuk melakukannya juga? Dan kemudian saya ingin menambahkan pemformatan mata uang. Metode lain? Rantai filter dalam template membuat manipulasi presentasi menjadi fleksibel dan sangat ekspresif. Kekhawatiran ini belum ditangani dengan benar dengan metode (dan kurangnya pengetahuan saya tidak memungkinkan saya untuk memahami metode bisa lebih baik).

Apakah ini mungkin?

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

Saya setuju bahwa melakukan terlalu banyak logika dalam template adalah sesuatu yang harus dihindari. Namun, filter chaining dan kemampuan untuk memasukkan filter di mana saja di komponen/template aplikasi adalah konsep yang fantastis dan ada alasan mengapa Anda menambahkannya sejak awal. Apa alasan atau alasan itu? Jika Anda dapat menyebutkan nama mereka, maka saya berani bertaruh uang mereka lebih besar daripada "tetapi itu mempromosikan praktik buruk" sejauh satu mil.

Apa pun yang memungkinkan fleksibilitas dapat digunakan dengan tidak semestinya, sama seperti Vue itu sendiri. Argumen utama untuk inline-template adalah fleksibel dan memungkinkan Vue untuk digunakan dengan cara yang berbeda. Filter tidak jauh berbeda, selain itu Vue internal dan tidak mempengaruhi bagaimana Vue dapat digunakan secara eksternal. Namun, itu tidak mendevaluasi pentingnya. Ingat, banyak orang juga mengatakan bahwa mereka tidak boleh melakukan upgrade. Itu sangat penting! :senyum:

Cara baru hanya membutuhkan atribut yang sama dengan cara lama.

• dapat dirantai
• global
• tambahkan ke template untuk mengekspresikan dengan baik bagaimana data dalam template akan dimanipulasi

(Apakah saya lupa sesuatu?)

Jika bisa melakukan semua itu, maka saya yakin semua orang akan cukup puas. Saya pribadi tidak dapat melihatnya terjadi dengan metode (belum).

skot

@smolinari

1. Saya telah dengan jelas menyatakan bahwa Anda harus menempatkan lebih sedikit logika di template Anda. Ini pendapat saya apakah Anda suka atau tidak. Jelas Anda bebas untuk tidak setuju, tetapi saya tidak dapat membantu Anda jika Anda ingin menentang praktik terbaik yang direkomendasikan.
2. Diberikan (1) - Saya telah menjelaskan mengapa rantai tidak menjadi masalah karena logika kompleks harus dilakukan dalam JavaScript.
3. Saya juga memberikan contoh bagaimana Anda dapat menambahkan metode yang tersedia secara global.
4. Lihat contoh @ rigor789 pada sintaks rantai khusus yang mirip dengan yang Anda inginkan.
5. Tujuan kerangka kerja ini adalah untuk memberikan apa yang _I_ yakini sebagai cara terbaik untuk mengembangkan aplikasi ujung depan, bukan untuk menyenangkan semua orang. Jadi tolong jangan gunakan "Saya tidak akan memutakhirkan jika Anda tidak mengembalikan fitur ini kepada saya" - itu tidak berfungsi.

Mengapa kalian tidak mencoba rilis alfa baru ini selama seminggu dan kemudian datang dengan beberapa komentar yang sangat berharga (berdasarkan latihan Anda)? Mungkin coba perbaiki aplikasi Anda yang ada dan beri tahu kami apa yang tidak mungkin, apa yang ditingkatkan, apa yang lebih buruk, sehingga kami dapat mendiskusikannya dengan lebih baik. Itu akan berguna untuk semua orang yang saya pikir.

@yyx990803 - saya setuju untuk 1. Jadi kami setuju. :smile: Saya hanya tidak setuju itu menjadi alasan yang tepat untuk mengambil sesuatu yang telah mendapatkan begitu banyak cinta.

Jadi, saya kira Anda telah memutuskan dari waktu ke waktu bahwa JS pragmatis lebih baik daripada HTML pragmatis?

Argumen larangan untuk tidak memutakhirkan adalah apa yang dikatakan orang lain. Saya hanya mencoba untuk berkomunikasi dan mengurangi itu.

Satu argumen terakhir dari saya sendiri. Lihatlah ini dari mata pengguna pengguna. Katakanlah saya memiliki sistem seperti Laravel atau sistem MVC atau MVVM lain yang menggabungkan Vue, yang juga memungkinkan pengguna sistem itu untuk membangun komponen mereka sendiri. Filter, seolah-olah, menyederhanakan kurva pembelajaran dan memungkinkan pengguna sistem itu menyelesaikan banyak hal, tanpa menyentuh JS apa pun. Saya penggemar Vue, karena itu memungkinkan pemrogram non-JS untuk tetap menyelesaikan banyak hal. Ini adalah alasan yang sama mengapa saya tidak suka React dan JSX. Kombinasi itu akan memiliki basis pengguna yang jauh lebih kecil dibandingkan Vue seiring berjalannya waktu. Saya akan bertaruh uang untuk itu.

Saya juga mengerti bahwa fleksibilitas sebenarnya terletak pada JS. Namun, tolong jangan hanya mengandalkan JS untuk fleksibilitas di Vue. Ingatlah, tidak semua orang adalah programmer JS pembunuh. Faktanya, kebanyakan orang tidak. Filter adalah cara yang bagus untuk menyelesaikan banyak hal untuk orang-orang itu dan itu adalah batu loncatan yang bagus menuju manipulasi JS lebih lanjut. Filter tidak bisa menyelesaikannya? Masuk lebih dalam ke metode JS.

Baik. Cukup dari saya..... saya sudah selesai. Dan, terima kasih telah mendengarkan, bagaimanapun caranya. Vue masih luar biasa! :senyum:

@azamat-sharapov - poin bagus.

skot

Melihat orang mencoba membenarkan praktik buruk di dalam JS membuatku sedih. Sungguh, Anda tidak perlu menjadi seorang profesional, lakukan saja pekerjaan rumah dasar (atau sudah tidak dasar lagi akhir-akhir ini?)

Masalah yang saya miliki dengan metode filter-dalam-adalah semantik.

Dalam istilah oops, filter seperti fungsi statis sedangkan metode adalah fungsi non-statis.

Filter menyampaikan semantik yang sangat berbeda dari metode. perbedaan terbesar adalah bahwa filter tidak dapat menggunakan this , tetapi metode bisa.

@yyx990803 saat menggunakan Vue.prototype.filters dapat bekerja tetapi mengubah Vue tidak terlihat seperti praktik yang baik bagi saya. Saya lebih suka menganjurkan membuat objek (global) terpisah yang akan berisi semua filter.

Itu tidak terlihat seperti praktik yang baik karena global bukanlah praktik yang baik. Pendekatan yang disarankan secara eksplisit mengimpor metode pembantu. Melampirkan ke prototipe adalah solusi bagi mereka yang tidak ingin mengimpor metode secara eksplisit.

Adapun semantik - filter adalah konsep yang diciptakan. Dalam JavaScript Anda tidak akan menemukan semantik yang berbeda hanya untuk huruf besar string - Anda memanggil fungsi. Dan itulah mereka, fungsi JavaScript.

Saya akan membuat satu komentar lagi untuk mencoba dan memperjelas poin pribadi saya, terutama karena komentar "mencoba membenarkan praktik buruk di dalam JS". Saya tentu tidak berusaha melakukan itu.

Saya menyadari Vue lebih dari sekadar sistem templating, tetapi, ini juga sistem templating dan saya khawatir Vue mencoba menjauh dari peran itu, yang menurut saya tidak seharusnya. Jadi sebagai mesin/sistem templating, ambil mesin templating Twig sebagai contoh yang sangat sukses dari apa yang dapat diharapkan dari sistem templating. Mereka memiliki bagian " Untuk perancang template " dan bagian " Untuk pengembang " di dokumen mereka. Sebagai sistem templating, Twig juga kuat untuk perancang templat, karena penuh dengan perilaku default, termasuk filter . Ini memungkinkan non-pengembang untuk melakukan banyak hal dengan sistem templat, tanpa mengetahui PHP secara langsung. Mereka hanya perlu mempelajari apa yang Twig tawarkan dan bagaimana menggunakannya. Saya mencari ini di Vue juga. Saya juga ingin melihat bagian "Vue for template designer" di dokumen. :senyum:

Juga, yang sangat penting adalah ekstensibilitas Twig. Jika sesuatu tidak tersedia dalam versi stok, itu dapat ditambahkan. Saat itulah pengembang masuk. Yang menyenangkan juga, ekstensi dapat dibagikan, yang berarti, itu hanya perlu dilakukan sekali.

Hal menyenangkan lainnya tentang perancang/pengembang dua tingkat ini adalah, Anda mendapatkan basis pengguna yang jauh lebih luas. Jauh, jauh lebih luas dan ini sama dengan . Dan ketika perilaku default tidak cukup, saat itulah mereka mulai belajar, dengan sukarela, bahasa yang mendasarinya. Dan saat itulah mereka mempelajari praktik terbaik dan selebihnya.

Jika Anda mengatakan, Vue tidak dapat menjadi mesin templat tanpa harus mempelajari JS, maka menurut saya, itu sangat menurunkan nilai pasarnya. Jika Anda berkata, Anda akan membiarkan pintu terbuka untuk membiarkan orang lain menjadikan alat itu untuk mesin templating sebagai plug-in, bagus. Tapi, kemudian semua orang akan berjuang untuk apa yang seharusnya ada di sistem templating. Itu juga IMHO yang kontraproduktif.

Di siswa Anda yang berbicara tentang contoh filter Evan, apakah seseorang yang mempelajari JS atau seseorang yang mempelajari mesin templat? Jika itu yang terakhir, saya yakin percakapannya akan berbeda.

Bagaimanapun. Saya masih berpikir Vue adalah sistem pemenang. Saya harap pemikiran saya dapat membuat orang lain berpikir secara berbeda tentang peran Vue dalam beberapa hal. :senyum:

skot

@yyx990803 jika filter adalah konsep yang diciptakan, lalu mengapa mereka diciptakan di tempat pertama?

Saya percaya itu karena di dalam <template> semua variabel eksternal seperti $data atau abc dikonversi menjadi this.$data dan this.abc dan karenanya fungsi js biasa didefinisikan di luar komponen tidak dapat direferensikan. Filter diperkenalkan untuk mengatasi keterbatasan ini.

Batasan itu masih ada --- saya berasumsi saya benar --- untuk menghapus batasan akan membutuhkan devs untuk secara eksplisit mengkode this.abc untuk referensi this.abc dan mengakses fungsi js seperti yang akan dirujuk dalam js.

Tapi itu akan menjadi fitur yang terlalu kuat, rentan terhadap penyalahgunaan dan migrasi kode lama akan menyusahkan. sintaks saat ini terlihat jauh lebih baik dari itu bagi saya.

Saya setuju dengan Anda bahwa filter pada dasarnya adalah fungsi js dan harus diimpor ke komponen. Saya hanya tidak suka bahwa mereka didefinisikan di tempat yang sama dengan metode.

Halo semuanya. Saya membaca seluruh utas dan inilah yang saya pikirkan.

• Tidak ada yang akan melewatkan filter bawaan seperti orderBy filterBy dan lainnya
• Apa yang semua orang ingin tetap miliki adalah operator pipa di template
• Tim inti mengatakan bahwa logika harus disimpan dalam javascript, bukan di templat, selain itu ada fitur es7 yang akan datang dengan operator pipa.

Memiliki itu sebagai ringkasan cepat apa yang saya pikir itu bisa menjadi solusi yang baik sampai js mengimplementasikan operator pipa asli , adalah memiliki operator pipa sebagai plugin dan menjaga versi 2.0 seperti apa adanya. Jadi, pengguna dapat melakukannya

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

Sementara kami menunggu implementasi fitur baru, itu dapat disertakan dengan beberapa peringatan tentang penghentian yang akan datang atau sesuatu. Saya tahu bahwa siapa pun dapat mengimplementasikan plugin itu, tetapi saya pikir itu akan lebih baik jika disediakan dan disimpan oleh tim Vue, mungkinkah itu?

Saya bisa saja salah, tetapi saya tidak berpikir Vue mengizinkan plugin mengacaukan kompilernya..

@azamat-sharapov Tentu saja tidak. Saya hanya tidak berpikir itu akan mengacaukan kompiler Vue :open_mouth:

@YerkoPalma Saya benar-benar _love_ operator pipa. Saya menggunakannya secara obsesif dalam bahasa fungsional dan tidak sabar untuk memilikinya di JavaScript! _But_, bayangkan Vue tidak pernah memiliki filter. Apakah Anda akan meminta kerangka kerja frontend untuk memperluas sintaks JavaScript? Itu domain Babel atau bahasa kompilasi ke JS, bukan kerangka kerja UI. Jika Anda lebih suka menggunakan bahasa seperti LiveScript, seperti yang sering saya lakukan, Anda bisa. Tapi masalahnya di sini bukan dengan Vue. Ini dengan JavaScript itu sendiri dan kami tidak di sini untuk memperbaikinya.

Selain itu, jika kami dapat menyalurkan hasil render di 2.0 melalui Babel seperti yang kami harapkan, maka Anda bahkan dapat menggunakan plugin terlacak non-TC39 jika Anda mau - secara konsisten, di mana saja di JavaScript Anda, alih-alih di templatenya saja. Jadi jika Anda hanya menginginkan pipa, kemungkinan besar Anda akan dapat memilikinya. Dan Anda _dapat_ memilikinya hari ini di 1.x - berhati-hatilah bahwa pipa yang akan Anda gunakan di template Anda cenderung memiliki prioritas dan perilaku yang berbeda dari yang ada di Babel Anda.

@smolinari dan lainnya. Ada dua frasa (dan variasinya) yang selalu saya dengar:

• "Pikirkan pengembang / perspektif pengguna"
• "Pikirkan pemula"

Keduanya menyiratkan asumsi - bahwa kita _tidak_ memikirkan kelompok-kelompok ini.

Saya telah menyebutkan ini sebelumnya, tetapi saya kira itu perlu diulang. _Semua orang_ di tim inti adalah desainer, pengembang frontend, atau kombinasi keduanya . Kami menggunakan alat ini setiap hari untuk pekerjaan kami sendiri. Kami akan menggunakan Vue 2.0 juga. Percayalah, kami _are_ memikirkan itu. 😉.

Untuk pemula, saya membuat kasus di sini , tapi saya rasa saya akan membahas lebih detail. Saya seorang pendidik. Dan saya adalah pendukung penghapusan filter, _pemikiran pemula_. Saya pribadi telah mengajari ratusan orang - bahkan mungkin lebih dari seribu - cara berlatih pengembangan web, biasanya dari awal. Tidak ada pengalaman pengkodean sebelumnya. Saya telah melakukan ini dengan siswa sekolah menengah, siswa sekolah menengah, mahasiswa, orang dewasa profesional, dan warga senior.

Dari perspektif itu, saya dapat memberi tahu Anda bahwa meskipun filter pada awalnya tampak seperti sulap yang mengasyikkan, filter pada akhirnya memperlambat pembelajaran siswa dengan memperkenalkan lebih banyak kerumitan untuk kenyamanan terbatas. Jika mereka belum pernah di Angular atau Vue dan percakapan ini terbalik - kami mencoba _memperkenalkan_ mereka di 2.0 - kami akan kesulitan menjelaskan mengapa mereka dibutuhkan dan kapan Anda harus menggunakannya.

Sebelum ada pembicaraan tentang penghentian di 2.0, saya telah menghilangkan filter dari kurikulum di sekolah kode kami, karena kami telah mengumpulkan cukup bukti bahwa mereka lebih berbahaya daripada baik untuk pemula. Kami lebih suka mereka mendapatkan pengalaman dengan fitur Vue yang lebih fleksibel, seperti metode dan properti yang dihitung. Kami bahkan tidak menganjurkan penggunaan filter, karena filter memudahkan untuk mengambil praktik buruk.

Harapan yang menempatkan dua keluhan ini ke tempat tidur. Kita lihat saja nanti. 😃.

Tapi, bayangkan Vue tidak pernah memiliki filter. Apakah Anda akan meminta kerangka kerja frontend untuk memperluas sintaks JavaScript?

Tentu saja saya akan melakukannya, karena filter sangat alami untuk _template_ seperti di Twig, yang disebutkan sebelumnya. Saya merasa bahwa memiliki operator pipa sama alaminya dengan memiliki sintaks kumis di template, maksud saya, kumis bukan html, dan bukan javascript apakah kalian akan menghapusnya juga? apa bedanya dengan operator pipa?

Argumen "pikirkan tentang anak-anak" itu bodoh. Sejauh yang saya tahu, Vue tidak dirancang untuk mengajarkan JavaScript, tetapi untuk pengembang front-end untuk menyelesaikannya. Untuk filter yang terakhir sangat bagus.

Jika mereka belum pernah di Angular atau Vue dan percakapan ini terbalik - kami mencoba untuk memperkenalkan mereka di 2.0 - kami akan kesulitan menjelaskan mengapa mereka dibutuhkan dan kapan Anda harus menggunakannya.

Saya sangat tidak setuju. Saya telah menggunakan kerangka kerja Python yang disebut Django sejak 2005 dan bahasa templatnya -- yang telah menjadi inspirasi bagi sebagian besar bahasa templat yang lahir belakangan di luar sana -- telah memiliki filter sejak hari pertama. Setelah menggunakannya dengan pengembang front-end selama sepuluh tahun, saya mulai menghargai keindahan dan kegunaannya. Akan sedih melihat sintaks ini hilang.

(Inilah yang dilakukan Django dengan filter: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen tolong perhatikan nada bicara Anda - menyebut argumen orang lain bodoh bukanlah cara yang konstruktif untuk berpartisipasi dalam diskusi.

Bagi mereka yang menggambar analogi dengan bahasa templat sisi server - satu aspek penting yang perlu diperhatikan adalah bahwa bahasa templat sisi server tidak memiliki jumlah fleksibilitas yang sama dengan yang dimiliki templat Vue (tidak ada properti yang dihitung, ekspresi terbatas). Juga - mereka dibangun untuk tujuan yang sama sekali berbeda: mengeluarkan string statis. Template Vue adalah representasi dari DOM interaktif - ada binding dua arah, event handler, komponen props, dan banyak lagi. Filter hanya cocok dalam kasus penggunaan yang sangat terbatas dalam konteks Vue: hari ini saya percaya itu adalah ide yang buruk untuk mengizinkan filter di mana-mana, misalnya filter pada model-v, v-untuk dan v-on memperkenalkan lebih banyak kompleksitas daripada kebaikan.

Salah satu alternatif yang mungkin adalah menyimpan filter tetapi hanya untuk interpolasi teks - yaitu Anda hanya dapat menggunakannya di dalam {{ }} s, bukan dalam arahan.

Sebagai referensi yang menarik: Angular 2 masih memiliki filter (berganti nama menjadi "pipa") tetapi mereka juga dengan sengaja menghapus filter daftar.

Maaf untuk bahasa saya, tidak bermaksud menghina siapa pun.

Bagi saya tujuan kerangka _is_ untuk melakukan hal-hal yang sulit dan membuatnya terlihat mudah bagi para pengembang yang menggunakan alat-alat ini. Saya masih berpendapat bahwa sintaks tidak dapat dikalahkan dan, sekali lagi, akan sedih melihatnya pergi.

Saya tidak tahu atau mengerti bahwa sebagian besar mekanisme di bawah kap mesin, tetapi dari sudut pandang pengguna, kepraktisan mengalahkan kemurnian :)

Dalam catatan terkait, menarik untuk melihat seberapa besar gairah yang ada di komunitas ini. Bagi saya Vue telah menjadi alat yang segar dan menyegarkan, mungkin itu sebabnya saya sendiri harus mengambil bagian dalam mengecat gudang khusus ini :)

Untuk titik data lain, Ember tidak memiliki filter dan juga tidak mengizinkan metode komponen, meskipun memiliki properti yang dihitung.

Untuk kasus penggunaan fungsi murni yang melakukan transformasi dalam template, Anda harus mendaftarkan helper stang / helper ember.
http://emberjs.com/api/classes/Ember.Helper.html

Pembantu stang secara sintaksis berbeda dari hal-hal yang bukan pembantu stang itulah sebabnya saya mengangkatnya. Mereka memiliki kesamaan dengan sintaks filter perpipaan. Namun template stang adalah "logika-kurang" yang berarti bahwa mereka memerlukan sintaks khusus untuk panggilan fungsi dalam template. Masalah yang tidak dimiliki Vue.

Filter sederhana untuk pemula, lihat keajaiban dengan menggunakan output cantik atau filter\ordersearch dalam array

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

dan kemudahan mendefinisikannya

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

sederhana, jelas di template, untuk 2.x Anda menentukan filter di modul eksternal dan di template get

import moment from 'moment'

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

dan dalam template

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

Sebagai saran, mengapa tidak meninggalkan filter lama di templat, tetapi pindahkan filter ke modul terpisah dan gunakan dari bagian metode?

Jadi jika Anda membutuhkannya, lakukan saja

npm install vue-utils

dan gunakan filter khusus dari paket utils

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

methods:{
   moment, price
}

dan gunakan sebagai filter umum

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

hasilnya diterjemahkan ke panggilan fungsi sederhana

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

_Catatan_
Bagi saya, filter paling banyak digunakan untuk memformat data, seperti tanggal, angka, atau string . Untuk memfilter array\objek, saya pikir lebih baik menggunakan komputasi dan fungsi dari modul vue umum:

import _ from 'vue-utils/array'

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

Manfaat:
Pemula dapat dengan mudah menggunakan filter lama, tetapi dalam menghitung dan menggunakan fungsi cantik di templat mereka untuk memformat keluaran data dan pemrogram dapat menulis modul fungsi sendiri untuk itu dan mudah digunakan.

_Mengapa modul terpisah?_
Saya pikir itu tidak perlu menjadi inti dari Vue, tetapi Vue harus memiliki beberapa utilitas untuk desainer template developer, jadi tidak perlu sepanjang waktu memerlukan lodash, momen atau yang lain, cukup instal utils dari npm dan mudah menggunakannya, tetapi simpan sintaks panggilan lama untuk template.
Tetapi satu pemikiran penting yang harus dilakukan untuk filter, harus ada fungsi murni, seperti getter di vuex.

Ini mudah untuk didukung, mudah digunakan kembali, dan memiliki tampilan template yang bagus.

Yang Anda butuhkan adalah jalur peningkatan yang jelas dan keinginan untuk mempelajari cara memodulasi kode Javascript Anda.

@thelinuxlich Kami berbicara tentang filter.

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

hanya sintaks gula untuk

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

Tetapi sepenuhnya mengecualikan filter untuk pemula di Vue\javascript itu buruk. Mengapa komunitas Laravel menyukai Vue? Karena itu sederhana dan kuat.

Jika kita benar-benar menghapus filter, perlu memberikan alternatif untuk _"Untuk desainer template"_, tidak perlu tahu bagaimana mengurutkan array atau memfilternya, cukup masukkan contoh formulir kode dan dapatkan hasilnya.

Programer harus tahu bagaimana _modularise_ kode Javascript, tetapi sisanya yang menggunakannya untuk hal-hal kecil tidak perlu mengetahuinya.

Jika kita berbicara tentang _"Untuk desainer template"_ di sana hanya dapat menempatkan

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

dan penggunaan kode di dalam

Vue.use(VueUtils)

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

dari contoh dan membanggakan diri sendiri, tidak perlu tahu js untuk memfilter dan mengurutkan array, banyak orang ingin melakukan beberapa hal, tetapi sulit untuk memahami kode seperti

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

jadi tidak perlu membuat hal yang rumit untuk tipe orang seperti ini, jika kita bisa memberikan solusi sederhana untuk itu dan itu bagus untuk pengembang.

Salah satu alternatif yang mungkin adalah menyimpan filter tetapi hanya untuk interpolasi teks - yaitu Anda hanya dapat menggunakannya di dalam {{ }}, bukan dalam arahan.

Saya pikir ini bisa menjadi kompromi yang sangat baik. Meskipun tidak akan memuaskan semua orang, itu semua yang pernah saya gunakan untuk filter dan saya benar-benar merasa aneh bahwa mereka saat ini dapat melakukan lebih dari itu.

Ini akan memungkinkan pemformatan teks yang nyaman jika Anda ingin menggunakan filter dan mengurangi kerumitan dengan menghapus filter dua arah secara efektif.

Menurut pendapat saya, contoh filter momentjs Anda sudah melewati terlalu banyak logika ke template.

Serius, Anda harus mengarahkan semua "pipe love" ini ke repositori spesifikasi hingga mencapai TC39 :)

Saya suka apa yang disarankan oleh @yyx99803 dan @VitaliyLavrenko . Itu bisa menjadi jalan tengah yang bagus.

skot

Saya suka proposal @VitaliyLavrenko , tetapi ketika saya mengatakan sesuatu yang serupa, tentang memiliki operator pipa di plugin @azamat-sharapov mengatakan bahwa plugin tidak boleh mengacaukan kompiler... Jadi saya bingung apakah itu mungkin atau jika saya hanya salah paham komentar?

@thelinuxlich

Apa yang lebih baik untuk Anda baca?

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

atau

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

Berpikirlah sebagai pengembang dan tanyakan kepada seseorang yang tidak tahu javascript.

Bagi saya, untuk _not developers_ lebih baik seperti ini:

Vue.use(VueUtils)

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

Ini tengah, dan digunakan seperti vue-resource hanya lib umum.

Tentang pipa, saya ini sintaks gula

benda dalam benda | filterDengan 'foo' | pesanDengan 'bar' | batasDengan 5

untuk

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

Apa kemudahan untuk membaca?

Jika Anda perlu meneruskan data ke 2 templat berbeda, Anda menyimpan 2 atau 3 modifikasi untuk satu data?

Jika itu seperti:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

Ini situasi abstrak, tetapi jika digunakan dalam satu atau dua templat? Anda perlu menyimpan data untuk 10 atau 100 objek? Meningkatkan penggunaan memori? Ya kita bisa menggunakan metode helper dan menggunakannya dalam template, tapi untuk _"Untuk desainer template"_ yang jauh dari javascript lebih baik sesuatu seperti judul | padLeft 10 dan itu harus diterjemahkan ke panggilan fungsi, itu mudah dan fungsional.

Pikirkan tentang orang yang berbeda, pengembang dapat dengan mudah melakukannya dengan cara yang berbeda, tetapi orang lain ingin melakukannya dengan sederhana.

Saya akan mengatakannya lagi, terlalu banyak logika dalam template adalah anti-pola. Daripada harus mempelajari DSL (filter) tertentu, Anda harus mempelajari Javascript.

@thelinuxlich Cukup gunakan JSX dan kami mendapatkan React dengan pengikatan 2 arah dan beberapa hal lainnya.

Tetapi dengan Vue yang kami dapatkan, orang yang tidak tahu javascript, tetapi dengan google dapat melakukan sesuatu dan jika Anda tidak menyukai pipa, jangan menggunakannya. Kami hanya dapat menambahkan sesuatu seperti

Vue.config.pipeFuncCall = true

Dan Anda dapat mengaktifkan\menonaktifkannya, tetapi bagi sebagian orang itu mudah.

_Saya akan mengatakan lagi, tidak hanya pengembang JS yang dapat menggunakan Vue, ini adalah sisi terkuat dari Vue._

Filter umum standar perlu, tetapi lebih baik ada di lib terpisah dan mudah untuk menambahkannya ke vue dan digunakan.

Atau Anda ingin Vue menjadi sesuatu seperti ASM dan hanya pengembang yang baik yang dapat menggunakannya?

Kawan, saya pikir keputusan yang diambil oleh tim inti Vue telah dijelaskan dengan sangat baik. Bisakah kita tidak mengulangi hal yang sama berulang-ulang dan berkomentar hanya dengan sesuatu yang baru, berharga, jika ada?

Jika itu adalah bagian dari prinsip inti Vue untuk lebih mudah bagi pengembang non-JS, bahkan jika itu menyakiti prinsip bahasa, maka saya akan setuju dengan Anda, tetapi mungkin tidak demikian.

Seperti yang saya katakan sebelumnya, saya sebagian besar baik-baik saja dengan filter yang tidak digunakan lagi, saya pasti akan merindukannya demi kenyamanan mereka, tetapi saya lebih dari yakin bahwa sistem filter yang sangat mirip dapat diperkenalkan sebagai plugin.

Saya telah memberikan contoh bukti konsep sedikit lebih awal, yang dapat digunakan dalam alat peraga yang dihitung, serta inline

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

Di sisi lain, Jika seseorang menginginkan pipa, saya yakin itu bisa dilakukan, dengan sesuatu seperti ini

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

Atau mungkin, jika akan ada pengait yang memungkinkan plugin mengurai ekspresi, dan memprosesnya sesuka mereka, itu bisa menjadi cara yang mungkin juga, tetapi itu semata-mata tergantung pada seberapa rumit penerapannya, dan efek apa yang akan ditimbulkannya. pada kerangka kerja (kinerja / ukuran), dan apakah @yyx990803 benar-benar ingin pergi ke arah ini atau tidak!

Saya merasa, jika kita diberi alternatif elegan, yang mudah digunakan (Plugin atau sesuatu di intinya), kita akan terbiasa dengan cukup cepat.

@rigor789 untuk memfilter array dan mengurutkannya, dll, lebih baik menggunakan komputasi, jauh lebih bersih. Tapi saya pikir masalah untuk menampilkan data dalam format yang berbeda:

jika kita memiliki bidang yang dibuat_at dan perlu di templat, buat sebagai dd.mm.YYYY atau di tautan

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

untuk filter ini digunakan dengan baik sekarang, alternatif apa yang bisa kita dapatkan dari 2.x?

Untuk saat ini hanya gunakan

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

dan tentukan metode tanggal, tetapi itu membuat templat menjadi kotor, jika menyimpan 3 bidang tambahan itu menghabiskan memori, dan jika 100-200 objek menjadi berat.

Inilah keputusan akhir:

1. Filter akan didukung, tetapi hanya di dalam interpolasi teks. Ini membatasi mereka untuk tujuan pemformatan teks sambil menegakkan logika lain ke dalam JavaScript.
2. Vue 2.0 akan dikirimkan tanpa filter bawaan. Komunitas dapat membuat paket filter mereka sendiri jika diperlukan.
3. Sintaks filter akan berubah untuk menggunakan sintaks pemanggilan fungsi untuk argumen alih-alih dipisahkan oleh spasi. Ini membuatnya lebih sesuai dengan JavaScript dan bahasa templating populer lainnya (Jinja2, swig, twig...):

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

Terima kasih sudah mendengarkan Evan. Itulah yang membuat Vue hebat. Ia memiliki pemimpin yang hebat. :senyum:

skot

@yyx990803 & @chrisvfritz

Satu hal yang tampaknya telah terkubur dalam diskusi ini adalah filter dua arah. Filter dua arah adalah yang paling sulit untuk direplikasi dengan solusi lain yang diusulkan.

1. Pertimbangkan contoh sederhana ini , yang telah saya posting di utas forum itu. Menggunakan properti yang dihitung untuk ini akan memiliki 2 kelemahan utama:
   
   
   
   1. Anda harus membuat properti baru yang dihitung untuk setiap nilai, menghasilkan satu ton kode boilerplate.
   
   
   2. Lebih buruk lagi, properti yang dihitung bahkan tidak dapat disarangkan . Jika Anda memiliki grafik objek yang lebih kompleks, semua properti yang dihitung harus berada di tingkat atas. Anda akan berakhir dengan nama properti yang panjang dan bertele-tele yang membutuhkan lebih banyak kognitif yang berlebihan untuk terus melacak properti terkomputasi mana yang melacak nilai bersarang.
   
   

Mengabaikan kasus penggunaan ini sebagai "sepele" atau "kurang rumit" adalah kontra-produktif. Saya telah menggunakan ini pada aplikasi skala menengah dan besar. Ini bekerja dengan sangat baik! Demonya tentu sederhana, tetapi tekniknya bagus.

1. Ini semakin membingungkan ketika berhadapan dengan array di v-for , seperti dalam contoh ini (sekali lagi, sengaja dibuat sederhana). Mengulangi array, Anda tidak akan menemukan jalan lain dalam properti yang dihitung. Satu-satunya cara untuk mengatasinya adalah dengan memiliki komponen terpisah untuk setiap item dalam larik, menambahkan lebih banyak boilerplate.

Bandingkan contoh ini dengan filter:

``` js
impor mata uang dari 'some-currency-filter';
mengimpor produk dari 'product-stub';

Vue baru({
el: document.body,
data: { produk },
filter: { mata uang },
});
```

Untuk satu tanpa filter:

``` js
impor mata uang dari 'some-currency-filter';
mengimpor produk dari 'product-stub';

Vue baru({
el: document.body,
data: { produk },
komponen: {
produk: {
alat peraga: ['produk'],
dihitung: {
harga: {
Dapatkan() {
kembali mata uang.baca(ini.produk.harga);
},
set(nilai) {
this.product.price = mata uang.tulis(nilai)
}
},
pengiriman: {
Dapatkan() {
return currency.read(ini.produk.pengiriman);
},
set(nilai) {
this.product.shipping = currency.write(nilai)
}
},
penanganan: {
Dapatkan() {
return currency.read(this.product.handling);
},
set(nilai) {
this.product.handling = currency.write(nilai)
}
},
diskon: {
Dapatkan() {
kembalikan mata uang.baca(ini.produk.diskon);
},
set(nilai) {
this.product.discount = mata uang.tulis(nilai)
}
}
}
}
}
});
```

Saya tahu yang mana di atas yang ingin saya tulis.

_{(ini mungkin bisa dibersihkan sedikit dengan membuat pabrik properti yang dihitung, tetapi intinya tetap bahwa ini jauh lebih bertele-tele daripada yang dibutuhkan)}

Karena tim inti tampaknya teguh menentang sintaks pipa filter, apakah mungkin untuk memperkenalkan filter param untuk v-model direktif?

Dengan param filter kita akan dapat mempertahankan versi elegan pertama dari JS di atas, dan cukup menulis ulang template untuk menggunakan param sebagai ganti sintaks pipa ajaib:

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

Ini akan mencapai keseimbangan yang tepat karena tidak memiliki sintaksis ajaib sambil mempertahankan kemampuan untuk dengan mudah mengonversi input bolak-balik tanpa banyak boilerplate.

Terimakasih atas pertimbangan anda.

Saya telah menulis ulang contoh Anda untuk memasukkan filter Anda sebagai arahan khusus: jsfiddle .
Meskipun tidak sesingkat filter, itu hampir tidak menyakitkan seperti yang saya bayangkan. Dan saya tidak membutuhkan banyak waktu untuk mengumpulkan bagian-bagian dari barang-barang yang sudah tersedia bagi kita semua.

@Nirazul membuat arahan khusus untuk setiap filter telah diusulkan sebelumnya . Perlu membuat arahan baru yang mengimplementasikan ulang semua fungsi v-model untuk setiap jenis filter yang Anda gunakan di aplikasi Anda sungguh tidak masuk akal.

Selain itu, arahan Anda bahkan tidak sepenuhnya berfungsi seperti filter; mengaburkan bidang setelah mengubah nilai tidak memformatnya kembali. Selain itu, v-model melakukan jauh lebih banyak daripada yang Anda lakukan dalam arahan itu.

Arahan ini jelas dapat diubah dengan lebih banyak fitur dan perbaikan, tetapi intinya tetap: ini semua adalah plester di atas sesuatu yang seharusnya benar-benar sederhana.

Saya belum melihat proposisi apa pun di utas ini yang menyebutkan arahan khusus. Maukah Anda mengarahkan saya ke komentar ini?

Seperti yang dapat Anda bayangkan, saya belum menulis dan mengujinya untuk Anda gunakan di aplikasi Anda. Saya hanya ingin menunjukkan, apa yang mungkin sekarang sebagai alternatif. Jika ini memungkinkan dengan sangat mudah, mungkin ada ruang bagi plugin untuk mengotomatiskan proses lebih banyak lagi.
Jelas, bahwa arahan yang ditulis dengan cepat ini tidak memiliki fungsionalitas penuh dari v-model. Mungkin satu arahan filter khusus yang dikombinasikan dengan params dan/atau pengubah akan cukup untuk menggantikan filter.

Mari tetap konstruktif, seperti yang telah saya coba untuk memecahkan masalah Anda. Itu selalu lebih mudah untuk bash pada solusi daripada memberikan kontribusi dan bergerak maju.

@JosephSilber Anda perlu bersantai. "tidak masuk akal" adalah kata yang kuat.

Hai, Apakah menghapus filter dimotivasi dengan mengurangi kekacauan template atau apakah itu sangat memengaruhi
implementasi teknis 2.0? Jika itu adalah masalah efek visual sebelumnya, bagaimana kalau mengizinkan
filter seperti sekarang (tetapi dengan bentuk javascript baru)
tetapi membatasinya hanya untuk satu per ekspresi, seperti v-for="i of list | orderBy('key')", (tidak lebih dari satu tanda pipa)
ini bisa membuat pemrosesan filter di 2.0 lebih sederhana dan dapat diprediksi dan secara visual paling tidak berantakan.
Karena akan ada penguraian filter untuk {}}, mengizinkannya dalam ekspresi lain akan masuk akal.
ini akan mengakomodasi semua kasus penggunaan/fungsi yang ada (seperti pemfilteran dua arah, item dalam v-for).
Penggunaan lebih dari satu filter yang ada dapat dengan mudah digabungkan/ditingkatkan menjadi satu oleh pemilik.

@tomsmithgroup Apa yang Anda sarankan (dan lebih dari itu) telah diputuskan untuk tetap didukung di 2.0.

@yyx99803 & @chrisvfritz akan senang mendengar pendapat Anda tentang filter dua arah .

@JosephSilber Jadi dengan pabrik properti terkomputasi yang Anda singgung, bahkan tidak ada banyak boilerplate:

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

Meskipun secara pribadi, saya tidak akan membuat pabrik untuk contoh ini, karena masing-masing properti ini sebenarnya adalah masalah terpisah yang hanya _muncul_ sama sekarang. Saat Anda menghapus filter, menjadi lebih jelas betapa rumitnya satu komponen itu. Itulah yang Anda lihat sebagai boilerplate.

Dan ini adalah alasan besar mengapa komponen _exist_. Untuk membagi kompleksitas menjadi masalah yang dapat dikelola. Ketika saya melihat sebuah komponen, semua yang dilakukannya perlu dengan mudah masuk ke memori kerja saya atau pengembangan menjadi jauh lebih lambat dan lebih rawan kesalahan. Menyembunyikan kerumitan di balik sintaks filter tidak menghilangkan kerumitan itu.

Untuk mendemonstrasikan ini, mari kita lihat apa yang terjadi ketika masalah memenuhi persyaratan yang berubah di dunia nyata: Katakanlah Anda memutuskan diskon tidak boleh lebih besar dari harga + pengiriman + penanganan. Atau penanganannya tidak boleh melebihi jumlah X. Atau bidang diskon harus berupa persentase, bukan mata uang. Atau jika total melebihi jumlah tertentu, diskon minimum harus diterapkan secara otomatis.

Anda mungkin tergoda untuk membuat filter lebih kompleks dengan opsi tambahan dan logika kondisional. Saat Anda memperbarui API filter dan logika internal, Anda sekarang harus memikirkan bagaimana perubahan Anda dapat memengaruhi hal lain yang menggunakan filter - bahkan mungkin di luar komponen saat ini, jika ini adalah filter bersama. Jadi sekarang Anda berada dalam situasi di mana membuat perubahan pada aplikasi Anda mulai terasa menakutkan. Dan itu semua karena dua filter bersama memungkinkan Anda mendelegasikan status komponen internal ke luar komponen, melanggar batasan komponen, meningkatkan sambungan, dan menyembunyikan kerumitan yang masih perlu Anda pikirkan setiap kali Anda mengerjakan komponen.

Dengan memecah berbagai hal menjadi beberapa komponen yang tidak terlalu rumit secara individual, dengan properti komputasi yang ditentukan secara terpisah atau props terikat, Anda sering memperbarui satu baris untuk menyesuaikan dengan persyaratan yang berubah. Tidak ada opsi atau persyaratan tambahan. Tidak ada refactoring untuk memenuhi kompleksitas penskalaan. Anda tidak perlu memikirkan apa pun di luar komponen _atau bahkan di luar properti tunggal itu_. Aplikasi Anda dari awal dan masih tetap mudah untuk dipikirkan dan diperbarui.

Saya pikir apa yang membuat filter awalnya menggoda dalam kasus ini, adalah mereka adalah obat duplikasi yang mudah dijangkau. Tapi duplikasi bukanlah boilerplate ketika itu insidental (yaitu kode kebetulan sama sekarang, sebelum masalah dunia nyata mulai bergulir).

Dan saya tidak bisa mengatakannya lebih baik daripada Sandi Metz:

duplikasi jauh lebih murah daripada abstraksi yang salah

@chrisvfritz Filter sama sekali tidak ada hubungannya dengan persyaratan bisnis. Filter hanya memformat data. Itu dia. Mereka tidak memanipulasinya dengan cara, bentuk, atau bentuk apa pun. filter="currency" secara konseptual sama dengan param number . Persyaratan bisnis jelas tidak boleh ditangani dalam filter.

Katakanlah Anda memutuskan diskon tidak boleh lebih besar dari harga + pengiriman + penanganan. Atau penanganannya tidak boleh melebihi jumlah X.

Kemudian Anda akan menggunakan beberapa modul validasi yang tepat, la vue-validator . Filter mata uang akan tetap di tempatnya, hanya menampilkan nilai yang mendasarinya.

bidang diskon harus berupa persentase, bukan mata uang.

Maka jelas jenisnya bukan lagi mata uang. Tidak berbeda dengan jika Anda menukar type="text" dengan type="email" ketika persyaratan nama pengguna berubah. Atau bahkan saat Anda menghapus param number saat bidang bukan lagi angka.

jika total melebihi jumlah tertentu, diskon minimum harus diterapkan secara otomatis.

Sekali lagi, minimum akan diterapkan, tetapi filter mata uang akan tetap di tempatnya. Anda masih ingin menampilkannya sebagai mata uang.

Saat Anda memperbarui API filter dan logika internal, Anda sekarang harus memikirkan bagaimana perubahan Anda dapat memengaruhi hal lain yang menggunakan filter [...] two-filter memungkinkan Anda mendelegasikan status komponen internal ke luar komponen

Tidak. Anda _tidak pernah_ memasukkan logika atau status apa pun ke dalam filter itu sendiri. Filter adalah fungsi idempoten secara ketat untuk memformat nilai. Idealnya, itu tidak boleh dijalankan dalam konteks VM ; seharusnya tidak ada this untuk menarik data tambahan.

duplikasi jauh lebih murah daripada abstraksi yang salah

...ketika, seperti yang Anda katakan, Anda sedang mengabstraksi kode yang kebetulan sama saat ini. Filter, di sisi lain, adalah fungsi idempoten sederhana yang memformat nilai. Mereka sama sekali bukan abstraksi.

filter tl;dr bukan abstraksi, dan tidak menggantikan persyaratan bisnis eksplisit. Filter tidak pernah memiliki logika internal, dan tidak seharusnya. Mereka secara konseptual mirip dengan atribut v-model type dan param number .

Filter dua arah tentu saja merupakan abstraksi. Perilaku filter dua arah saat ini pada v-model menyembunyikan banyak keajaiban di dalamnya - khususnya ini memungkinkan nilai DOM input untuk sementara tidak sinkron dengan model yang mendasarinya, dan hanya "menyinkronkannya" saat Anda mengaburkan lapangan. BTW @JosephSilber perilaku ini diterapkan secara khusus karena permintaan Anda, jadi saya bisa mengerti mengapa Anda sangat merasakannya.

Namun, masalah terbesar yang saya lihat dengan filter dua arah adalah bahwa logika yang mendasarinya adalah kotak hitam, dan pengguna tidak memiliki cara untuk menyesuaikannya lebih lanjut selain membuat permintaan fitur. Bagi saya, pilihan yang lebih baik adalah menyediakan blok bangunan yang tepat untuk menerapkan perilaku seperti itu sendiri. Dan izinkan saya menunjukkan kepada Anda bagaimana itu mungkin di 2.0:

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

Di sini kita memiliki komponen CustomInput dasar yang mengimplementasikan perilaku "tidak sinkron-sampai-kabur" dari filter dua arah saat ini. Karena perubahan pada 2.0, Anda dapat langsung menggunakan v-model pada komponen khusus selama komponen menerima prop value dan $emits input event. Selain itu, ini juga memformat nilai pada peristiwa change , yang saat ini tidak mungkin dilakukan dengan filter dua arah . Anda selanjutnya dapat mengubah komponen ini untuk mendapatkan perilaku yang diinginkan tanpa terikat pada bagaimana filter dua arah diimplementasikan oleh kerangka kerja.

Komponen dasar tidak mengimplementasikan logika parse/pemformatan - Anda memperluasnya dengan metode parse dan format untuk mendapatkan komponen masukan khusus yang disesuaikan untuk kasus penggunaan tertentu. Dalam hal ini, komponen CurrencyInput .

Komponen dasar lebih kompleks daripada filter dua arah, karena kami sekarang menerapkan sendiri perilaku ajaib sebelumnya. Namun Anda hanya perlu mendefinisikan komponen ini satu kali. Sebagai imbalannya Anda mendapatkan kontrol penuh atas bagaimana seharusnya berperilaku jika Anda ingin mengubahnya nanti. Saya percaya ini adalah tradeoff yang layak.

Ini adalah contoh bagaimana kita harus lebih memikirkan komponen karena ini adalah abstraksi terpadu untuk dapat digunakan kembali yang memberi Anda kendali paling besar. Lihat juga contoh 2.0 select2 - sebelumnya di 1.0 ini diimplementasikan sebagai direktif, tetapi sekarang menjadi komponen dengan antarmuka v-model yang sama.

Bagi saya, pilihan yang lebih baik adalah menyediakan blok bangunan yang tepat untuk menerapkan perilaku seperti itu sendiri.

Ini bagus dan paling pasti yang dibutuhkan Vue, namun saya ingin membaca ini

Bagi saya, opsi yang lebih baik adalah menyediakan blok pembangun yang tepat untuk memulai dengan Vue dan juga memperluas Vue dengan perilaku pemfilteran baru sendiri.

Dengan kata lain, tidak bisakah komponen input mata uang bersama dengan sejumlah komponen filter default lainnya menjadi bagian dari Vue? Karena, setiap orang menggunakan mata uang di beberapa titik, bukan? Mengapa menyerahkan kepada orang lain untuk melakukan pekerjaan yang sama lagi dan lagi? Pemformatan mata uang cukup standar untuk menjadikannya bagian dari komponen alat pemfilteran Vue sendiri dan itu adalah contoh dasar yang bagus bagi orang lain untuk belajar membuat komponen pemfilteran mereka sendiri juga.

Dan ..... hanya ada satu hal yang hilang dari contoh untuk menjadi komponen input mata uang yang sudah jadi dan itu adalah fitur i18n, yang menurut saya juga harus dimiliki oleh Vue. Pemformatan nomor mata uang harus berubah tergantung pada Lokal yang dipilih orang tersebut (pemirsa). Maksud saya data lokal yaitu . "DE_de" untuk memformat mata uang dan angka lain seperti yang ditunjukkan di Penjelajah Lokal ini (yang berasal dari standar). Tambahkan itu ke Vue dan Anda memiliki sistem komponen pemformatan mata uang / angka yang bagus yang dibangun langsung ke dalam Vue, sehingga 1000-an pengembang lain yang menggunakan Vue tidak perlu membuat sendiri, melainkan dapat langsung menggunakannya saat mereka mendapatkan Vue . Ini menjadikan Vue sistem templating yang kuat!

Jika menggunakan "komponen pemformatan i18n" ini tidak dapat digunakan dengan cara yang dapat dirantai sebagai filter seperti pada 1.0, itu harus dapat di-plugin. Itu akan baik-baik saja juga. Itulah yang dilakukan Aurelia dan Twig juga dengan ekstensinya . Komponen input mata uang masih bisa <currency-input> .

i18n ini dan filter templating standar lainnya benar-benar perlu menjadi sesuatu yang orang lain tidak perlu terus-menerus mereproduksi, jika mereka tidak harus melakukannya. Jika Anda menunjukkan cara membuat plug-in seperti itu, saya bahkan akan melakukan plug-in i18n untuk Anda. Saya sangat tertarik dengan ini secara keseluruhan!:senyum:

skot

Karena, setiap orang menggunakan mata uang di beberapa titik, bukan?

Tidak benar-benar, tidak. Saya, misalnya, tidak pernah benar-benar menggunakannya :) Hal yang sama akan berlaku untuk semua filter bawaan lainnya – beberapa di antaranya berguna bagi sebagian dari kita, sementara yang lain tidak berguna. Sementara kita membahas topik ini, sebagian besar waktu saya ingin menggunakan filter bawaan, akhirnya saya tetap menulis versi saya sendiri, merender kode mati versi bawaan.

sebuah fitur i18n, yang menurut saya juga harus dimiliki oleh Vue.

Ini, sekali lagi, sangat bisa diperdebatkan. Dukungan i18n yang komprehensif bisa sangat kompleks, dan IMO tidak termasuk dalam Vue, terutama ketika sebagian besar pengguna tidak membutuhkannya.

Sekarang, saya ingin mengangkat ini: setiap kali kita mencoba membuat perbandingan antara Vue dan kerangka/template lain, ada satu hal penting yang perlu diingat: Tidak seperti Django/Laravel/Twig, Vue pada dasarnya adalah pustaka klien, dan dengan demikian harus seringan mungkin. Akan lebih masuk akal untuk membuatnya cukup sederhana – sambil mempertahankan semua fitur _core_ tentu saja – daripada menambahkan "fitur" dan "utils" hanya demi apa yang disebut "kegunaan" atau "keanggunan." Jika Anda menginginkan sesuatu selain fungsi inti, cara yang lebih disukai adalah menggunakan plugin atau bahkan mengembangkannya sendiri. Ambil ini sebagai contoh: Untuk SPA yang umum terlihat, apakah i18n/mata uang lebih penting daripada router atau manajer negara bagian? Saya tidak berpikir begitu. Namun, vue-router dan vuex tidak termasuk dalam Vue, tetapi memiliki repositori mereka sendiri. Dengan kata lain, Vue bersifat progresif .

Jika Anda menunjukkan cara membuat plug-in seperti itu, saya bahkan akan melakukan plug-in i18n untuk Anda. Saya sangat tertarik dengan ini secara keseluruhan!

Saya percaya ini adalah pendekatan yang lebih masuk akal, dan terima kasih atas minat Anda :)

jika banyak yang perlu menggunakan i18n di beberapa area)) Saya pikir saya bisa masuk ke kode dan secara manual mengubah beberapa nama dari beberapa hal, untuk kecantikan.
Sebagai contoh: hanya beberapa jam yang lalu, saya butuh butstrap.datepikker - saya tidak terhubung, i18n terlepas dari kenyataan bahwa ada kemungkinan seperti itu. Cepat 60 detik. "Secara manual" menggantikan nama hari dalam seminggu dan bulan, dan semuanya - ok! ))

@phanan - Argumen Anda adalah mengapa saya menyebutkan "plugin". Saya setuju, tidak semua orang menginginkan fungsionalitas mata uang atau i18n dan mereka yang tidak dapat menjaga aplikasi mereka tetap ringan, tetapi sebagai sistem templating, saya percaya (dan ini adalah pendapat pribadi saya) Vue juga harus memiliki fungsionalitas standar seperti itu tersedia juga. Lebih penting lagi, dan kekhawatiran saya, bukankah seharusnya setiap orang harus menemukan kembali i18n atau roda komponen filter mata uang. Dengan kata lain, seperti Vue-Router dan Vuex tersedia tambahan untuk Vue, sejumlah filter standar seperti mata uang dan i18n juga bisa.

Oh, dan yang cukup menarik, Angular tampaknya memiliki i18n.

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

Angular mendukung i18n/l10n untuk filter tanggal, nomor, dan mata uang.

Ember dan React tampaknya telah menempuh rute "biarkan dunia dev melakukannya sendiri".
Video yang menarik.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Mungkin Vue hanya membutuhkan integrasi ke FormatJS? VueIntl? :senyum:

Sunting: Tidak bisa sesederhana itu, bukan? https://github.com/learningequality/vue-intl/blob/master/index.js

skot

Angular memiliki i18n yang terpasang di dalamnya.

Angular juga hadir dengan ng-router yang, dari apa yang saya dengar, dijauhi oleh komunitas ng demi ui-router.

Sekarang, jika tim Angular mengganti ng-router dengan ui-router, itu akan mengakibatkan perubahan dan rasa sakit yang terputus.

jika mereka mencoba meningkatkan ng-router, mereka membuang-buang waktu karena solusi yang lebih baik (ui-router) sudah ada.

Jika Vue mulai mendukung i18n, mata uang dll di intinya, maka situasi yang sama akan terjadi pada vue juga.

Saya menemukan filter bawaan nyaman, tetapi dalam hal ini saya setuju dengan tim vuejs..

Kemudian kita semua setuju bahwa filter tidak ada di inti Vue. Saya juga penggemar komponenisasi sebenarnya. Namun, tidak bisakah Vue menawarkan filter sebagai plugin inti juga? Suka Vuex dan Vue-Router?

skot

Namun, tidak bisakah Vue menawarkan filter sebagai plugin inti juga? Suka Vuex dan Vue-Router?

Itulah yang dibagikan @blake-newman sebelumnya.

Hai: halaman keputusan akhir yang ditunjukkan hanya mengizinkan filter untuk teks
tampilan {}} (v-teks)
bukan untuk ekspresi lain seperti v-for="item of list | sortBy"
Atau apakah saya salah paham?
Yang saya maksud adalah tetap memiliki filter seperti pada 1.0 tetapi hanya membatasi satu filter
per ekspresi

Pada Minggu, 1 Mei 2016 pukul 22:24, Phan An [email protected] menulis:

@tomsmithgroup https://github.com/tomsmithgroup Apa yang Anda sarankan
(dan lebih dari itu) telah diputuskan
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 ke
tetap didukung di 2.0.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@yyx990803 Bolehkah saya menyimpulkan dari balasan Anda bahwa filter dua arah tidak akan didukung di 2.0?

@fnlctrl itu benar. Cukup buat komponen Anda sendiri.

Saya akan sedikit keluar dari topik: apakah filter dua arah itu benar-benar berguna dalam produksi?
Maksud saya, apakah benar-benar boleh membiarkan pengguna mengetikkan sesuatu ke input lalu memformat ulang setelah diburamkan?
Tim bisnis saya selalu meminta masukan kami untuk bertindak seperti ini : Anda tidak boleh salah mengetik. Jadi bahkan sekarang dengan Vue kami menggunakan jquery.inputmask untuk tujuan itu karena perubahan dua arah instan sudah tidak digunakan lagi (yang saya sangat rindukan...)
Maksud saya, apakah benar-benar ada masalah dengan filter dua arah itu atau orang-orang yang terlalu memikirkannya? :)

@fullfs Filter dua arah banyak digunakan di aplikasi produksi kami (banyak <input> s) untuk kenyamanan, tetapi seperti yang saya lihat sekarang, mengapa memfilter nilai secara real-time alih-alih hanya memfilternya sekali sebelum ada POST-ed ke server? Butuh beberapa waktu untuk memfaktorkan ulang kodenya, tapi saya rasa saya tidak akan melewatkannya :D

Jika Anda ingin pembaruan UI yang

skot

Filter 2 arah sangat bagus di vue. Anda selalu dapat membuat komponen kustom Anda sendiri, dengan atau tanpa filter yang tersedia, tetapi itu membutuhkan waktu. Perpustakaan harus memberikan fleksibilitas tetapi juga cara yang lebih cepat dan nyaman untuk melakukan sesuatu. Menyertakan filter 2 arah tidak akan menghentikan orang untuk membangun komponen mereka sendiri jika perlu, tetapi akan memungkinkan pengembangan yang lebih cepat ketika fungsionalitas yang ada sesuai dengan kebutuhan, yang seringkali terjadi. Itu selalu merupakan kompromi antara permukaan API dan kenyamanan. Keseimbangan harus ditemukan, dan Vue sudah memiliki yang hebat. Menyingkirkan filter tampaknya merupakan langkah mundur dari titik keseimbangan yang tepat. Pustaka menjadi lebih kecil, tetapi basis kode dan boilerplate dari setiap proyek yang menggunakannya tumbuh lebih besar.

Jika filter benar-benar tidak digunakan lagi, mungkin akan lebih baik untuk memberikan alternatif yang dapat menentukan parser dan pemformat untuk arahan model-v, dengan cara yang mudah. Dengan filter dapat menulis hanya ini bagian dari contoh @yyx990803 yang disediakan:

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

Tanpa filter 2 arah, seseorang juga harus menulis

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

Jadi, lebih banyak fleksibilitas, tetapi juga lebih banyak kode untuk hasil yang sama.

@aristidesfl - filter tidak ditinggalkan. Kami memenangkan pertempuran, sebagian. TERTAWA TERBAHAK-BAHAK! Mereka akan dibatasi hanya untuk digunakan dalam interpolasi teks. Lihat di sini: https://github.com/vuejs/vue/issues/2873

skot

Terima kasih @smolinari . Saya merujuk terutama pada filter 2 arah.

silakan datang kembali! kita membutuhkannya, saya setuju semua yang Anda katakan. tapi itu sangat mudah, kami adalah pengguna yang malas, kami hanya ingin cara yang malas dan mudah. seperti tetap hidup.

Mungkin harus ada cara untuk menambahkan pengubah model v khusus ( http://rc.vuejs.org/guide/forms.html#Modifiers )

Mereka bekerja seperti filter dua arah.

@ecmel setuju. Ini adalah cara untuk pergi.

Buka masalah permintaan fitur kemudian :)

@ecmel ide serupa, meskipun digambarkan sebagai pengubah tipe, telah dibahas di sini .

@rpkilby Diskusi itu ditutup juga, mungkin kita harus membuka yang baru untuk modifikator v-model khusus.

Tidak lagi dapat melakukan ini:

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

Membatasi filter ke {{ }} tampaknya aneh, sering kali Anda ingin menggunakan filter dalam pengikatan atribut (tidak melewati prop), dan kami tidak dapat menggunakan {{ }} dalam atribut lagi !

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

Membatasi filter ke {{ }} tampaknya aneh, sering kali Anda ingin menggunakan filter dalam pengikatan atribut (tidak melewati prop), dan kami tidak dapat menggunakan {{ }} dalam atribut lagi !

Mereka dihapus karena mereka dapat dengan mudah diganti dengan properti dan metode yang dihitung, sementara mereka sendiri memiliki API yang lebih terbatas dan tidak ada kemungkinan hasil caching.

Jadi:

• satu API lebih sedikit
• gunakan metode yang sama dalam template dan kode JS, tidak perlu menduplikasi perilaku filter untuk digunakan dalam kode aplikasi.
• alat peraga yang dihitung dapat di-cache
• lebih fleksibel karena hanya JS

pseudocode di depan:

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

Maaf, saya hanya "baru".
Tetapi datang dari Angular 1 tidak memiliki filter terasa sangat aneh dan kontra intuitif mengapa lebih baik setiap pengembang mengembangkan set filternya sendiri dan mengatur entri yang dihitung sendiri, dll. Lebih baik daripada membuatnya dibangun?
Dan apa yang sekarang dianggap sebagai praktik terbaik untuk memfilter array yang sangat besar, menurut objek dalam elemen. Dengan sudut ini hanya satu baris kode. Dimungkinkan untuk memfilter array untuk input pencarian dan itu akan melakukan semua keajaiban, yang seharusnya menjadi fungsi kerangka kerja.

Dan apa yang sekarang dianggap sebagai praktik terbaik untuk memfilter array yang sangat besar

Apa itu array yang sangat besar? Secara teoritis, properti yang dihitung akan baik untuk pemfilteran juga.

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

mengapa lebih baik setiap pengembang mengembangkan set filternya sendiri dan menyetel entri yang dihitung sendiri, dll. Lebih baik daripada membuatnya terpasang?

Saya dulu berpikir dengan cara yang sama (dan mengapa saya memulai utasnya), tetapi karena saya telah mempelajarinya, pada dasarnya membuat filter semacam ini sendiri, dan ada begitu banyak hal yang mungkin diinginkan oleh setiap pengembang. sebagai filter (atau properti yang dihitung), saya menyadari bahwa bukan masalah besar jika tidak memiliki filter bawaan.

skot

Dalam kasus saya itu sama dengan> 10.000 baris di json yang disediakan oleh database firebase.
Saya mengerti mengapa Anda mungkin berpikir seperti itu, dan memutuskan untuk menghentikan fitur tersebut, namun itu cukup merepotkan bagi para pengembang.

Saya memotong biola agar sejalan dengan Struktur Data saya:
https://jsfiddle.net/nw5yhLwv/
Jadi saya perlu mengkode pencarian string di objek saya dengan tangan?

Saya tidak mengerti pertanyaan Anda. Maaf. Biola terlihat seperti yang saya posting.

skot

Dihitung vs. filter

Filter mungkin buruk untuk kinerja, karena mereka dihitung untuk setiap render (seperti metode) dan properti yang dihitung mudah dilakukan, dan hanya dihitung ulang, bila perlu jika tidak, hasilnya di-cache, yang berarti Vue dapat terbang.

Oh. dan kami memiliki keduanya. 😄.

skot

Hei, saya melakukan beberapa mengutak-atik dan sekarang saya mengerti, itu konsep yang bagus! 😄.

Saya akan mengunci utas ini sekarang, karena diskusi tentang ini sudah lama selesai - Vue 2.0 telah keluar selama beberapa bulan, dan kritik tentang penurunan filter sebagian besar telah mereda.

Diskusi lebih lanjut di utas ini tidak produktif. Jika Anda melihat sudut pandang baru terhadap topik yang menurut Anda perlu didiskusikan, silakan buka edisi baru.