Vue: [सुझाव] Vue 2.0 - कृपया फ़िल्टर वापस लाएं

एक बिंदु को स्पष्ट करना जो मूल रूप से Gitter चैट से आया था: debounce एक फ़िल्टर नहीं है, और 2.0 परिवर्तनों में से एक और था जिसे खोने के बारे में लोग रोमांचित नहीं थे।

@JosephSilber का सुधार शिष्टाचार: debounce एक फ़िल्टर और v-model परम दोनों है।

धन्यवाद @ agc93. मैंने वह बिंदु हटा दिया है।

स्कॉट

सबसे खराब स्थिति में हम इससे निपटने के लिए छोटे प्लगइन्स लेकर आएंगे। फ़िल्टर के बारे में, https://www.npmjs.com/package/babel-plugin-pipe-operator है
समस्या यह है कि यह बेबेल संकलन के बिना काम नहीं करेगा

मैं कुछ बदलावों के बारे में बहुत ज्यादा उत्साहित नहीं हूं। फ़िल्टर के लिए, वैश्विक मिश्रणों को पंजीकृत करके एक आसान विकल्प प्रतीत होता है। हालाँकि, मुझे अपने सभी घटकों के तरीकों को प्रदूषित करने के विचार का बहुत शौक नहीं है, जैसे कि बहुवचन और आगे जैसे अति-सरल कार्यों के लिए। हालाँकि, मैंने कभी भी दो-तरफ़ा फ़िल्टर का उपयोग नहीं किया है।

फिल्टर बस सुविधाजनक और सुंदर थे। Vue ने हमेशा सही (अब तक) दो चीजें की हैं।

जब मैंने vue 2.0 पर पोस्ट पढ़ी, तो मैं सभी नई संभावनाओं (विशेषकर वर्चुअल डोम और सर्वर रेंडरिंग) के बारे में सोच रहा था, लेकिन मैं भी हैरान था और थोड़ा दुखी भी था कि फ़िल्टर चले गए हैं।

वे व्यू के मेरे पसंदीदा हिस्सों में से एक थे, न केवल इसलिए कि वे आसानी से प्रयोग करने योग्य और श्रृंखलाबद्ध थे, बल्कि मुख्य रूप से इसलिए कि वे आसानी से एक्स्टेंसिबल थे और उन्हें सीधे टेम्पलेट में उपयोग करने के लिए एक सुंदर वाक्यविन्यास था। विशेष रूप से v-for लूप के संयोजन में, वे एक आदर्श मैच थे।

यह सोचकर कि मुझे अपने इच्छित प्रत्येक प्रोप के लिए फ़िल्टरिंग को बदलने के लिए गणना की गई संपत्तियों का उपयोग करना होगा, मुझे चिंता है कि मैं भविष्य में बहुत सारे बॉयलरप्लेट लिखूंगा। जबकि मिक्सिन समस्या के एक हिस्से को कम कर सकते हैं, मुझे अभी भी ऐसा लगता है कि लालित्य का एक हिस्सा और वीयू का उपयोग करने में आसानी गायब होने वाली है।

हर कोई जो इससे सहमत है, क्या आप कृपया विवरण के तहत थम्स अप पर क्लिक कर सकते हैं? यह +1 के साथ 17 हजार लोगों को स्पैम करने से बेहतर है। इससे भी बेहतर, कुछ सार्थक उपयोग के मामलों के साथ आएं।

मैंने कभी भी दो-तरफ़ा फ़िल्टर का उपयोग नहीं किया है, लेकिन मुझे वास्तव में फ़िल्टर की कमी खलेगी! मैं (और कभी-कभी मैं करता हूं) परिकलित गुणों का उपयोग कर सकता हूं, लेकिन कुछ साधारण मामलों में, यह एक सुविधा है जो वास्तव में वर्कफ़्लो को गति देती है।

इस बहुत ही सरल उदाहरण पर विचार करें

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

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

उपरोक्त उन मामलों में लिखना इतना आसान है जहां कुछ और जटिल फ़िल्टरिंग की आवश्यकता नहीं है।

अब इसकी तुलना निम्नलिखित से करें

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

<ul>
    <li v-for="item in filteredItems">{{ item }}</li>
</ul>

new Vue({
    el: 'body',

    data: {
        items: [],
        filter: ''
    },

    computed: {
        filteredItems() {
            var self = this
            return this.items.filter(function(item) {
                return item.indexOf(self.filter) > -1
            })
        }
    }
})

मैं यह नहीं कह रहा हूं कि दूसरा लिखना मुश्किल है, लेकिन जब आप इसे कई जगहों पर इस्तेमाल करते हैं, तो आप खुद को दोहराना शुरू कर देंगे, और इसमें कुछ अतिरिक्त समय लगता है जिसे आप शायद कुछ अन्य, अधिक उपयोगी सुविधाओं पर उपयोग कर सकते हैं!

किसी भी तरह से मैं एक खुश Vue उपयोगकर्ता बना रहूंगा, बस बहिष्कृत किए जा रहे फ़िल्टर पर अपनी राय साझा कर रहा हूं!

फिल्टर पुन: प्रयोज्य हैं। मैं अपने डेटा को एक बार प्रारूपित करने के लिए फ़ंक्शन बना सकता हूं, इसे फ़िल्टर के रूप में पंजीकृत कर सकता हूं और सभी उदाहरणों से उपयोग कर सकता हूं। मैं इसे 2.0 में कैसे कर सकता हूं?

मैं इसे 2.0 में कैसे कर सकता हूं?

• मिक्सिन
• विधि के साथ अलग मॉड्यूल
• कंप्यूटेड प्रोप फंक्शन के साथ अलग मॉड्यूल

मैंने अभी-अभी घोषणा थ्रेड पर एक टिप्पणी छोड़ी है, इसलिए इसे यहाँ दोहराने के बजाय मैं बस इसे लिंक करूँगा:

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

मैं पूरी तरह से समझता हूं कि आपसे कुछ सुपर सुविधाजनक छीन लिया जा रहा है। लेकिन पहले कृपया ऊपर दिए गए फोरम थ्रेड में @chrisvfritz की टिप्पणी पढ़ने के लिए कुछ समय निकालें। चर्चा को आसान बनाने के लिए मैं इसे यहाँ कॉपी पेस्ट कर रहा हूँ:

@theotherzach Vue के लिए आपके जुनून के लिए धन्यवाद! मैं बहिष्करण को थोड़ा बेहतर तरीके से समझाना चाहता हूं, लेकिन पहले, मुझे अपना परिचय देना चाहिए। मैं Vue कोर टीम का सदस्य हूं, मैं अपने फ्रीलांस UI और डेटा विज़ुअलाइज़ेशन कार्य के लिए हर समय Vue का उपयोग करता हूं, और मैं एक शिक्षक भी हूं जो लोगों को अन्य वेब तकनीकों के साथ Vue और Rails का उपयोग करना सिखाता है। मैं एक कोड स्कूल चलाता हूं, इसलिए मैं लोगों को इन उपकरणों का उपयोग करना सीखने में मदद करता हूं (और उनका एक साथ उपयोग करता हूं) लगभग _हर दिन_।

मैं भी Vue 2.0 में फ़िल्टर हटाने के बड़े समर्थकों में से एक था।

Vue . के शुरुआती लोगों के लिए फ़िल्टर की समस्या

मेरे द्वारा फ़िल्टर को बंद करने के पक्ष में होने का एक बड़ा कारण वास्तव में _for_ शुरुआती था। छात्रों के साथ काम करते समय, यह एक से अधिक बार होने वाली बातचीत है:

• छात्र: "तो एक फिल्टर मूल रूप से एक कार्य है?"
• मेंटर: "हाँ!"
• छात्र: "ठीक है, तो क्या मैं इसे सामान्य रूप से फ़ंक्शन कोष्ठक के साथ उपयोग कर सकता हूँ?"
• मेंटर: "ठीक है, नहीं। यह एक विशेष प्रकार का कार्य है।"
• छात्र: "क्या मैं इसे अन्य स्थानों पर उपयोग कर सकता हूँ? जैसे गणना मूल्य में?"
• मेंटर: "नहीं, आप इसे केवल टेम्प्लेट में और केवल विशेष पाइप सिंटैक्स के साथ उपयोग कर सकते हैं।"
• छात्र: "... क्यों?"

शुरुआती लोगों तक पहुंचने वाली बड़ी चीजों में से एक है _exceptions_. फ़िल्टर केवल कार्य हैं, _except_ उन्हें एक विशेष वाक्यविन्यास की आवश्यकता होती है और हर जगह उपयोग नहीं किया जा सकता है। और वे एक पाइप सिंटैक्स का उपयोग करते हैं जो पाइप सिंटैक्स से अलग है जिसे ES7 में एकीकृत किया जा सकता है , जिसका अर्थ है कि यह तब तक लंबा नहीं होगा जब तक कि लोगों के पास कुछ समान करने के लिए दो समान ऑपरेटर न हों, लेकिन वे _quite_ समान नहीं हैं। और उनमें से केवल एक ही वास्तव में जावास्क्रिप्ट है।

पुस्तकालयों तक _are_ उपयोगी है, लेकिन Vue एक नहीं है

filterBy के मामले में, स्ट्रिंग्स और संख्याओं के लिए रूपांतरण, और अन्य विशिष्ट फ़िल्टर, हाँ, वे उन अनुप्रयोगों में उपयोगी होते हैं जहां वे आते हैं। सामान्य रूप से पुस्तकालय उपयोगी होते हैं। और चुनने के लिए दर्जनों महान उपयोग पुस्तकालय हैं, लेकिन Vue एक उपयोगिता पुस्तकालय नहीं है। और स्पष्ट रूप से, हमने जो उपयोगिताएँ प्रदान की हैं उनमें से कोई भी अपनी श्रेणी में सर्वश्रेष्ठ नहीं है।

मुद्राओं, तिथियों, या यहां तक ​​कि फ़िल्टरिंग सरणियों को संभालना - ये हमारा ध्यान नहीं हैं। कई ऐप्स को उनकी आवश्यकता नहीं होती है और अधिकांश ऐप्स जिन पर मैंने काम किया है, इन समस्याओं का सामना करने के लिए वर्तमान में Vue की तुलना में अधिक मजबूत समाधान की आवश्यकता होती है (या महत्वपूर्ण ब्लोट और व्हील रीइन्वेंशन को पेश किए बिना _could_ ऑफ़र)।

मेरे ऐप्स में, Accounting.js ने मुद्रा को शानदार ढंग से संभाला है, Moment.js (जैसा कि आपने उल्लेख किया है) दिनांक और समय को संभालता है, pluralize कई बहुवचनों को अच्छी तरह से हैंडल नहीं करता है, इसलिए एक कस्टम गणना मूल्य अक्सर अधिक वांछनीय होता है, और json से कुछ अधिक है JSON.stringify ।

गणना की गई संपत्तियों के लाभ

फ़िल्टर के स्थान पर गणना किए गए गुणों का उपयोग करने से यह लाभ भी मिलता है कि संसाधित मूल्य को घटक में _anywhere_ DRY तरीके से आसानी से पुन: उपयोग किया जा सकता है। मुझे हर समय अपने ऐप्स में ऐसा करना पड़ता है। गणना की गई संपत्ति टेम्पलेट से अधिक कार्यान्वयन विवरण भी ले जाती है, जिससे घटक क्या करता है इसका केवल एक स्पष्ट विवरण छोड़ देता है। और विश्व स्तर पर परिभाषित फ़िल्टरों पर एक लाभ यह है कि किसी को केवल उस कंप्यूटर मान के लिए फ़ंक्शन को देखने की आवश्यकता है और यह देखने के लिए कि यह कैसे काम कर रहा है। सरणियों पर, जावास्क्रिप्ट के map और filter विधियों का पीछा करने से पाइपों द्वारा की जाने वाली प्रसंस्करण की समान रैखिक सूची भी मिलती है, लेकिन इससे भी अधिक घोषणात्मक और आसानी से हेरफेर किए जाने वाले तरीके से।

विश्व स्तर पर परिभाषित की उपयोगिता जो भी हो

यदि आपको किसी फ़ंक्शन या किसी अन्य चीज़ को परिभाषित करने की आवश्यकता है जिसे आप अपने सभी घटकों में एक्सेस करना चाहते हैं, तो Vue.prototype.whateverIWant = mySuperCoolFunction ऐसा करने का एक शानदार तरीका है। व्यक्तिगत रूप से, मैंने इसे कभी भी _वांछित_ नहीं किया है। मैंने हमेशा एक मॉड्यूल में एक सहायक विधि डालना और उस मॉड्यूल को आयात करना पसंद किया है जहां मुझे इसकी आवश्यकता है। लेकिन यह नोट करना अभी भी महत्वपूर्ण है कि किसी भी प्रकार के ग्लोबल्स को पंजीकृत करना कोई कठिन नहीं है।

debounce निर्देश का मामला

मुझे कहना है, मैं वास्तव में इस पर तुम्हारे साथ हूँ! मैंने हाल ही में अपने सभी Vue प्रोजेक्ट्स को देखा और हर एक जिसमें input कहीं न कहीं debounce भी उपयोग किया। वास्तव में, मेरे पिछले अनुप्रयोगों में से केवल एक ने बहस का उपयोग नहीं किया। जबकि तकनीकी रूप से एक उपयोगिता - लॉश और कई अन्य मजबूत परियोजनाएं बहस समाधान प्रदान करती हैं - यह समस्या यूआई विकास के लिए बहुत ही सार्वभौमिक है, _any_ प्रकार के ऐप के लिए। अपना खुद का डेब्यू फंक्शन लिखना भी इतना गैर-तुच्छ है कि मैं शायद लगभग हर प्रोजेक्ट के लिए लॉश के कार्यान्वयन का उपयोग करना चाहता हूं।

इस पर कुछ आंतरिक बहस बनी हुई है, इसलिए हम देखेंगे कि यह कहाँ जाता है। लेकिन हां, मेरे लिए व्यक्तिगत रूप से और यह कुछ अन्य लोगों को भी लगता है, बहस को हटाने से v-model द्वारा दी जाने वाली अधिकांश सुविधा समाप्त हो जाती है।

फिर से, आपके जुनून के लिए धन्यवाद!

गंभीरता से, हम प्यार करते हैं कि आप Vue से कितना प्यार करते हैं और वास्तव में खुशी है कि आप अपनी चिंताओं को व्यक्त कर रहे हैं - और विशेष रूप से इस तरह के दयालु और सम्मानजनक तरीके से! हम आपको सुन रहे हैं। कोर टीम सभी डिज़ाइनर, फ्रंट-एंड डेवलपर्स और डेटा विज़ुअलाइज़ेशन विशेषज्ञ हैं। हम सभी अपने स्वयं के काम के लिए Vue का उपयोग करते हैं, जो बहुत विविध है, इसलिए हम निश्चित रूप से डॉगफ़ूड को बाहर निकालने के लिए समर्पित हैं जिसे हम स्वयं खाना चाहते हैं। :-)

टॉक सस्ता है, आइए कोड देखें कि क्या बिना फिल्टर के, हम फिल्टर कैसे लागू करते हैं और रिवर्स:

कोड पुन: उपयोग के लिए एक अलग फ़ाइल में वैश्विक शुद्ध फ़िल्टर फ़ंक्शन लिखें

//
// filters.js
//
function filterBy(list, value) {
  return list.filter(function(item) {
    return item.indexOf(value) > -1;
  });
}

function findBy(list, value) {
  return list.filter(function(item) {
    return item == value
  });
}

function reverse(value) {
  return value.split('').reverse().join('');
}

export {filterBy, reverse, findBy}

App.vue टेम्पलेट में फ़िल्टर का उपयोग करें

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ reverse(msg) }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in filterBy(words, userInput)">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in findBy(words, userInput)">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
import {reverse, filterBy, findBy} from './filters.js'
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
  methods : {
    reverse,
    filterBy,
    findBy,
  },
}
</script>

यहां देखें रिजल्ट http://raywill.github.io/vuefilter/

यदि फ़िल्टर का उपयोग किया जाता है, तो निम्न Vue कोड वही करेगा:

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ msg | reverse }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in words | filterBy userInput">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in words | findBy userInput">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
}

जाहिर है, फ़िल्टर समर्थित के साथ हम कम तुच्छ कोड लिख सकते हैं।
व्यक्तिगत रूप से मैं vue 1.0 तरीका पसंद करता हूं, जो कोडिंग को और अधिक मनोरंजक बनाता है।

बॉयलरप्लेट की चिंताओं के लिए - इससे निपटने के कई तरीके हैं।

1. स्पष्ट रूप से आयात/निर्यात

जैसे @raywill ने ऊपर दिखाया। यह थोड़ा अधिक क्रियात्मक है, लेकिन लाभ यह है कि:

1. यह कैसे काम करता है यह समझने के लिए आपको Vue के फ़िल्टर दस्तावेज़ देखने की ज़रूरत नहीं है। यह सुपर स्पष्ट है कि कार्य कहां से आ रहे हैं और उन्हें कैसे कार्यान्वित किया जाता है।
2. कार्य स्वयं सिर्फ जावास्क्रिप्ट हैं। आप बिल्ट-इन फिल्टर के विपरीत विशेष उपयोग के मामलों में फिट होने के लिए उन्हें बदल/रचना कर सकते हैं जिन्हें आप छू नहीं सकते।
3. आप इन कार्यों को विधियों, परिकलित गुणों और कहीं भी जावास्क्रिप्ट लिखने में आयात और प्रोग्रामेटिक रूप से पुन: उपयोग कर सकते हैं।

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

फिर से, एक बहुत ही महत्वपूर्ण डिज़ाइन विचार यह है कि अंतर्निर्मित फ़िल्टर उपयोगी हो सकते हैं, लेकिन उनमें शुद्ध जावास्क्रिप्ट के लचीलेपन की कमी होती है । जब एक अंतर्निहित फ़ंक्शन आपकी आवश्यकताओं के अनुरूप नहीं होता है, तो आप या तो कुछ समान को फिर से लागू करते हैं (और अपने अंतिम कोड में शिपिंग करते हैं, जहां बिल्ट-इन बेकार हो जाता है, मृत कोड), या Vue के लिए प्रतीक्षा करनी होगी उन्हें अपडेट करें और एक नया संस्करण जारी करें।

@ yyx990803 मुझे प्रोटोटाइप दृष्टिकोण पसंद है, लेकिन उन मामलों के बारे में जहां आपको एकाधिक फ़िल्टर की आवश्यकता है?

orderBy के साथ filterBy . का उपयोग करना बहुत आम है

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

उन मामलों के बारे में जहां आप limitBy भी जोड़ेंगे?

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

क्या यह दृष्टिकोण कोड को कम पठनीय बनाता है?

हाँ, कम से कम मेरी राय में।

मुझे लगता है कि हमारे पास filterAndOrderBy जैसे संयुक्त फ़िल्टर हो सकते थे लेकिन यह भी सही नहीं लगता।

मैं परिवर्तनों के लिए तैयार हूं, बस इसे संभालने का लगभग उतना ही आसान तरीका खोजना चाहता हूं!

साथ ही, कहीं भी फ़िल्टर का उपयोग करने में सक्षम होने का लाभ भी वास्तव में एक अच्छा बिंदु है।

बस ध्यान दें, @vuejs/सहयोगी वर्तमान एकीकृत फिल्टर के उपयोगिता पैकेज प्रदान करने के विकल्प पर चर्चा कर रहे हैं। वहाँ बहुत सारे संसाधन हैं जो आपको आपके कोड आधार के लिए उपयोगिता उपकरण प्रदान करेंगे।

कोर फ़िल्टर को हटाने के बारे में एक अच्छी बात यह है कि अब आप उन्हें स्वयं अनुकूलित/कार्यान्वित कर सकते हैं। जो आपको काफी ज्यादा फ्लेक्सिबिलिटी देता है।

@ कठोरता 789 टेम्पलेट अभिव्यक्ति यथासंभव सरल होनी चाहिए। आदर्श रूप से <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

यह गणना की गई संपत्ति के रूप में असाइन करने के लिए बहुत अधिक पुन: प्रयोज्य है, और यहां तक ​​​​कि बाल घटकों को भी पास किया जा सकता है। क्या होगा यदि आप दो स्थानों पर फ़िल्टर किए गए डेटा का उपयोग करना चाहते हैं? अभिव्यक्तियों में जंजीर वाले फ़िल्टर की तुलना में टेम्प्लेट के लिए सरल अभिव्यक्ति होना आसान, सरल, विश्वसनीय और अधिक पठनीय है।

साथ चलने वाले किसी भी व्यक्ति के लिए, मैंने यहां उत्तर दिया: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

निम्नलिखित विश्व स्तर पर उपलब्ध शुद्ध दृश्य सहायक कार्यों के _very_ कुछ के मेरे उपयोग के मामले को हल करता है। मैं अपनी फ़िल्टर हटाने की चिंताओं को वापस लेता हूं। उन्हें जला दो! 🔥 इंटरनेट पर किसी की सोच (मेरा) बदलने के लिए @chrisvfritz और @yyx990803 को बधाई!

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

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

मैं @yyx990803 से पूरी तरह सहमत हूं, फ़िल्टर हटा दें और सादे JS फ़ंक्शंस से चिपके रहें।

@ ब्लेक-न्यूमैन यह एक बहुत अच्छा बिंदु है, मैं इस बिंदु पर अधिकतर आश्वस्त हूं, और पठनीयता के बारे में सोचकर, मुझे लगता है कि ऐसा कुछ हासिल किया जा सकता है

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

यहाँ अवधारणा का एक त्वरित jsfiddle है

कोर फ़िल्टर को हटाने के बारे में एक अच्छी बात यह है कि अब आप उन्हें स्वयं अनुकूलित/कार्यान्वित कर सकते हैं। जो आपको काफी ज्यादा फ्लेक्सिबिलिटी देता है।

आप हमेशा उन्हें स्वयं अनुकूलित/कार्यान्वित करने में सक्षम थे।

Vue एक उपयोगिता पुस्तकालय नहीं है। और स्पष्ट रूप से, हमने जो उपयोगिताएँ प्रदान की हैं उनमें से कोई भी अपनी श्रेणी में सर्वश्रेष्ठ नहीं है।

हम जिस चीज को लेकर चिंतित हैं, वह है टेम्प्लेट में फ़िल्टर कार्यक्षमता को हटाना। बिल्ट-इन फिल्टर को हटाने से बहुत फायदा होता है - उन्हें अंडरस्कोर / अन्य उपयोग पुस्तकालयों के लिए प्रॉक्सी करके आसानी से फिर से बनाया जा सकता है। फिर, कोई एक एकल प्लगइन भी जारी कर सकता है जो सभी मौजूदा अंतर्निहित फ़िल्टर को फिर से बनाता है।

फ़िल्टर के स्थान पर गणना किए गए गुणों का उपयोग करने से यह लाभ भी मिलता है कि संसाधित मूल्य को घटक में कहीं भी DRY तरीके से आसानी से पुन: उपयोग किया जा सकता है।

बेशक आप गणना की गई संपत्तियों का उपयोग कर सकते हैं यदि आपको इसे कहीं और पुन: उपयोग करना है। लेकिन यदि आप नहीं करते हैं, तो फ़िल्टर अभी भी अधिक सुविधाजनक है।

कुछ अन्य बिंदु हैं जिन्हें मैंने उस लिंक में पोस्ट किया है जिसे मैंने ऊपर साझा किया है।

ES7 प्रस्तावित सिंटैक्स की तरह काम करने वाले फ़िल्टर के लिए सिंटैक्स का समर्थन क्यों नहीं करते? यह लोगों को अपने प्रिय फ़िल्टर का उपयोग जारी रखने और भविष्य में जो कुछ भी हो सकता है उसके अनुरूप लाने की अनुमति देगा। आखिरकार जब हमारे पास ES7 पाइप होते हैं, तो आप एपीआई को बदले बिना आंतरिक कार्यान्वयन को स्विच कर सकते हैं।

क्या ES7 पाइप स्वीकृत हैं या बहुत सारे परिवर्तनों के अधीन हैं?

यह सैद्धांतिक रूप से परिवर्तन के अधीन है, लेकिन लगता है... स्थिर?
स्थिति: माइंडेवर/एस-पाइपलाइन-ऑपरेटर#33

@JosephSilber @young-steveo @thelinuxlich मुझे लगता है कि हम सामान्य रूप से पाइप के मूल्य के संबंध में एक ही पृष्ठ पर हैं। 2.0 में नए कंपाइलर का एक फायदा यह है कि हम उत्पन्न रेंडर फ़ंक्शन कोड को बैबेल के माध्यम से पाइप कर सकते हैं। इसे अभी भी और तलाशने की जरूरत है, लेकिन यह समझ से बाहर नहीं है कि एक बार |> अधिक गति प्राप्त कर लेता है और इसके लिए एक बैबेल प्लगइन विकसित हो जाता है, तो आप अपने ऐप में फिर से पाइप के साथ तरीकों को खुशी से चेन कर सकते हैं - _everywhere_। लाइवस्क्रिप्ट और अन्य कार्यात्मक भाषाओं के बहुत बड़े प्रशंसक के रूप में, मैं निश्चित रूप से मूल्य को पहचानता हूं!

यह पाइपलाइन ऑपरेटर चरण 0 . में भी नहीं है

@thelinuxlich हाँ, मेरा मानना ​​है कि वे अभी भी TC39 पर एक चैंपियन की प्रतीक्षा कर रहे हैं। मैं

@ कठोरता 789 यह उन विकल्पों में से एक है जिसका मैं भी उल्लेख करना चाहता था! जावास्क्रिप्ट की शक्ति आपको अपनी पसंद की अभिव्यक्ति प्राप्त करने की अनुमति देती है, और यह फ़िल्टरिंग तर्क को टेम्प्लेट के अंदर डालने से बेहतर है।

@yyx990803 निम्नलिखित मामलों में Vue कैसा प्रदर्शन करता है, जब एक उपयोगकर्ता का नाम अपडेट किया जाता है?

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

Vue.extend({
  computed: {
    displayableUsers() {
      for (user of this.users)
        user.name = capitalize(user.name);
    },
  },
});

ऐसा लगता है कि पूर्व केवल एक वस्तु को फिर से प्रस्तुत करेगा, जबकि बाद वाला पूरी सूची को फिर से प्रस्तुत करेगा?

@rpkilby जो समकक्ष प्रतीत नहीं होता है। यह अधिक पसंद होगा:

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

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

अभी भी फ़िल्टर के रूप में विधियों का उपयोग करने का विचार पसंद नहीं है (एक आंत महसूस के रूप में यह गलत लगता है, लेकिन वास्तव में इसे समझा नहीं सकता)। किसी भी तरह से आपने फ़िल्टर उपलब्ध कराने के अन्य तरीकों पर चर्चा की, इसलिए +1।

इस सूत्र में सुझाई गई कोई भी चीज़ फ़िल्टर की अभिव्यक्ति और संक्षिप्तता के करीब भी नहीं आती है। यह बस नहीं है।

और यह मुझे वास्तव में दुखी करता है। जैसा कि मैंने फोरम थ्रेड में कहा था: मेरे लिए, यह Vue Vue के बड़े हिस्से को हटा देता है।

अगर आप मुझे ढूंढ़ रहे हैं, तो आप मुझे कोने में पा सकते हैं और जोर-जोर से रोते हुए पा सकते हैं

कोई रास्ता नहीं, यह परिवर्तन अच्छी जावास्क्रिप्ट कोडिंग को प्रोत्साहित करता है, इससे निपटें :)

इसलिए मैंने अभी @yyx990803 के साथ एक लंबी चर्चा की है, जहां मैंने - एक उपयोगकर्ता के दृष्टिकोण से - _syntax_ समर्थन रखने का सुझाव दिया, क्योंकि यह सुरुचिपूर्ण और स्वाभाविक लगता है। मेरी कल्पना कुछ इस प्रकार थी:

<li v-for="item in items | filterBy 'name' | orderBy 'title' 1">{{ item.name }}</li>
...
<script>
  ...
  methods: {
    filterBy (items, field) { return filtered; },
    orderBy (items, field, order) { return filtered; }
  }
  ...
</script>

मैं इस धारणा के तहत था कि यह दोनों दुनिया के सर्वश्रेष्ठ लोगों तक पहुंच जाएगा।

हालांकि अंत में, मुझे विश्वास है कि संपूर्ण रूप से फ़िल्टर हटाना वास्तव में एक बेहतर बात है: जैसे @thelinuxlich ने अभी कहा, यह बेहतर जावास्क्रिप्ट और तर्क सोच को प्रोत्साहित करता है। हम Laravel's Blade या किसी अन्य फ्रेमवर्क की व्यू लेयर में लॉजिक का परिचय नहीं देते हैं, और हमें Vue के टेम्प्लेट में नहीं करना चाहिए।

उस ने कहा, @JosephSilber अगर आप दूसरे कोने को देखें, तो आप मुझे वहां पाएंगे।

मेरे लिए फ़िल्टर फील बहुत सुंदर हैं, सिंटैक्स ठीक वैसा ही है जैसा फ़िल्टर सिंटैक्स को दिखना चाहिए।

इसके अलावा मेरे लिए Vue के बारे में एक आकर्षक बात यह है कि यह (कुछ) बैटरी के साथ आता है। इन चीजों में से किसी एक को खोना वास्तव में दुखद होगा - दोनों, जो मेरी राय में, Vue को सबसे अलग बनाते हैं।

धागे के माध्यम से पढ़ना, ऐसा लगता है कि फ़िल्टर के साथ अधिकांश चिंता यह थी कि Vue में डिफ़ॉल्ट फ़िल्टर थे, और वास्तव में फ़ंक्शन स्वयं नहीं था (या यह है? मुझे अभी भी यकीन नहीं है)।

मुझे @ ब्लेक-न्यूमैन से फ़िल्टर प्लग-इन सोच पसंद है और पूर्वनिर्मित उदाहरण होने चाहिए। यदि अन्य लोग अन्य फ़िल्टर के साथ आते हैं, तो उन्हें प्लग एंड प्ले होना चाहिए। वह महान होगा। मैं इस बात से पूरी तरह सहमत हूं कि फिल्टर बनाना यूजरलैंड की जिम्मेदारी है।

जो अभी भी वांछित है वह है पाइप और चेनिंग क्षमताएं और मूल फ़िल्टर सुविधा की वैश्विकता। वैश्विकता के बारे में चिंताओं को @yyx990803 द्वारा कवर किया गया था। कैसे पाइप के साथ जंजीर के बारे में? यह टेम्प्लेट को पढ़ने और आउटपुट के रूप में क्या अपेक्षित है, यह समझने में एक टन की मदद करता है। पाइप और चेनिंग की चर्चा ऊपर की गई थी। क्या यह अभी भी किया जा सकता है? यह बिल्कुल भी बुरी बात क्यों है? डिजाइनर के लिए, यह सोना है! फ़िल्टर एक डिज़ाइनर का टूल है, JS प्रोग्रामर का नहीं। इसलिए, बेहतर JS लिखने का तर्क मेरी पुस्तक में, बोर्ड से हट जाता है, लेकिन मैं समझ सकता हूँ कि इसकी आवश्यकता क्यों होगी। लेकिन, एक डिजाइनर के रूप में, मैं बेहतर कोड भी लिखना चाहता हूं, और फिल्टर मुझे खूबसूरती से अनुमति देता है। :मुस्कुराओ:

स्कॉट

यहां चेनिंग के बारे में बात है - फिल्टर मुख्य रूप से दो उद्देश्यों के लिए उपयोग किए जाते हैं:

1. स्वरूपण पाठ;
2. एक सरणी प्रसंस्करण।

टेक्स्ट को फ़ॉर्मेट करने के मामले में, 90% या अधिक बार केवल एक ही उपयोगिता पद्धति का उपयोग किया जाता है। चेनिंग वास्तव में इस मामले में इतनी समस्या नहीं है।

सरणियों के लिए: मैंने पहले ही बताया है कि सरणी प्रसंस्करण वास्तव में तर्क है और जावास्क्रिप्ट में बेहतर अनुकूल है। एकाधिक जंजीर वाले सरणी फ़िल्टर होने पर यह आसान लग सकता है, लेकिन जब आप प्रत्येक के लिए 1 से अधिक तर्कों का उपयोग करते हैं तो बदसूरत हो सकते हैं। यह आपको अपने टेम्पलेट में बहुत अधिक तर्क डालने के लिए भी प्रोत्साहित कर रहा है जब आपको वास्तव में ऐसा नहीं करना चाहिए। वे अनम्य भी हैं (संसाधित मूल्य को आसानी से प्राप्त नहीं कर सकते)। इसकी तुलना में, ES2015 मूल उदाहरण के साथ है

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

के रूप में लिखा जा सकता है:

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

यह सिर्फ जावास्क्रिप्ट है, इसमें सीखने के लिए कोई जादू नहीं है, कोई वैकल्पिक वाक्यविन्यास और फ़िल्टर-विशिष्ट एपीआई नहीं है। और आप संसाधित मूल्य (जो बुद्धिमानी से कैश किया गया है) तक पहुंच सकते हैं। आप इसके ऊपर चीनी डालने के लिए भी स्वतंत्र हैं जैसा कि पिछली टिप्पणियों में दिखाया गया है। साथ ही, आपका टेम्प्लेट साफ दिखता है:

<div v-for="filteredThings">

मुझे पता है कि यह एक आसान चीज की तरह है, लेकिन ईमानदारी से, फ़िल्टर के लिए तर्क अभी मुझे लगता है जैसे सिंटैक्स के लिए सिंटैक्स को रखने की कोशिश कर रहा है। मेरी राय में, किसी विशेषता को सही ठहराने में "क्योंकि यह सुरुचिपूर्ण है" से अधिक समय लगता है - इसे उद्देश्य मूल्य प्रदान करने की आवश्यकता है। inline-templates लिए यह मामला था, लेकिन मैं इसे फ़िल्टर के लिए नहीं देखता।

@ yyx990803 - आपका उदाहरण इस मुद्दे का उदाहरण है, मुझे लगता है। दोबारा, मैं सबसे अच्छा जेएस प्रोग्रामर नहीं हूं, लेकिन मुझे यह जानने के filteredThings जेएस प्रोग्रामर होने की आवश्यकता नहीं है कि यह वास्तव में क्या करता है इसके बारे में कुछ भी नहीं कहता है। मेरे लिए, यह एक बुरा अभ्यास है। : मुस्कान: तथ्य यह है कि फ़िल्टरिंग विधि वैश्विक है इसका मतलब यह भी है कि मुझे दस्तावेज़ों, कोड में खोज करना चाहिए या यह पता लगाने के लिए आउटपुट को समझना चाहिए कि विधि क्या करती है। वास्तव में सुरुचिपूर्ण नहीं। सही?

तो ठीक है। हमारे पास एक विधि नाम हो सकता है जैसे 'filterByOrderByAndLimit'। तर्कों के बारे में क्या?

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

क्या यह सही होगा?

अगर ऐसा है तो यह संभव हो सकता है। फिर भी अच्छा नहीं लगता।

और, अब मैं केवल फ़िल्टरबी और ऑर्डरबी चाहता हूं। क्या मुझे ऐसा करने के लिए एक अलग विधि की भी आवश्यकता है? और फिर मैं मुद्रा स्वरूपण जोड़ना चाहता हूं। एक और तरीका? टेम्प्लेट में फ़िल्टर चेनिंग प्रस्तुति को लचीला और बहुत अभिव्यंजक बनाता है। इस चिंता को अभी तक तरीकों से ठीक से संबोधित नहीं किया गया है (और मेरे ज्ञान की कमी मुझे यह समझने की अनुमति नहीं दे रही है कि तरीके बेहतर हो सकते हैं)।

क्या यह संभव हो सकता है?

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

मैं मानता हूं कि किसी टेम्पलेट में बहुत अधिक तर्क करना कुछ ऐसा है जिससे बचना चाहिए। लेकिन, फ़िल्टर चेनिंग और ऐप के घटकों/टेम्पलेट्स में कहीं भी एक फ़िल्टर में बस पॉप करने की क्षमता एक शानदार अवधारणा है और एक कारण था कि आपने इसे शुरू करने के लिए क्यों जोड़ा। वह कारण या कारण क्या था? यदि आप उन्हें नाम दे सकते हैं, तो मैं शर्त लगा सकता हूं कि वे पैसे से अधिक "लेकिन यह बुरी प्रथाओं को बढ़ावा देता है" एक मील से।

जो कुछ भी लचीलेपन की अनुमति देता है, उसका उपयोग Vue की तरह ही अनुचित तरीके से किया जा सकता है। inline-template के लिए मुख्य तर्क यह था कि यह लचीला था और Vue को विभिन्न तरीकों से उपयोग करने की अनुमति देता था। फ़िल्टर बहुत अलग नहीं हैं, इसके अलावा यह Vue आंतरिक है और यह प्रभावित नहीं करता है कि Vue को बाहरी रूप से कैसे उपयोग किया जा सकता है। फिर भी, यह इसके महत्व का अवमूल्यन नहीं करता है। याद रखें, बहुत से लोगों ने यह भी कहा है कि यह उनके लिए अपग्रेड करने के लिए नो-गो होगा। यह इतना महत्वपूर्ण है! :मुस्कुराओ:

नए तरीके को बस उन्हीं विशेषताओं की जरूरत है जो पुराने तरीके से थीं।

• जंजीर
• वैश्विक
• टेम्प्लेट में जोड़ें ताकि यह अच्छी तरह से व्यक्त किया जा सके कि टेम्प्लेट में डेटा में हेरफेर कैसे किया जाएगा

(क्या मैं कुछ भूल गया?)

अगर यह वह सब कर सकता है, तो मुझे यकीन है कि हर कोई काफी संतुष्ट होगा। मैं व्यक्तिगत रूप से इसे विधियों (अभी तक) के साथ नहीं देख सकता।

स्कॉट

@smolinari

1. मैंने स्पष्ट रूप से कहा है कि आपको अपने टेम्प्लेट में कम तर्क रखना चाहिए। यह मेरी राय है कि आप इसे पसंद करते हैं या नहीं। जाहिर है आप असहमत होने के लिए स्वतंत्र हैं, लेकिन अगर आप अनुशंसित सर्वोत्तम अभ्यास के खिलाफ काम करना चाहते हैं तो मैं आपकी मदद नहीं कर सकता।
2. दिया गया (1) - मैंने समझाया है कि क्यों जंजीर एक मुद्दा नहीं है क्योंकि जटिल तर्क जावास्क्रिप्ट में किया जाना चाहिए।
3. मैंने यह भी उदाहरण दिया है कि आप विश्व स्तर पर उपलब्ध विधियों को कैसे जोड़ सकते हैं।
4. आप जो चाहते हैं उसके समान कस्टम चेनिंग सिंटैक्स पर @ कठोरता 789 का उदाहरण देखें।
5. फ्रेमवर्क का लक्ष्य यह प्रदान करना है कि _I_ क्या मानता है कि फ्रंट एंड एप्लिकेशन विकसित करने का सबसे अच्छा तरीका है, न कि सभी को खुश करना। तो कृपया "यदि आप मुझे यह सुविधा वापस नहीं देते हैं तो मैं अपग्रेड नहीं करूंगा" का उपयोग न करें - यह काम नहीं करता है।

आप लोग एक सप्ताह के लिए इस नए अल्फा रिलीज को क्यों नहीं आजमाते हैं और फिर कुछ वास्तव में मूल्यवान टिप्पणियों के साथ आते हैं (आपके अभ्यास के आधार पर)? हो सकता है कि अपने मौजूदा ऐप को रिफैक्टर करने का प्रयास करें और हमें बताएं कि क्या असंभव था, क्या सुधार हुआ, क्या खराब हुआ, ताकि हम इस पर बेहतर चर्चा कर सकें। मेरे विचार से यह सबके लिए उपयोगी होगा।

@yyx990803 - मैं 1 के लिए सहमत हूं। तो हम सहमत हैं। : मुस्कान: मैं इस बात से सहमत नहीं हूं कि यह कुछ ऐसा करने का एक उचित कारण है जिसे इतना प्यार मिला था।

तो, मुझे लगता है कि आपने समय के साथ तय कर लिया है कि व्यावहारिक जेएस व्यावहारिक एचटीएमएल से बेहतर है?

अपग्रेड न करने के लिए नो-गो का तर्क दूसरों ने कहा है। मैं बस संवाद करने और इसे कम करने की कोशिश कर रहा हूं।

मेरी ओर से एक आखिरी तर्क। इसे यूजर के यूजर की नजर से देखें। मान लें कि मेरे पास लैरावेल या कुछ अन्य एमवीसी या एमवीवीएम सिस्टम जैसी प्रणाली है जिसमें वीयू शामिल है, जो उस सिस्टम के उपयोगकर्ता को अपने स्वयं के घटकों का निर्माण करने की अनुमति देता है। फ़िल्टर, जैसा कि था, सीखने की अवस्था को सरल करता है और यह उस सिस्टम के उपयोगकर्ताओं को किसी भी JS को छुए बिना बहुत कुछ करने की अनुमति देता है। मैं वू का प्रशंसक हूं, क्योंकि इसने गैर-जेएस प्रोग्रामर को अभी भी बहुत कुछ करने की अनुमति दी है। यही कारण है कि मुझे रिएक्ट और JSX पसंद नहीं है। समय बीतने के साथ उस संयोजन का Vue पर बहुत छोटा उपयोगकर्ता आधार होगा। मैं उस पर पैसा लगाऊंगा।

मैं यह भी समझता हूं कि वास्तविक लचीलापन जेएस में है। फिर भी, कृपया Vue में लचीलेपन के लिए केवल JS पर निर्भर न रहें। ध्यान रखें, हर कोई हत्यारा JS प्रोग्रामर नहीं होता है। वास्तव में, ज्यादातर लोग नहीं हैं। फ़िल्टर उन लोगों के लिए बहुत कुछ करने का एक अच्छा तरीका था और यह आगे JS हेरफेर की दिशा में एक अच्छा कदम था। फ़िल्टर इसे पूरा नहीं कर सकते? JS विधियों के बारे में गहराई से जानें।

ठीक। मेरी ओर से बहुत हो गया..... मैं कर चुका हूँ। और, किसी भी दर पर सुनने के लिए धन्यवाद। व्यू अभी भी कमाल है! :मुस्कुराओ:

@ अज़मत-शारापोव - अच्छी बात है।

स्कॉट

लोगों को जेएस के अंदर खराब प्रथाओं को सही ठहराने की कोशिश करते हुए देखकर मुझे दुख होता है। वास्तव में, आपको पेशेवर होने की ज़रूरत नहीं है, बस मूल गृहकार्य करें (या आजकल यह बुनियादी नहीं है?)

मेरे पास फ़िल्टर-अंदर-विधियों के साथ समस्या अर्थशास्त्र की है।

उफ़ शब्द में, फ़िल्टर स्थिर कार्यों की तरह होते हैं जबकि विधियाँ गैर-स्थैतिक कार्य होती हैं।

फ़िल्टर विधियों की तुलना में अत्यंत भिन्न शब्दार्थ बताते हैं। सबसे बड़ा अंतर यह है कि फ़िल्टर this का उपयोग नहीं कर सकते, लेकिन तरीके कर सकते हैं।

@ yyx990803 Vue.prototype.filters का उपयोग करते समय काम कर सकता है लेकिन Vue को बदलना मेरे लिए अच्छा अभ्यास नहीं लगता है। मैं इसके बजाय एक अलग (वैश्विक) वस्तु बनाने की वकालत करूंगा जिसमें सभी फिल्टर होंगे।

यह अच्छा अभ्यास नहीं लगता क्योंकि ग्लोबल्स अच्छा अभ्यास नहीं है। अनुशंसित दृष्टिकोण स्पष्ट रूप से सहायक विधियों का आयात कर रहा है। प्रोटोटाइप से जुड़ना उन लोगों के लिए एक समाधान है जो स्पष्ट रूप से विधियों को आयात नहीं करना चाहते हैं।

शब्दार्थ के लिए - वैसे भी फिल्टर एक गढ़ी हुई अवधारणा है। जावास्क्रिप्ट में आप केवल एक स्ट्रिंग को अपरकेस करने के लिए एक अलग शब्दार्थ का आविष्कार नहीं करेंगे - आप एक फ़ंक्शन को कॉल करते हैं। और वे यही हैं, जावास्क्रिप्ट कार्य करता है।

मैं अपनी व्यक्तिगत बात को स्पष्ट करने की कोशिश करने के लिए एक और टिप्पणी करने जा रहा हूं, मुख्य रूप से "जेएस के अंदर खराब प्रथाओं को सही ठहराने की कोशिश" टिप्पणी के कारण। मैं निश्चित रूप से ऐसा करने की कोशिश नहीं कर रहा हूं।

मुझे एहसास है कि Vue सिर्फ एक टेम्प्लेटिंग सिस्टम से अधिक है, लेकिन, यह एक टेम्प्लेटिंग सिस्टम भी है और मुझे डर है कि यह उस भूमिका से दूर जाने की कोशिश कर रहा है, जो मुझे लगता है कि इसे नहीं करना चाहिए। इसलिए एक टेम्प्लेटिंग इंजन/सिस्टम के रूप में, एक टेम्प्लेटिंग सिस्टम से कोई क्या उम्मीद कर सकता है, इसका एक बहुत ही सफल उदाहरण के रूप में ट्विग टेम्प्लेटिंग इंजन को लें। उनके पास उनके दस्तावेज़ों में " टेम्पलेट डिजाइनरों के लिए " अनुभाग और " डेवलपर्स के लिए " अनुभाग है। एक टेम्प्लेटिंग सिस्टम के रूप में, Twig टेम्प्लेट डिज़ाइनर के लिए भी शक्तिशाली है, क्योंकि यह फ़िल्टर सहित डिफ़ॉल्ट व्यवहारों से भरा हुआ है । यह गैर-डेवलपर्स को सीधे PHP को जाने बिना टेम्पलेट सिस्टम के साथ एक टन करने की अनुमति देता है। उन्हें बस यह सीखना है कि टहनी को क्या पेशकश करनी है और इसका उपयोग कैसे करना है। मैं इसे Vue में भी ढूंढ रहा हूं। मैं दस्तावेज़ों में "टेम्पलेट डिज़ाइनरों के लिए Vue" अनुभाग भी देखना चाहता हूँ। :मुस्कुराओ:

साथ ही, टहनी की एक्स्टेंसिबिलिटी बहुत महत्वपूर्ण है। यदि स्टॉक संस्करण में कुछ उपलब्ध नहीं है, तो इसे जोड़ा जा सकता है। वह तब होता है जब डेवलपर कदम रखता है। अच्छी बात यह है कि एक्सटेंशन साझा किए जा सकते हैं, जिसका अर्थ है कि इसे केवल एक बार करना होगा।

इन दो स्तरों के डिज़ाइनर/डेवलपर के बारे में दूसरी अच्छी बात यह है कि आपको उपयोगकर्ताओं का अधिक व्यापक आधार मिलता है। बहुत, बहुत व्यापक और यह के साथ भी ऐसा ही है। और जब व्यवहार चूक पर्याप्त नहीं होती है, तब वे स्वेच्छा से अंतर्निहित भाषा सीखना शुरू करते हैं। और वह तब होता है जब वे सर्वोत्तम अभ्यास और बाकी सीखते हैं।

यदि आप कह रहे हैं, JS सीखने के बिना Vue एक टेम्प्लेट इंजन नहीं हो सकता है, तो मैं कहूंगा, यह अपने बाजार मूल्य को काफी कम कर रहा है। यदि आप कहते हैं, तो आप दूसरों को टेम्पलेट इंजन के लिए प्लग-इन के रूप में उन उपकरणों को बनाने के लिए दरवाजा खुला छोड़ देंगे, बढ़िया। लेकिन, तब हर कोई इस बात के लिए लड़ रहा होगा कि टेंपलेटिंग सिस्टम में क्या होना चाहिए। वह भी प्रतिकूल IMHO है।

आपके छात्र में फ़िल्टर उदाहरण इवान के बारे में बात करते हुए, क्या कोई JS सीख रहा था या कोई टेम्पलेट इंजन सीख रहा था? अगर यह बाद वाला था, तो मुझे यकीन है कि बातचीत अलग तरह से होगी।

किसी भी कीमत पर। मुझे अभी भी लगता है कि Vue एक विजेता प्रणाली है। मुझे उम्मीद है कि मेरे विचार दूसरों को Vue की भूमिकाओं के बारे में अलग तरह से सोचने पर मजबूर कर सकते हैं। :मुस्कुराओ:

स्कॉट

@ yyx990803 यदि फिल्टर गढ़े गए अवधारणा हैं, तो उन्हें पहले स्थान पर क्यों बनाया गया था?

मेरा मानना ​​​​है कि <template> के अंदर सभी बाहरी चर जैसे $data या abc को this.$data और this.abc $ में परिवर्तित कर दिया गया है और इसलिए सादे जेएस कार्यों को परिभाषित किया गया है घटक के बाहर संदर्भित नहीं किया जा सकता है। इस सीमा को पार करने के लिए फिल्टर पेश किए गए थे।

वह सीमा अभी भी मौजूद है --- मुझे लगता है कि मैं सही हूं --- सीमा को हटाने के लिए देवों को this.abc को संदर्भित करने के लिए this.abc को स्पष्ट रूप से कोड करने की आवश्यकता होगी और जेएस फ़ंक्शंस तक पहुंचें क्योंकि उन्हें संदर्भित किया जाएगा जेएस

लेकिन यह बहुत शक्तिशाली विशेषता होगी, दुरुपयोग की संभावना होगी और पुराने कोड को माइग्रेट करना एक दर्द होगा। वर्तमान वाक्य-विन्यास मेरे लिए उससे कहीं बेहतर दिखता है।

मैं आपसे सहमत हूं कि फ़िल्टर मूल रूप से जेएस फ़ंक्शन हैं और उन्हें घटक में आयात किया जाना चाहिए। मुझे यह पसंद नहीं है कि उन्हें विधियों के समान स्थान पर परिभाषित किया गया हो।

हेलो सब लोग। मैंने पूरा सूत्र पढ़ा और मुझे यही लगता है।

• orderBy filterBy और किसी भी अन्य जैसे अंतर्निहित फ़िल्टर को कोई नहीं छोड़ेगा
• हर कोई जो अभी भी चाहता है वह टेम्पलेट्स में पाइप ऑपरेटर है
• कोर टीम का कहना है कि लॉजिक को जावास्क्रिप्ट में रखना चाहिए, टेम्प्लेट में नहीं, इसके अलावा पाइप ऑपरेटर के साथ आने वाली es7 सुविधा है।

एक त्वरित सारांश के रूप में, जो मुझे लगता है कि यह एक अच्छा समाधान हो सकता है जब तक कि जेएस एक देशी पाइप ऑपरेटर को लागू नहीं करता है, पाइप ऑपरेटर को एक प्लगइन के रूप में रखना होगा और 2.0 संस्करण को वैसा ही रखना होगा। तो, उपयोगकर्ता कर सकते हैं

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

जबकि हम नई सुविधा के कार्यान्वयन की प्रतीक्षा करते हैं, इसे आने वाले बहिष्करण या कुछ और के बारे में कुछ चेतावनी के साथ शामिल किया जा सकता है। मुझे पता है कि कोई भी उस प्लगइन को लागू कर सकता है, लेकिन मुझे लगता है कि यह बेहतर होगा अगर इसे Vue टीम द्वारा प्रदान और रखा जाए, क्या यह संभव हो सकता है?

मैं गलत हो सकता था, लेकिन मुझे नहीं लगता कि Vue प्लगइन्स को इसके कंपाइलर के साथ गड़बड़ करने की अनुमति देता है ..

@ अज़मत-शारापोव बिल्कुल नहीं। मैंने अभी नहीं सोचा था कि यह वू कंपाइलर के साथ गड़बड़ करेगा: open_mouth:

@YerkoPalma मैं बिल्कुल _love_ पाइप ऑपरेटर। मैं इसे कार्यात्मक भाषाओं में जुनूनी रूप से उपयोग करता हूं और इसे जावास्क्रिप्ट में रखने के लिए इंतजार नहीं कर सकता! _लेकिन_, कल्पना कीजिए कि Vue में कभी फ़िल्टर नहीं थे। क्या आप अनुरोध कर रहे हैं कि एक फ्रंटएंड फ्रेमवर्क जावास्क्रिप्ट के सिंटैक्स का विस्तार करे? यह बैबेल का डोमेन है या एक कंपाइल-टू-जेएस भाषा है, यूआई फ्रेमवर्क नहीं। यदि आप लाइवस्क्रिप्ट जैसी भाषा का उपयोग करना पसंद करते हैं, जैसा कि मैं अक्सर करता हूं, तो आप कर सकते हैं। लेकिन यहाँ समस्या Vue के साथ नहीं है। यह जावास्क्रिप्ट के साथ ही है और हम इसे ठीक करने के लिए यहां नहीं हैं।

इसके अतिरिक्त, यदि हम अपनी उम्मीद के अनुसार 2.0 में रेंडर के परिणामों को Babel के माध्यम से पाइप करने में सक्षम हैं, तो आप गैर-TC39 ट्रैक किए गए प्लगइन का उपयोग करने में सक्षम होंगे यदि आप चाहें - लगातार, अपने जावास्क्रिप्ट में हर जगह, इसके बजाय बस टेम्पलेट में। तो अगर आप सिर्फ एक पाइप चाहते हैं, तो संभव है कि आप इसे प्राप्त करने में सक्षम होंगे। और आप _can_ आज इसे 1.x में प्राप्त कर सकते हैं - बस सावधान रहें कि आप अपने टेम्प्लेट में जिस पाइप का उपयोग कर रहे हैं, उसकी प्राथमिकता और व्यवहार आपके Babel से भिन्न होने की संभावना है।

@smolinari और अन्य। दो मुहावरे हैं (और उनके रूपांतर हैं) मैं सुनता रहता हूं:

• "डेवलपर्स / उपयोगकर्ता के दृष्टिकोण के बारे में सोचें"
• "शुरुआती के बारे में सोचो"

दोनों एक धारणा का संकेत देते हैं - कि हम इन समूहों के बारे में सोच रहे हैं।

मैंने पहले भी इसका उल्लेख किया है, लेकिन मुझे लगता है कि इसे दोहराने की जरूरत है। कोर टीम में _हर कोई_ या तो एक डिज़ाइनर, फ़्रंटएंड डेवलपर, या दोनों का संयोजन है । हम इन उपकरणों का उपयोग प्रतिदिन अपने काम के लिए करते हैं। हम Vue 2.0 का भी उपयोग करेंगे। मेरा विश्वास करो, हम इसके बारे में सोच रहे हैं। मैं

शुरुआती लोगों के लिए, मैंने यहां एक मामला बनाया

उस दृष्टिकोण से, मैं आपको बता सकता हूं कि पहली बार में फिल्टर रोमांचक जादू की तरह लग सकते हैं, वे अंततः सीमित सुविधा के लिए अधिक जटिलता का परिचय देकर एक छात्र के सीखने को धीमा कर देते हैं। अगर वे एंगुलर या वीयू में कभी नहीं रहे होते और इस बातचीत को उलट दिया जाता - हम 2.0 में उन्हें _introduce_ करने की कोशिश कर रहे थे - हमें यह समझाने में मुश्किल होगी कि उनकी आवश्यकता क्यों थी और आपको उनका उपयोग कब करना चाहिए।

इससे पहले कि 2.0 में एक बहिष्करण की कोई बात होती, मैंने अपने कोड स्कूल में पाठ्यक्रम से फ़िल्टर हटा दिए थे, क्योंकि हमने पर्याप्त सबूत एकत्र किए थे कि वे शुरुआती लोगों के लिए अच्छे से ज्यादा नुकसान कर रहे थे। इसके बजाय हम चाहते हैं कि वे अधिक बहुमुखी Vue सुविधाओं के साथ अनुभव प्राप्त करें, जैसे कि विधियाँ और गणना की गई विशेषताएँ। हमने फ़िल्टर के उपयोग को भी हतोत्साहित किया, क्योंकि उन्होंने खराब प्रथाओं को चुनना आसान बना दिया।

आशा है कि इन दोनों शिकायतों पर प्रकाश डाला जाएगा। हम देखेंगे। मैं

लेकिन, कल्पना कीजिए कि Vue में कभी फ़िल्टर नहीं थे। क्या आप अनुरोध कर रहे हैं कि एक फ्रंटएंड फ्रेमवर्क जावास्क्रिप्ट के सिंटैक्स का विस्तार करे?

निश्चित रूप से, जैसा कि पहले उल्लेख किया गया है, फ़िल्टर _templates_ के लिए बहुत स्वाभाविक हैं, जैसा कि टहनी में है। मुझे लगता है कि एक पाइप ऑपरेटर होना उतना ही स्वाभाविक है जितना कि टेम्प्लेट में मूंछों का सिंटैक्स होना, मेरा मतलब है, मूंछें html नहीं हैं, और जावास्क्रिप्ट नहीं है, क्या आप लोग उन्हें भी हटाने जा रहे हैं? पाइप ऑपरेटर के साथ क्या अलग है?

"बच्चों के बारे में सोचो" तर्क सिर्फ गूंगा है। जहां तक ​​​​मुझे पता है, Vue को जावास्क्रिप्ट सिखाने के लिए नहीं बनाया गया है, बल्कि फ्रंट-एंड डेवलपर्स के लिए बकवास करने के लिए डिज़ाइन किया गया है। बाद के फिल्टर के लिए महान हैं।

अगर वे एंगुलर या वीयू में कभी नहीं रहे होते और यह बातचीत उलट जाती - हम उन्हें 2.0 में पेश करने की कोशिश कर रहे थे - हमें यह समझाने में कठिन समय होगा कि उनकी आवश्यकता क्यों थी और आपको उनका उपयोग कब करना चाहिए।

मैं बहुत असहमत हूं। मैं 2005 से Django नामक एक पायथन ढांचे का उपयोग कर रहा हूं और इसकी टेम्प्लेटिंग भाषा - जो बाद में पैदा हुई अधिकांश टेम्प्लेटिंग भाषाओं के लिए प्रेरणा रही है - में पहले दिन से ही फिल्टर हैं। दस वर्षों में फ्रंट-एंड डेवलपर्स के साथ उनका उपयोग करने के बाद, मैं उनकी सुंदरता और उपयोगिता की सराहना करने लगा हूं। इस वाक्य-विन्यास को जाते हुए देखना दुखद होगा।

(यहाँ Django फिल्टर के साथ क्या करता है: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen कृपया अपने स्वर पर ध्यान दें - दूसरों के तर्कों को गूंगा कहना चर्चा में भाग लेने का रचनात्मक तरीका नहीं है।

उन लोगों के लिए जो सर्वर-साइड टेम्प्लेटिंग भाषाओं के अनुरूप हैं - ध्यान देने योग्य एक महत्वपूर्ण पहलू यह है कि सर्वर-साइड टेम्प्लेट भाषाओं में उतनी लचीलेपन की मात्रा नहीं होती है जितनी Vue टेम्प्लेट में होती है (कोई कंप्यूटेड गुण, सीमित अभिव्यक्ति नहीं)। इसके अलावा - वे पूरी तरह से अलग उद्देश्यों के लिए बनाए गए हैं: स्थिर तारों को आउटपुट करना। Vue टेम्प्लेट इंटरएक्टिव DOM का प्रतिनिधित्व करते हैं - दो-तरफ़ा बाइंडिंग, इवेंट हैंडलर, कंपोनेंट प्रॉप्स और बहुत कुछ हैं। फ़िल्टर केवल Vue संदर्भ में बहुत सीमित उपयोग के मामले में फिट होते हैं: आज मेरा मानना ​​है कि हर जगह फ़िल्टर की अनुमति देना एक बुरा विचार है, उदाहरण के लिए v-मॉडल, v-for और v-on पर फ़िल्टर अच्छे से अधिक जटिलता का परिचय देते हैं।

एक संभावित विकल्प फिल्टर रखना है लेकिन केवल टेक्स्ट इंटरपोलेशन के लिए - यानी आप इसे केवल {{ }} s के अंदर उपयोग कर सकते हैं, निर्देशों में नहीं।

एक दिलचस्प संदर्भ के रूप में: कोणीय 2 में अभी भी फ़िल्टर हैं (नाम बदलकर "पाइप") लेकिन उन्होंने जानबूझकर सूची फ़िल्टरिंग को हटा दिया।

मेरी भाषा के लिए खेद है, किसी का अपमान करने का मतलब नहीं है।

मेरे लिए एक ढांचे का उद्देश्य _is_ कठिन सामान करना और इन उपकरणों का उपयोग करने वाले डेवलपर्स के लिए इसे आसान बनाना है। मैं अभी भी तर्क देता हूं कि वाक्य रचना को हराया नहीं जा सकता है और, फिर से, इसे जाते हुए देखना दुखद होगा।

मैं हुड तंत्र के तहत बहुत कुछ नहीं जानता या समझता हूं, लेकिन उपयोगकर्ताओं के दृष्टिकोण से, व्यावहारिकता शुद्धता को हरा देती है :)

संबंधित नोट में, यह देखना दिलचस्प रहा है कि इस समुदाय में कितना जुनून है। मेरे लिए Vue एक ताज़ा और स्फूर्तिदायक उपकरण रहा है, शायद इसीलिए मुझे खुद इस विशेष शेड को चित्रित करने में भाग लेना पड़ा :)

एक अन्य डेटापॉइंट के लिए, एम्बर में फ़िल्टर नहीं होते हैं और न ही यह घटक विधियों की अनुमति देता है, हालांकि इसमें गणना गुण होते हैं।

इन-टेम्पलेट ट्रांसफॉर्म करने वाले शुद्ध कार्यों के उपयोग के मामले के लिए, आपको एक हैंडलबार हेल्पर/एम्बर हेल्पर पंजीकृत करना होगा।
http://emberjs.com/api/classes/Ember.Helper.html

हैंडलबार हेल्पर्स उन चीजों से वाक्यात्मक रूप से अलग हैं जो हैंडलबार हेल्पर्स नहीं हैं, इसलिए मैं इसे लाता हूं। वे पाइपिंग फ़िल्टर सिंटैक्स के साथ समान रूप से मिल गए हैं। हालांकि हैंडलबार टेम्प्लेट "लॉजिक-लेस" होते हैं, जिसका अर्थ है कि उन्हें इन-टेम्पलेट फ़ंक्शन कॉल के लिए विशेष सिंटैक्स की आवश्यकता होती है। एक समस्या जो Vue के पास नहीं है।

शुरुआती लोगों के लिए फ़िल्टर सरल है, सुंदर आउटपुट के लिए उपयोग करके कुछ जादू देखें या सरणियों में फ़िल्टर\आदेश खोजें

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

और बर्तन पैकेज से विशिष्ट फिल्टर का उपयोग करें

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 में डेवलपर्स टेम्पलेट डिज़ाइनर के लिए कुछ बर्तन होने चाहिए, इसलिए हर समय लॉश, पल या किसी और की आवश्यकता नहीं है, बस npm से बर्तन स्थापित करें और इसका उपयोग करने में आसानी करें, लेकिन पुराने कॉल सिंटैक्स को सहेजें टेम्पलेट्स।
लेकिन फिल्टर के लिए एक महत्वपूर्ण विचार किया जाना चाहिए, शुद्ध कार्य होना चाहिए, जैसे कि vuex में गेटर्स।

यह समर्थन करने में आसान है, उपयोग करने में आसान हैपुन: उपयोग करेंविस्तार और टेम्पलेट्स पर इसकी अच्छी नज़र है।

आप लोगों को एक स्पष्ट अपग्रेड पथ और अपने जावास्क्रिप्ट कोड को संशोधित करने का तरीका सीखने की इच्छा है।

@thelinuxlich हम फिल्टर के बारे में बात करते हैं।

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

बस वाक्य रचना चीनी के लिए

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

लेकिन Vue\javascript में शुरुआती लोगों के लिए फ़िल्टर को पूरी तरह से बाहर करना खराब है। Laravel समुदाय Vue को क्यों पसंद करता है? क्योंकि यह सरल और शक्तिशाली है।

यदि हम फ़िल्टर को पूरी तरह से हटा देते हैं, तो _"टेम्पलेट डिज़ाइनरों के लिए"_ के लिए विकल्प देने की आवश्यकता है, यह जानने की कोई आवश्यकता नहीं है कि सरणी को कैसे सॉर्ट करें या फ़िल्टर करें, बस कोड फॉर्म उदाहरण दर्ज करें और परिणाम प्राप्त करें।

प्रोग्रामर को पता होना चाहिए कि कैसे _modularise_ 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)
   }
}

उदाहरण से और खुद पर गर्व है, सरणी को फ़िल्टर और सॉर्ट करने के लिए जेएस जानने की कोई आवश्यकता नहीं है, बहुत से लोग कुछ चीजें करना चाहते हैं, लेकिन कोड को समझना मुश्किल है जैसे

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

इसलिए इस प्रकार के लोगों के लिए जटिल चीजें बनाने की आवश्यकता नहीं है, अगर हम वहां के लिए सरल समाधान दे सकते हैं और यह डेवलपर्स के लिए अच्छा होगा।

एक संभावित विकल्प फिल्टर रखना है लेकिन केवल टेक्स्ट इंटरपोलेशन के लिए - यानी आप इसे केवल {{}} के अंदर उपयोग कर सकते हैं, निर्देशों में नहीं।

मुझे लगता है कि यह एक बहुत अच्छा समझौता हो सकता है। हालांकि यह हर किसी को संतुष्ट नहीं करेगा, लेकिन मैंने कभी भी फ़िल्टर का उपयोग किया है और मुझे वास्तव में यह अजीब लगता है कि वे वर्तमान में इससे अधिक कर सकते हैं।

यदि आप फ़िल्टर का उपयोग करना चाहते हैं और दो-तरफ़ा फ़िल्टर को प्रभावी ढंग से हटाकर जटिलता को कम करना चाहते हैं तो यह सुविधाजनक टेक्स्ट स्वरूपण की अनुमति देगा।

मेरी राय में, आपका मोमेंटज फिल्टर उदाहरण पहले से ही टेम्प्लेट में बहुत अधिक तर्क दे रहा है।

गंभीरता से, आपको यह सब "पाइप प्यार" को विशेष भंडार में तब तक निर्देशित करना चाहिए जब तक यह टीसी39 तक नहीं पहुंच जाता :)

मुझे वह पसंद है जो @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)
  }
}

डेवलपर के रूप में सोचें और किसी ऐसे व्यक्ति से पूछें जो जावास्क्रिप्ट नहीं जानता।

मेरे लिए, _not Developers_ के लिए ऐसा कुछ बेहतर है:

Vue.use(VueUtils)

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

यह मध्य है, और vue-resource की तरह उपयोग किया जाता है, जो कि सामान्य काम है।

पाइप के बारे में, मैं यह वाक्य रचना चीनी है

बातों में | फ़िल्टर 'फू' द्वारा | आदेश द्वारा 'बार' | सीमा 5

के लिये

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

पढ़ने में क्या आसानी?

यदि आपको 2 भिन्न टेम्प्लेट में डेटा पास करने की आवश्यकता है, तो आप एक डेटा के लिए 2 या 3 संशोधनों को संग्रहीत करते हैं?

अगर यह कुछ ऐसा हो:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

मैं अमूर्त स्थिति नहीं है, लेकिन अगर यह एक या दो टेम्पलेट्स में उपयोग करता है? आपको 10 या 100 वस्तुओं के लिए स्टोर डेटा चाहिए? स्मृति उपयोग बढ़ाएँ? हाँ, हम हेल्पर मेथड का उपयोग कर सकते हैं और इसे टेम्प्लेट में उपयोग कर सकते हैं, लेकिन _"टेम्पलेट डिज़ाइनरों के लिए"_ जो जावास्क्रिप्ट से बहुत दूर शीर्षक जैसा कुछ बेहतर है कैपिटलाइज़ करें |

अलग-अलग लोगों के बारे में सोचें, डेवलपर्स इसे अलग तरीके से आसानी से कर सकते हैं, लेकिन अन्य लोग इसे आसान बनाना चाहते हैं।

मैं इसे फिर से कहूंगा, टेम्प्लेट में बहुत अधिक तर्क एक विरोधी पैटर्न है। एक विशिष्ट डीएसएल (फ़िल्टर) सीखने के बजाय आपको जावास्क्रिप्ट सीखना चाहिए।

@thelinuxlich बस JSX का उपयोग करें और हमें 2-वे बाइंडिंग और कुछ अन्य चीजों के साथ रिएक्ट मिलता है।

लेकिन Vue के साथ हमें ऐसे लोग मिलते हैं जो जावास्क्रिप्ट नहीं जानते हैं, लेकिन Google के साथ कुछ कर सकते हैं और यदि आप पाइप को नापसंद करते हैं, तो इसका उपयोग न करें। हम बस कुछ इस तरह जोड़ सकते हैं

Vue.config.pipeFuncCall = true

और आप इसे चालू/बंद कर सकते हैं, लेकिन कुछ लोगों के लिए यह आसान हो सकता है।

_मैं फिर से कहूंगा, न केवल JS डेवलपर्स Vue का उपयोग कर सकते हैं, यह Vue का सबसे मजबूत पक्ष है।_

स्टैंडआर्ट आम फिल्टर की जरूरत है, लेकिन अलग-अलग काम में बेहतर होना चाहिए और इसे वू और उपयोग में जोड़ना आसान होगा।

या आप चाहते हैं कि Vue ASM जैसा कुछ हो और केवल अच्छे देव ही इसका उपयोग कर सकें?

दोस्तों, मुझे लगता है कि Vue कोर टीम द्वारा लिए गए निर्णय को बहुत अच्छी तरह से समझाया गया है। क्या हम एक ही बात को बार-बार नहीं दोहरा सकते हैं और केवल कुछ नया, मूल्यवान, यदि कोई हो, के साथ टिप्पणी नहीं कर सकते हैं?

यदि यह गैर-जेएस डेवलपर्स के लिए आसान होने के लिए 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 सरणियों को फ़िल्टर करने और इसे सॉर्ट करने के लिए, आदि, गणना का बेहतर उपयोग करें, यह बहुत साफ है। लेकिन मुझे लगता है कि डेटा को भिन्न प्रारूप में प्रदर्शित करने में समस्या है:

अगर हमारे पास फ़ील्ड create_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. फ़िल्टर समर्थित होंगे, लेकिन केवल टेक्स्ट इंटरपोलेशन के अंदर। जावास्क्रिप्ट भूमि में अन्य तर्कों को लागू करते समय यह उन्हें पाठ स्वरूपण उद्देश्यों तक सीमित कर देता है।
2. Vue 2.0 बिना बिल्ट-इन फिल्टर के शिप होगा। यदि आवश्यक हो तो समुदाय अपने स्वयं के फ़िल्टर पैक बना सकता है।
3. फ़िल्टर सिंटैक्स स्पेस-सीमांकित के बजाय तर्कों के लिए फ़ंक्शन इनवोकेशन सिंटैक्स का उपयोग करने के लिए बदल जाएगा। यह इसे जावास्क्रिप्ट और अन्य लोकप्रिय टेम्प्लेटिंग भाषाओं (जिंजा 2, स्विग, टहनी ...) के साथ और अधिक इनलाइन लाता है:

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

इवान सुनने के लिए धन्यवाद। यही बात Vue को बेहतरीन बनाती है। इसके पास एक महान नेता है। :मुस्कुराओ:

स्कॉट

@yyx990803 और @chrisvfritz

एक बात जो इस चर्चा में दबी हुई लगती है, वह है टू-वे फिल्टर। दो-तरफ़ा फ़िल्टर वे हैं जिन्हें अन्य प्रस्तावित समाधानों के साथ दोहराना सबसे कठिन है।

1. इस सरल उदाहरण पर विचार करें, जिसे मैंने उस फोरम थ्रेड में पोस्ट किया है। इसके लिए परिकलित गुणों का उपयोग करने से 2 मुख्य कमियां होंगी:
   
   
   
   1. आपको प्रत्येक मान के लिए एक नई गणना की गई संपत्ति बनानी होगी, जिसके परिणामस्वरूप एक टन बॉयलरप्लेट कोड होगा।
   
   
   2. मामलों को बदतर बनाने के लिए, गणना की गई संपत्तियों को नेस्ट भी नहीं किया जा सकता है। यदि आपके पास अधिक जटिल ऑब्जेक्ट ग्राफ़ है, तो आपके सभी गणना किए गए गुण शीर्ष स्तर पर होने चाहिए। आप लंबे, वर्बोज़ संपत्ति नामों के साथ समाप्त हो जाएंगे, जिन्हें लगातार गणना की गई संपत्ति ट्रैक का ट्रैक रखने के लिए अधिक संज्ञानात्मक अधिभार की आवश्यकता होती है, जो नेस्टेड मूल्य है।
   
   

इस उपयोग-मामले को "तुच्छ" या "कम जटिल" के रूप में खारिज करना प्रति-उत्पादक है। मैंने इसे मध्यम और बड़े पैमाने के अनुप्रयोगों दोनों पर उपयोग किया है। यह अद्भुत काम किया है! डेमो अनिवार्य रूप से सरल है, लेकिन तकनीक ध्वनि है।

1. v-for में एक सरणी के साथ काम करते समय यह और अधिक भ्रमित हो जाता है, जैसे कि इस उदाहरण में (फिर से, जानबूझकर सरल)। एक सरणी पर पुनरावृति करने पर आपको परिकलित गुणों में कोई सहारा नहीं मिलेगा। इसे हल करने का एकमात्र तरीका सरणी में प्रत्येक आइटम के लिए एक अलग घटक होना, और भी अधिक बॉयलरप्लेट जोड़ना है।

फ़िल्टर के साथ इस उदाहरण की तुलना करें:

``` जेएस
'कुछ-मुद्रा-फ़िल्टर' से मुद्रा आयात करें;
'उत्पाद-आधार' से उत्पादों का आयात;

नया व्यू({
एल: दस्तावेज़। शरीर,
डेटा: {उत्पाद},
फ़िल्टर: {मुद्रा},
});
```

फ़िल्टर के बिना एक के लिए:

``` जेएस
'कुछ-मुद्रा-फ़िल्टर' से मुद्रा आयात करें;
'उत्पाद-आधार' से उत्पादों का आयात;

नया व्यू({
एल: दस्तावेज़। शरीर,
डेटा: {उत्पाद},
अवयव: {
उत्पाद: {
सहारा: ['उत्पाद'],
परिकलित: {
कीमत: {
प्राप्त() {
वापसी मुद्रा।पढ़ें (यह उत्पाद। मूल्य);
},
मूल्य ते करना) {
this.product.price = Currency.write(value)
}
},
शिपिंग: {
प्राप्त() {
वापसी मुद्रा.पढ़ें (यह.उत्पाद.शिपिंग);
},
मूल्य ते करना) {
यह.उत्पाद.शिपिंग = मुद्रा.लिखें(मान)
}
},
हैंडलिंग: {
प्राप्त() {
वापसी करेंसी.रीड (यह.उत्पाद.हैंडलिंग);
},
मूल्य ते करना) {
this.product.handling = Currency.write(value)
}
},
छूट: {
प्राप्त() {
वापसी मुद्रा.पढ़ें (यह.उत्पाद.छूट);
},
मूल्य ते करना) {
यह.उत्पाद.छूट = मुद्रा.लिखें(मान)
}
}
}
}
}
});
```

मुझे पता है कि मैं उपरोक्त में से क्या लिखना चाहूँगा।

_{(इसे गणना की गई संपत्ति कारखानों को बनाकर थोड़ा साफ किया जा सकता है, लेकिन बात यह है कि ये आवश्यकता से कहीं अधिक क्रियात्मक हैं)}

चूंकि कोर टीम फिल्टर पाइप सिंटैक्स का दृढ़ता से विरोध करती है, क्या v-model निर्देश के लिए filter परम को पेश करना संभव होगा?

filter परम के साथ हम ऊपर जेएस के पहले सुरुचिपूर्ण संस्करण को रखने में सक्षम होंगे, और मैजिक पाइप सिंटैक्स के बजाय परम का उपयोग करने के लिए टेम्पलेट को फिर से लिखेंगे:

<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 उस निर्देश में आपके द्वारा किए गए तरीके से कहीं

निर्देश स्पष्ट रूप से अधिक सुविधाओं और सुधारों के साथ संशोधित किया जा सकता है, लेकिन बिंदु बनी हुई है: ये सभी बैंड-एड्स हैं जो किसी चीज़ के ऊपर हैं जो वास्तव में सरल होना चाहिए।

मैंने इस सूत्र में कस्टम निर्देशों का उल्लेख करते हुए कोई प्रस्ताव नहीं देखा है। क्या आप कृपया मुझे इस टिप्पणी की ओर संकेत करेंगे?

जैसा कि आप कल्पना कर सकते हैं, मैंने इसे आपके ऐप में उपयोग करने के लिए लिखा और परीक्षण नहीं किया है। मैं सिर्फ यह दिखाना चाहता था कि विकल्प के रूप में अभी क्या संभव है। यदि यह इतनी आसानी से संभव है, तो प्रक्रिया को और भी स्वचालित करने के लिए प्लगइन के लिए जगह हो सकती है।
यह स्पष्ट है कि इस त्वरित लिखित निर्देश में वी-मॉडल की पूर्ण कार्यक्षमता का अभाव है। हो सकता है कि पैरा और/या संशोधक के साथ संयुक्त एक कस्टम फ़िल्टर निर्देश फ़िल्टर को बदलने के लिए पर्याप्त होगा।

आइए रचनात्मक बने रहें, जैसा कि मैंने आपकी समस्या का समाधान करने की कोशिश की है। योगदान करने और आगे बढ़ने के बजाय किसी समाधान पर कोसना हमेशा आसान होता है।

@JosephSilber आपको चिल करने की जरूरत है। "बेतुका" एक मजबूत शब्द है।

नमस्ते, क्या फ़िल्टर को हटाना टेम्प्लेट अव्यवस्था को कम करके प्रेरित है या यह गंभीर रूप से प्रभावित कर रहा है
2.0 का तकनीकी कार्यान्वयन? यदि यह पूर्व दृश्य प्रभाव मुद्दा है, तो अनुमति देने के बारे में कैसे?
अभी की तरह फ़िल्टर करें (लेकिन नए जावास्क्रिप्ट फॉर्म के साथ)
लेकिन इसे केवल एक प्रति अभिव्यक्ति के लिए सीमित करना, जैसे v-for="i of list |orderBy('key')", (एक से अधिक पाइप साइन नहीं)
यह 2.0 में फिल्टर प्रोसेसिंग को सरल और अनुमानित और नेत्रहीन कम से कम बरबाद कर सकता है।
चूंकि {{}} के लिए फ़िल्टर पार्सिंग होगी, इसलिए इसे अन्य अभिव्यक्तियों में अनुमति देना समझ में आता है।
यह सभी मौजूदा उपयोग के मामलों/कार्यों को समायोजित करेगा (जैसे दो तरह से फ़िल्टरिंग, वी-फॉर के भीतर आइटम)।
एक से अधिक फ़िल्टर के किसी भी मौजूदा उपयोग को मालिकों द्वारा आसानी से एक में विलय/अपग्रेड किया जा सकता है।

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

हालांकि व्यक्तिगत रूप से, मैं इस उदाहरण के लिए एक कारखाना नहीं बनाऊंगा, क्योंकि इनमें से प्रत्येक गुण वास्तव में अलग-अलग चिंताएं हैं जो अभी केवल _appear_ समान हैं। जब आप फ़िल्टर हटाते हैं, तो यह अधिक स्पष्ट हो जाता है कि एक घटक कितना जटिल था। यही आप बॉयलरप्लेट के रूप में देख रहे हैं।

और यह एक बहुत बड़ा कारण है कि घटक _exist_. जटिलता को प्रबंधनीय सरोकारों में विभाजित करना। जब मैं एक घटक को देखता हूं, तो वह जो कुछ भी कर रहा है उसे आसानी से मेरी कार्यशील स्मृति में फिट होने की आवश्यकता होती है अन्यथा विकास बहुत धीमा और अधिक त्रुटि-प्रवण हो जाता है। फ़िल्टर के सिंटैक्स के पीछे की जटिलता को छिपाने से वह जटिलता दूर नहीं होती है.

इसे प्रदर्शित करने के लिए, आइए देखें कि जब समस्या वास्तविक दुनिया की बदलती आवश्यकताओं को पूरा करती है तो क्या होता है: मान लें कि आप तय करते हैं कि छूट को कीमत + शिपिंग + हैंडलिंग से बड़ा नहीं होने दिया जाना चाहिए। या हैंडलिंग X राशि से अधिक नहीं होनी चाहिए। या छूट फ़ील्ड मुद्रा के बजाय प्रतिशत होना चाहिए। या यदि कुल एक निश्चित राशि से अधिक है, तो न्यूनतम छूट स्वचालित रूप से लागू होनी चाहिए।

आप अतिरिक्त विकल्पों और सशर्त तर्क के साथ फ़िल्टर को अधिक जटिल बनाने के लिए ललचा सकते हैं। जैसे ही आप फ़िल्टर के एपीआई और आंतरिक तर्क को अपडेट करते हैं, अब आपको यह सोचना होगा कि आपके परिवर्तन फ़िल्टर का उपभोग करने वाली किसी भी चीज़ को कैसे प्रभावित कर सकते हैं - संभवतः वर्तमान घटक के बाहर भी, यदि यह एक साझा फ़िल्टर है। तो अब आप ऐसी स्थिति में हैं जहां अपने ऐप में बदलाव करना कठिन लगने लगता है। और यह सब इसलिए है क्योंकि एक साझा, दो-फ़िल्टर ने आपको घटक के बाहर आंतरिक घटक स्थिति को सौंपने, घटक सीमाओं का उल्लंघन करने, युग्मन बढ़ाने और जटिलता को छिपाने की अनुमति दी है, जिसके बारे में आपको अभी भी हर बार घटक पर काम करने के बारे में सोचने की आवश्यकता है।

अलग-अलग परिभाषित गणना गुणों या बाउंड प्रॉप्स के साथ चीजों को कई, व्यक्तिगत रूप से कम जटिल घटकों में तोड़कर, आप बदलती आवश्यकता को समायोजित करने के लिए अक्सर एक पंक्ति को अपडेट करते हैं। कोई अतिरिक्त विकल्प या सशर्त नहीं। स्केलिंग जटिलता को संतुष्ट करने के लिए कोई रिफैक्टरिंग नहीं। आपको घटक _ या उस एकल संपत्ति के बाहर भी कुछ भी सोचने की ज़रूरत नहीं है। आपका आवेदन शुरू से ही था और अभी भी इसके बारे में सोचना और अपडेट करना आसान है।

मुझे लगता है कि इस मामले में शुरू में जो चीज फिल्टर को आकर्षक बनाती है, क्या वे दोहराव के इलाज के लिए आसानी से उपलब्ध हैं। लेकिन डुप्लिकेशन बॉयलरप्लेट नहीं है जब यह आकस्मिक होता है (यानी वास्तविक दुनिया की समस्याएं अनिवार्य रूप से शुरू होने से पहले कोड अभी वही होता है)।

और मैं इसे सैंडी मेट्ज़ से बेहतर नहीं रख सकता:

दोहराव गलत अमूर्तता की तुलना में बहुत सस्ता है

@chrisvfritz फ़िल्टर का व्यावसायिक आवश्यकताओं से कोई लेना-देना नहीं है। फ़िल्टर केवल डेटा को प्रारूपित करते हैं। बस, इतना ही। वे इसे किसी भी तरह, आकार या रूप में हेरफेर नहीं करते हैं। filter="currency" अवधारणात्मक रूप से number परम के समान है। व्यावसायिक आवश्यकताओं को स्पष्ट रूप से फ़िल्टर में कभी भी नियंत्रित नहीं किया जाना चाहिए।

मान लें कि आप तय करते हैं कि छूट को कीमत + शिपिंग + हैंडलिंग से बड़ा नहीं होने देना चाहिए। या हैंडलिंग X राशि से अधिक नहीं होनी चाहिए।

तब आप कुछ उचित सत्यापन मॉड्यूल का उपयोग करेंगे, la vue-validator । मुद्रा फ़िल्टर जगह पर बना रहेगा, भले ही वह केवल अंतर्निहित मूल्य प्रदर्शित करे।

मुद्रा के बजाय छूट फ़ील्ड प्रतिशत होना चाहिए।

तब जाहिर है कि इसका प्रकार अब मुद्रा नहीं है। उपयोगकर्ता नाम की आवश्यकताएं बदलने पर आप type="text" के लिए type="email" $ के लिए स्वैप करने से अलग नहीं हैं। या तब भी जब आप number परम को हटा देते हैं जब कोई फ़ील्ड अब एक संख्या नहीं है।

यदि कुल एक निश्चित राशि से अधिक है, तो न्यूनतम छूट स्वचालित रूप से लागू होनी चाहिए।

फिर से, न्यूनतम लागू किया जाएगा, लेकिन मुद्रा फ़िल्टर यथावत रहेगा। आप अब भी इसे मुद्रा के रूप में प्रदर्शित करना चाहेंगे।

जैसे ही आप फ़िल्टर के एपीआई और आंतरिक तर्क को अपडेट करते हैं, अब आपको इस बारे में सोचना होगा कि आपके परिवर्तन फ़िल्टर का उपभोग करने वाली किसी भी चीज़ को कैसे प्रभावित कर सकते हैं [...] दो-फ़िल्टर ने आपको घटक के बाहर आंतरिक घटक स्थिति को सौंपने की अनुमति दी है

नहीं। आपने कभी भी कोई तर्क या स्थिति फ़िल्टर में ही नहीं डाली है। फ़िल्टर मूल्यों को स्वरूपित करने के लिए कड़ाई से एक निष्क्रिय कार्य है। आदर्श रूप से, इसे VM के संदर्भ में भी निष्पादित नहीं किया जाना चाहिए ; इसमें कोई this नहीं होना चाहिए जिससे अतिरिक्त डेटा निकाला जा सके।

दोहराव गलत अमूर्तता की तुलना में बहुत सस्ता है

... जब, जैसा कि आपने कहा था, आप कोड को सारगर्भित कर रहे हैं जो अभी वही होता है। दूसरी ओर, फिल्टर, सरल निष्क्रिय कार्य हैं जो एक मान को प्रारूपित करते हैं। वे बिल्कुल अमूर्त नहीं हैं।

टीएल; डॉ फिल्टर एक अमूर्त नहीं हैं, और वे स्पष्ट व्यावसायिक आवश्यकता के स्थान पर नहीं हैं। फ़िल्टर में कभी भी कोई आंतरिक तर्क नहीं होता है, और न ही कभी होना चाहिए। वे अवधारणात्मक रूप से HTML के type विशेषता और v-model के number परम के समान हैं।

दो तरह से फिल्टर निश्चित रूप से एक अमूर्त है। v-model पर दो-तरफ़ा फ़िल्टर का वर्तमान व्यवहार अंदर बहुत सारे जादू को छुपाता है - विशेष रूप से यह इनपुट के DOM मान को अंतर्निहित मॉडल के साथ अस्थायी रूप से आउट-ऑफ-सिंक करने की अनुमति देता है, और केवल उन्हें "सिंक" करता है जब आप क्षेत्र धुंधला. BTW @JosephSilber यह व्यवहार विशेष रूप से आपके अनुरोध के कारण लागू किया गया था, इसलिए मैं समझ सकता हूं कि आप इसके बारे में इतनी दृढ़ता से क्यों महसूस करते हैं।

हालाँकि, दो-तरफ़ा फ़िल्टर के साथ मुझे जो सबसे बड़ी समस्या दिखाई देती है, वह यह है कि अंतर्निहित तर्क एक ब्लैक बॉक्स है, और उपयोगकर्ता के पास सुविधा अनुरोध करने के अलावा इसे और अधिक अनुकूलित करने का कोई तरीका नहीं है। मेरे लिए, इस तरह के व्यवहार को स्वयं लागू करने के लिए उचित बिल्डिंग ब्लॉक्स प्रदान करना बेहतर विकल्प है। और मैं आपको दिखाता हूँ कि 2.0 में यह कैसे संभव है:

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

यहां हमारे पास आधार CustomInput घटक है जो वर्तमान दो-तरफा फ़िल्टर के "आउट-ऑफ-सिंक-तक-धुंधला" व्यवहार को लागू करता है। 2.0 में बदलावों के कारण, आप कस्टम घटकों पर सीधे v-model उपयोग कर सकते हैं, जब तक कि घटक value प्रोप स्वीकार करता है और $$ input ईवेंट उत्सर्जित करता है। इसके अलावा, यह change ईवेंट पर मान को भी प्रारूपित करता है, जो वर्तमान में दो-तरफ़ा फ़िल्टर के साथ संभव नहीं है । आप किसी भी वांछित व्यवहार को प्राप्त करने के लिए इस घटक को और अधिक ट्वीक कर सकते

मूल घटक पार्स/स्वरूपण तर्क को लागू नहीं करता है - आप विशिष्ट उपयोग के मामलों के अनुरूप कस्टम इनपुट घटकों को प्राप्त करने के लिए इसे parse और format विधियों के साथ विस्तारित करते हैं। इस मामले में, एक CurrencyInput घटक।

मूल घटक दो-तरफ़ा फ़िल्टर की तुलना में अधिक जटिल है, क्योंकि अब हम पिछले जादुई व्यवहार को स्वयं लागू कर रहे हैं। हालाँकि आपको केवल एक बार इस घटक को परिभाषित करने की आवश्यकता है। बदले में यदि आप इसे बाद में बदलना चाहते हैं तो आपको इस पर पूर्ण नियंत्रण प्राप्त होगा कि इसे कैसे व्यवहार करना चाहिए। मेरा मानना ​​है कि यह एक योग्य ट्रेडऑफ़ है।

यह एक उदाहरण है कि हमें घटकों में और अधिक कैसे सोचना चाहिए क्योंकि यह पुन: प्रयोज्यता के लिए एक एकीकृत अमूर्त है जो आपको सबसे अधिक नियंत्रण देता है। 2.0 select2 उदाहरण भी देखें - पहले 1.0 में इसे एक निर्देश के रूप में लागू किया गया था, लेकिन अब यह समान v-model इंटरफ़ेस वाला एक घटक है।

मेरे लिए, इस तरह के व्यवहार को स्वयं लागू करने के लिए उचित बिल्डिंग ब्लॉक्स प्रदान करना बेहतर विकल्प है।

यह बहुत अच्छा है और सबसे निश्चित रूप से Vue को क्या चाहिए, हालाँकि मैं इसे पढ़ना पसंद करता

मेरे लिए, बेहतर विकल्प Vue से शुरू करने के लिए उचित बिल्डिंग ब्लॉक्स प्रदान करना और Vue को स्वयं नए फ़िल्टरिंग व्यवहार के साथ विस्तारित करना है।

दूसरे शब्दों में, क्या मुद्रा इनपुट घटक कई अन्य डिफ़ॉल्ट फ़िल्टरिंग घटकों के साथ Vue का हिस्सा नहीं हो सकता है? क्योंकि, हर कोई किसी न किसी समय मुद्राओं का उपयोग करता है, है ना? एक ही काम को बार-बार करने का जिम्मा बाकी सभी पर क्यों छोड़ दिया जाए? मुद्रा स्वरूपण पर्याप्त मानक है जो इसे Vue के अपने फ़िल्टरिंग घटक टूल बैग का हिस्सा बनाता है और वे दूसरों के लिए अपने स्वयं के फ़िल्टरिंग घटकों को भी बनाना सीखने के लिए एक महान बुनियादी उदाहरण हैं।

और.....पूर्ण मुद्रा इनपुट घटक होने के उदाहरण से केवल एक चीज गायब है और वह है एक i18n सुविधा, जो मेरा मानना ​​है कि Vue को भी शामिल करना चाहिए। मुद्रा संख्या स्वरूपण व्यक्ति (दर्शक के) चयनित लोकेल के आधार पर बदलना चाहिए। मेरा मतलब है लोकेल डेटा यानी . "DE_de" मुद्रा और अन्य नंबरों को प्रारूपित करने के लिए जैसा कि इस लोकेल एक्सप्लोरर में दिखाया गया है (जो एक मानक से उपजा है)। इसे Vue में जोड़ें और आपके पास Vue में निर्मित एक महान मुद्रा / संख्या स्वरूपण घटक प्रणाली है, जो कि Vue का उपयोग करने वाले 1000 अन्य देवों को स्वयं को बनाने की आवश्यकता नहीं है, बल्कि वे मौके पर ही उपयोग कर सकते हैं, जब वे Vue प्राप्त करते हैं . यह Vue को एक शक्तिशाली टेम्प्लेटिंग सिस्टम बनाता है!

यदि इस "i18n स्वरूपण घटक" का उपयोग एक श्रृंखलित फैशन में 1.0 की तरह फ़िल्टर के रूप में नहीं किया जा सकता है, तो यह प्लग-इन करने योग्य होना चाहिए। यह भी ठीक होगा। ऑरेलिया यही कर रही है और टहनी भी अपने विस्तार के साथ यही करती है । मुद्रा इनपुट घटक अभी भी <currency-input> हो सकता है।

यह i18n और अन्य मानक टेम्प्लेटिंग फ़िल्टर वास्तव में कुछ ऐसा होना चाहिए जो दूसरों को लगातार पुन: पेश करने की आवश्यकता न हो, यदि उन्हें नहीं करना है। यदि आप मुझे दिखाते हैं कि ऐसा प्लग-इन कैसे बनाया जाता है, तो मैं आपके लिए i18n प्लग-इन भी करूंगा। मुझे इसमें पूरी दिलचस्पी है!: मुस्कान:

स्कॉट

क्योंकि, हर कोई किसी न किसी बिंदु पर मुद्राओं का उपयोग करता है, है ना?

नहीं वास्तव में कोई नहीं। मैंने, एक के लिए, वास्तव में इसका कभी भी उपयोग नहीं किया है :) अन्य सभी अंतर्निर्मित फ़िल्टरों पर भी यही लागू होगा - उनमें से कुछ हम में से कुछ के लिए उपयोगी होते हैं, जब अन्य बिल्कुल बेकार होते हैं। जब हम इस विषय पर होते हैं, तो अधिकांश समय मैं एक अंतर्निहित फ़िल्टर का उपयोग करना चाहता था, मैंने वैसे भी अपना स्वयं का संस्करण लिखना समाप्त कर दिया, अंतर्निहित संस्करण मृत कोड का प्रतिपादन किया।

एक i18n सुविधा, जो मेरा मानना ​​है कि Vue को भी शामिल होना चाहिए।

यह, फिर से, बहुत बहस का विषय है। एक व्यापक i18n समर्थन बहुत जटिल हो सकता है, और IMO Vue से संबंधित नहीं है, खासकर जब अधिकांश उपयोगकर्ताओं को इसकी आवश्यकता नहीं होगी।

अब, मैं इसे उठाना चाहूंगा: हर बार जब हम Vue और किसी अन्य टेम्पलेट/ढांचे के बीच तुलना करने का प्रयास करते हैं, तो एक महत्वपूर्ण बात ध्यान में रखनी चाहिए: Django/Laravel/Twig के विपरीत, Vue अनिवार्य रूप से एक क्लाइंट लाइब्रेरी है, और इस प्रकार जितना संभव हो उतना हल्का होना चाहिए। केवल तथाकथित "उपयोगिता" या "लालित्य" के लिए "सुविधाओं" और "बर्तनों" को जोड़ने के बजाय - पाठ्यक्रम की सभी _core_ विशेषताओं को बनाए रखते हुए - इसे काफी सरल रखने के लिए और अधिक समझदारी होगी। यदि आप मुख्य कार्यों के अलावा कुछ भी चाहते हैं, तो अधिक पसंदीदा तरीका एक प्लगइन का उपयोग करना या अपना खुद का विकास करना होगा। इसे एक उदाहरण के रूप में लें: आमतौर पर देखे जाने वाले एसपीए के लिए, क्या i18n/मुद्रा राउटर या राज्य प्रबंधक से अधिक महत्वपूर्ण है? मुझे ऐसा नहीं लगता। और फिर भी, Vue-राउटर और Vuex Vue में नहीं हैं, लेकिन उनके अपने रिपॉजिटरी हैं। दूसरे शब्दों में, Vue प्रगतिशील है ।

यदि आप मुझे दिखाते हैं कि ऐसा प्लग-इन कैसे बनाया जाता है, तो मैं आपके लिए i18n प्लग-इन भी करूंगा। मुझे इसमें पूरी दिलचस्पी है!

मेरा मानना ​​​​है कि यह एक अधिक समझदार दृष्टिकोण है, और आपकी रुचि के लिए धन्यवाद :)

अगर कुछ क्षेत्रों में i18n का उपयोग करने की बहुत आवश्यकता होगी)) मुझे लगता है कि मैं कोड में जा सकता हूं और सुंदरता के लिए कुछ चीजों के कुछ नामों को मैन्युअल रूप से बदल सकता हूं।
उदाहरण के लिए: कुछ घंटे पहले, यह मुझे ले गया butstrap.datepikker - मैं कनेक्ट नहीं करता, i18n इस तथ्य के बावजूद कि ऐसी संभावना है। त्वरित 60 सेकंड। "मैन्युअल रूप से" सप्ताह और महीनों के दिनों के नामों को बदल दिया, और सभी - ठीक है! ))

@phanan - आपका तर्क है कि मैंने "प्लगइन्स" का उल्लेख क्यों किया। मैं सहमत हूं, हर कोई मुद्रा या i18n कार्यक्षमता नहीं चाहेगा और जो अपने ऐप को हल्का नहीं रख सकते हैं, लेकिन एक टेम्प्लेटिंग सिस्टम के रूप में, मेरा मानना ​​है (और यह मेरी व्यक्तिगत राय है) Vue में ऐसी मानक कार्यक्षमता भी उपलब्ध होनी चाहिए बहुत। इससे भी महत्वपूर्ण बात, और मेरी चिंता यह है कि ऐसा नहीं होना चाहिए कि हर किसी को i18n या करेंसी फिल्टर कंपोनेंट व्हील्स को फिर से बनाना पड़े। दूसरे शब्दों में, जैसे Vue-Router और Vuex, Vue में उपलब्ध अतिरिक्त हैं, मुद्रा और i18n जैसे मानक फ़िल्टर की एक अच्छी संख्या भी हो सकती है।

ओह, और दिलचस्प रूप से पर्याप्त है, कोणीय में i18n बनाया गया है।

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

कोणीय दिनांक, संख्या और मुद्रा फ़िल्टर के लिए i18n/l10n का समर्थन करता है।

ऐसा लगता है कि एम्बर और रिएक्ट "देव दुनिया को इसे अपने दम पर करने दें" मार्ग पर चले गए हैं।
दिलचस्प वीडियो।
https://www.youtube.com/watch?v=Sla-DkvmIHY

हो सकता है कि Vue को केवल FormatJS में एकीकरण की आवश्यकता हो? व्यूइंटल? :मुस्कुराओ:

संपादित करें: यह इतना आसान नहीं हो सकता है, है ना? https://github.com/learningequality/vue-intl/blob/master/index.js

स्कॉट

ऐसा लगता है कि कोणीय में i18n बनाया गया है।

कोणीय भी एनजी-राउटर के साथ आता है, जो मैंने सुना है, एनजी-समुदाय द्वारा यूआई-राउटर के पक्ष में छोड़ दिया गया है।

अब, अगर एंगुलर टीम एनजी-राउटर को यूआई-राउटर से बदल देती है, तो इसके परिणामस्वरूप ब्रेकिंग परिवर्तन और दर्द होगा।

अगर वे एनजी-राउटर में सुधार करने की कोशिश करते हैं, तो वे अपना समय बर्बाद कर रहे हैं क्योंकि बेहतर समाधान (यूआई-राउटर) पहले से मौजूद है।

अगर Vue अपने मूल में i18n, करेंसी आदि को सपोर्ट करना शुरू कर देता है, तो Vue के साथ भी यही स्थिति होगी।

मुझे इन-बिल्ट फिल्टर सुविधाजनक लगता है, लेकिन इस मामले में मैं vuejs टीम से सहमत हूं।

फिर हम सभी सहमत हैं कि फ़िल्टर Vue core में नहीं हैं। मैं वास्तव में घटककरण का भी प्रशंसक हूं। लेकिन, क्या Vue फिल्टर को कोर प्लगइन्स के रूप में भी पेश नहीं कर सका? Vuex और Vue-Router की तरह?

स्कॉट

लेकिन, क्या Vue फिल्टर को कोर प्लगइन्स के रूप में भी पेश नहीं कर सका? Vuex और Vue-Router की तरह?

ठीक यही @ ब्लेक-न्यूमैन ने पहले साझा किया था।

नमस्ते: अंतिम निर्णय पृष्ठ ने संकेत दिया कि केवल पाठ के लिए फ़िल्टर की अनुमति है
प्रदर्शन {{}} (वी-पाठ)
अन्य अभिव्यक्तियों के लिए नहीं जैसे v-for="सूची का आइटम | सॉर्टबी"
या मैंने गलत समझा?
मेरा मतलब था कि 1.0 की तरह फिल्टर रखना, लेकिन केवल एक फिल्टर को सीमित करना
प्रति अभिव्यक्ति

सूर्य, 1 मई, 2016 को रात 10:24 बजे, फान एन नोटिफिकेशन @github.com ने लिखा:

@tomsmithgroup https://github.com/tomsmithgroup आपने क्या सुझाव दिया है
(और उससे अधिक) निर्णय लिया गया है
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 से
2.0 में समर्थित रहें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@ yyx990803 क्या मैं आपके उत्तर से यह निष्कर्ष निकाल

@fnlctrl यह सही है। बस अपने घटकों का निर्माण करें।

मैं थोड़ा हटकर विषय पर जाऊंगा: क्या वे दो-तरफा फिल्टर वास्तव में उत्पादन में उपयोगी हैं?
मेरा मतलब है, क्या उपयोगकर्ता को इनपुट में कुछ भी टाइप करने देना वास्तव में ठीक है, फिर इसे धुंधला होने के बाद इसे दोबारा सुधारना है?
मेरी व्यावसायिक टीम हमेशा इस तरह से कार्य करने के लिए हमारे इनपुट की मांग करती है: आप बस कुछ भी गलत नहीं लिख सकते। तो अब भी Vue के साथ हम उस उद्देश्य के लिए jquery.inputmask का उपयोग करते हैं क्योंकि तत्काल दो-तरफा परिवर्तन बहिष्कृत हो गया है (वह जिसे मैं वास्तव में याद करता हूं ...)
मेरा मतलब है, क्या वास्तव में उन दो-तरफा फिल्टर या लोगों के बारे में सोचने में कोई समस्या है? :)

@fullfs सुविधा के लिए हमारे प्रोडक्शन ऐप (बहुत सारे <input> s) में दो-तरफ़ा फ़िल्टर का व्यापक रूप से उपयोग किया जाता है, लेकिन जैसा कि मैं अब देख रहा हूँ, मानों को वास्तविक समय में फ़िल्टर करने के बजाय उन्हें केवल एक बार फ़िल्टर करने से पहले क्यों फ़िल्टर करें सर्वर पर पोस्ट-एड? कोड को दोबारा करने में कुछ समय लगेगा, लेकिन मुझे लगता है कि मैं उन्हें याद नहीं करूंगा: डी

यदि आप UI को आशावादी रूप से अपडेट करना चाहते हैं (जो आज IMHO का आदर्श है, विशेष रूप से मोबाइल के लिए), तो आप चाहते हैं कि इनपुट दिए जाने के समय व्यावहारिक रूप से इनपुट को ठीक से स्वरूपित किया जाए।

स्कॉट

vue में टू वे फिल्टर वास्तव में अच्छे हैं। आप हमेशा अपने स्वयं के अनुकूलित घटकों का निर्माण कर सकते हैं, फ़िल्टर के साथ या बिना उपलब्ध, लेकिन इसमें समय लगता है। पुस्तकालय को लचीलापन प्रदान करना चाहिए लेकिन चीजों को करने का एक तेज़ और सुविधाजनक तरीका भी प्रदान करना चाहिए। 2-वे फ़िल्टर शामिल करना लोगों को अपने स्वयं के घटकों के निर्माण से नहीं रोकेगा यदि उन्हें करना है, लेकिन जब मौजूदा कार्यक्षमता आवश्यकताओं को पूरा करती है, तो यह तेजी से विकास की अनुमति देगा, जो कि ज्यादातर समय होता है। यह हमेशा एपीआई सतह और सुविधा के बीच एक समझौता है। संतुलन खोजने की जरूरत है, और Vue के पास पहले से ही बहुत अच्छा है। ऐसा लगता है कि फ़िल्टर से छुटकारा संतुलन में सही बिंदु से एक कदम पीछे है। पुस्तकालय छोटा हो जाता है, लेकिन इसका उपयोग करने वाले प्रत्येक प्रोजेक्ट का कोडबेस और बॉयलरप्लेट बड़ा हो जाता है।

यदि फ़िल्टर को वास्तव में बहिष्कृत किया जाना है, तो एक आसान तरीके से पार्सर और वी-मॉडल निर्देशों के लिए एक फॉर्मेटर निर्दिष्ट करने में सक्षम विकल्प प्रदान करना अच्छा होगा। फ़िल्टर के साथ @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)
    }
  }
})

दोतरफा फिल्टर के बिना भी लिखना पड़ता है

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 वह चर्चा भी बंद है, हो सकता है कि हमें कस्टम वी-मॉडल संशोधक के लिए एक नया खोलना चाहिए।

अब ऐसा नहीं कर पाएंगे:

<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

फ़िल्टर को {{ }} तक सीमित करना अजीब लगता है, कई बार आप एक विशेषता बाइंडिंग में फ़िल्टर का उपयोग करना चाहते हैं (प्रॉप पास नहीं कर रहे हैं), और हम अब विशेषताओं में {{ }} का उपयोग नहीं कर सकते हैं !

उन्हें हटा दिया गया क्योंकि उन्हें आसानी से गणना की गई संपत्तियों और विधियों द्वारा प्रतिस्थापित किया जा सकता है, जबकि स्वयं के पास अधिक सीमित एपीआई होने के कारण कैशिंग परिणामों की कोई संभावना नहीं है।

इसलिए:

• एक एपीआई कम
• टेम्प्लेट और 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>

क्षमा करें, मैं केवल "नया" हूं।
लेकिन एंगुलर 1 से फिल्टर न होना वास्तव में अजीब और काउंटर सहज महसूस करता है, यह बेहतर क्यों होगा कि प्रत्येक डेवलपर अपने स्वयं के फिल्टर का सेट विकसित करे और गणना की गई प्रविष्टियों को स्वयं सेट करे आदि। इसे बनाने से बेहतर है?
और क्या अब तत्व में वस्तुओं द्वारा वास्तव में एक बड़ी सरणी को फ़िल्टर करने के लिए सबसे अच्छा अभ्यास माना जाता है। कोणीय के साथ यह कोड की केवल एक पंक्ति थी। एक खोज इनपुट के लिए एक सरणी को फ़िल्टर करना संभव था और यह सभी जादू करेगा, जो एक ढांचे का कार्य होना चाहिए।

और जिसे अब वास्तव में एक बड़े सरणी को फ़िल्टर करने के लिए सबसे अच्छा अभ्यास माना जाता है

वास्तव में एक बड़ी सरणी क्या है? सैद्धांतिक रूप से एक गणना की गई संपत्ति फ़िल्टरिंग के लिए भी अच्छा करेगी।

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

यह बेहतर क्यों होगा कि प्रत्येक डेवलपर फ़िल्टर का अपना सेट विकसित करे और गणना की गई प्रविष्टियों को स्वयं सेट करे आदि। इसे बनाने से बेहतर?

मैं उसी तरह सोचता था (और मैंने धागा क्यों शुरू किया), लेकिन जब से मैंने सीखा है कि यह मूल रूप से इस प्रकार के फ़िल्टर बनाने के लिए केक का एक टुकड़ा है, और यह कि बहुत सी चीजें हैं प्रत्येक डेवलपर चाहता है एक फिल्टर (या गणना की गई संपत्ति) के रूप में, मुझे एहसास हुआ है कि यह सब इतना बड़ा सौदा नहीं है कि फिल्टर में नहीं बनाया गया है।

स्कॉट

मेरे मामले में यह एक फायरबेस डेटाबेस द्वारा प्रदान किए गए जेसन में> 10.000 लाइनों के बराबर है।
मैं देखता हूं कि आप ऐसा क्यों सोच सकते हैं, और इस सुविधा को छोड़ने का फैसला कर सकते हैं, फिर भी यह देवों के लिए काफी अतिरिक्त परेशानी है।

मैंने अपनी डेटा संरचना के साथ बेला को इन-लाइन करने के लिए फोर्क किया:
https://jsfiddle.net/nw5yhLwv/
तो मुझे अपने ऑब्जेक्ट में खोज को एक स्ट्रिंग को हाथ से कोड करने की ज़रूरत है?

मैं आपका प्रश्न नहीं समझता। माफ़ करना। बेला जैसा मैंने पोस्ट किया है वैसा ही दिखता है।

स्कॉट

परिकलित बनाम फ़िल्टर

फ़िल्टर संभवतः प्रदर्शन के लिए खराब होते हैं, क्योंकि उनकी गणना प्रत्येक रेंडर (विधियों की तरह) के लिए की जाती है और गणना किए गए गुण केक के रूप में आसान होते हैं, और केवल आवश्यक होने पर ही पुनर्गणना की जाती है, अन्यथा परिणाम कैश किए जाते हैं, जिसका अर्थ है कि Vue उड़ सकता है।

ओह। और हमारे पास दोनों हैं। मैं

स्कॉट

अरे, मैंने कुछ फिडलिंग की और अब मैं समझ गया, यह एक बेहतरीन कॉन्सेप्ट है! मैं

मैं इस धागे को अब बंद कर दूंगा, क्योंकि इसके बारे में चर्चा लंबे समय से समाप्त हो गई है - Vue 2.0 कुछ महीनों के लिए बाहर हो गया है, और फिल्टर की गिरावट के बारे में आलोचना काफी हद तक कम हो गई है।

इस सूत्र में आगे की चर्चा उत्पादक नहीं है। यदि आपको लगता है कि जिस विषय पर चर्चा करने की आवश्यकता है, यदि आप उस विषय के लिए एक नया कोण देखते हैं, तो कृपया एक नया मुद्दा खोलें।