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 ، أذهلتني جميع الاحتمالات الجديدة (خاصة دوم الظاهري وعرض الخادم) ، لكنني فوجئت أيضًا وأحزنني بعض الشيء أن المرشحات اختفت.

لقد كانت واحدة من الأجزاء المفضلة لدي من vue ، ليس فقط لأنها كانت سهلة الاستخدام وقابلة للتسلسل ، ولكن بشكل أساسي لأنها كانت قابلة للتوسيع بسهولة ولديها بناء جملة جميل لاستخدامها في القالب مباشرة. لقد كانت الحلقات متطابقة تمامًا خاصةً مع الحلقات v-for .

أعتقد أنه سيتعين علي استخدام الخصائص المحسوبة لاستبدال التصفية لكل عنصر أريده ، فأنا قلق من أنني سأكتب الكثير من النماذج المعيارية في المستقبل. بينما قد تخفف الخلطات جزءًا من المشكلة ، ما زلت أشعر بأن جزءًا من الأناقة وسهولة استخدام vue سيكون مفقودًا.

كل من يوافق على ذلك ، هل يمكنك فقط النقر فوق علامة الإعجاب تحت الوصف؟ إنه أفضل من إرسال رسائل غير مرغوب فيها إلى 17 ألف شخص بـ +1 . والأفضل من ذلك ، ابتكار بعض حالات الاستخدام المفيدة.

لم أستخدم الفلاتر ثنائية الاتجاه مطلقًا ، لكنني سأفتقد المرشحات حقًا! يمكنني (وأحيانًا أفعل) استخدام الخصائص المحسوبة ، لكن في بعض الحالات البسيطة ، تكون الراحة تسرّع سير العمل حقًا.

ضع في اعتبارك هذا المثال البسيط للغاية

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

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

ما ورد أعلاه أسهل في الكتابة في الحالات التي لا يلزم فيها إجراء تصفية أكثر تعقيدًا.

الآن قارنها بما يلي

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

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

new Vue({
    el: 'body',

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

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

أنا لا أقول أن الثانية صعبة الكتابة ، ولكن عندما تستخدمها في العديد من الأماكن ، ستبدأ في تكرار نفسك ، وسيستغرق الأمر بعض الوقت الإضافي الذي ربما يمكنك استخدامه في بعض الميزات الأخرى الأكثر فائدة!

في كلتا الحالتين ، سأبقى مستخدم Vue سعيدًا ، ما عليك سوى مشاركة رأيي حول المرشحات التي تم إهمالها!

المرشحات قابلة لإعادة الاستخدام. يمكنني إنشاء وظيفة لتنسيق بياناتي مرة واحدة ، وتسجيلها كعامل تصفية والاستخدام فقط من جميع الحالات. كيف يمكنني القيام بذلك في 2.0؟

كيف يمكنني القيام بذلك في 2.0؟

• ميكسين
• وحدة منفصلة مع الطريقة
• وحدة منفصلة مع وظيفة الدعامة المحسوبة

لقد تركت للتو تعليقًا على سلسلة الإعلان ، لذا بدلاً من تكرار كل ذلك هنا ، سأقوم ببساطة بالربط به:

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

أنا أتفهم تمامًا الشعور بأن شيئًا مريحًا للغاية يتم انتزاعه منك. لكن أولاً ، يرجى تخصيص بعض الوقت لقراءة تعليق chrisvfritz في موضوع المنتدى أعلاه. لتسهيل المناقشة ، ما عليك سوى نسخها ولصقها هنا:

theotherzach شكرًا على شغفك بـ Vue! أود أن أشرح هذا الإهمال بشكل أفضل قليلاً ، لكن أولاً ، يجب أن أقدم نفسي. أنا عضو في فريق Vue الأساسي ، وأنا أستخدم Vue طوال الوقت لعملي لواجهة المستخدم المستقلة وتصور البيانات ، وأنا أيضًا مدرس يعلم الناس استخدام Vue و Rails ، من بين تقنيات الويب الأخرى. أدير مدرسة تعليمات برمجية ، لذا أساعد الناس على تعلم استخدام هذه الأدوات (واستخدامها معًا) تقريبًا _ كل يوم_.

كنت أيضًا أحد المؤيدين الكبار لإزالة المرشحات في Vue 2.0.

مشكلة المرشحات للمبتدئين في Vue

جزء كبير من السبب الذي جعلني أؤيد إهمال الفلاتر كان في الواقع _ للمبتدئين. عند العمل مع الطلاب ، هذه محادثة ظهرت أكثر من مرة:

• الطالب: "هل الفلتر هو في الأساس وظيفة؟"
• مينتور: "نعم!"
• الطالب: "حسنًا ، هل يمكنني استخدامه بشكل طبيعي مع أقواس الوظيفة؟"
• مينتور: "حسنًا ، لا. إنه نوع خاص من الوظائف."
• الطالب: "هل يمكنني استخدامه في أماكن أخرى؟ مثل القيمة المحسوبة؟"
• مينتور: "لا ، لا يمكنك استخدامه إلا في النماذج وفقط مع تركيب الأنبوب الخاص."
• الطالب: "... لماذا؟"

من الأشياء الكبيرة التي تثير اهتمام المبتدئين _ الاستثناءات_. المرشحات ما هي إلا وظائف ، _ استثناء_ فهي تتطلب بنية خاصة ولا يمكن استخدامها في كل مكان. ويستخدمون تركيبًا للأنبوب يختلف عن تركيب الأنبوب الذي قد يتم دمجه في ES7 ، مما يعني أنه لن يمر وقت طويل حتى يكون لدى الأشخاص عاملين متشابهين جدًا للقيام بشيء مشابه جدًا ، لكنهم ليسوا متشابهين تمامًا. وواحد منهم فقط هو في الواقع JavaScript.

Util libraries _are_ مفيدة ، لكن Vue ليست واحدة

في حالة filterBy ، تحويلات السلاسل والأرقام ، وعوامل تصفية أخرى محددة ، نعم ، فهي مفيدة في التطبيقات التي تظهر فيها. مكتبات Util بشكل عام مفيدة. وهناك العشرات من مكتبات الاستخدام الرائعة للاختيار من بينها ، لكن Vue ليست مكتبة أدوات مساعدة. وبصراحة ، لم تكن أي من المرافق التي قدمناها هي الأفضل في فئتها.

التعامل مع العملات أو التواريخ أو حتى تصفية المصفوفات - هذه ليست محور تركيزنا. لا تتطلب العديد من التطبيقات هذه التطبيقات ، كما أن معظم التطبيقات التي عملت عليها _تواجه هذه المشكلات _ تتطلب حلاً أكثر قوة مما تقدمه Vue حاليًا (أو _يمكن _ تقديمه دون إدخال سخام كبير وتجديد عجلة).

في تطبيقاتي ، تعاملت Accounting.js مع العملة بطريقة رائعة ، وتعالج Moment.js (كما ذكرت) التواريخ والأوقات ، ولا يتعامل pluralize مع العديد من عمليات الجمع بشكل جيد ، لذلك غالبًا ما تكون القيمة المحسوبة المخصصة مرغوبة أكثر ، و json أكثر بقليل من JSON.stringify .

مزايا الخصائص المحسوبة

يوفر استخدام الخصائص المحسوبة بدلاً من المرشحات أيضًا ميزة أن القيمة المعالجة يمكن إعادة استخدامها بسهولة بطريقة DRY _ في أي مكان_ في المكون. أجد نفسي مضطرًا للقيام بذلك في تطبيقاتي طوال الوقت. تنقل الخاصية المحسوبة أيضًا المزيد من تفاصيل التنفيذ خارج القالب ، تاركة فقط وصفًا نظيفًا لما يفعله المكون. والميزة التي تتفوق على المرشحات المحددة عالميًا هي أن المرء يحتاج فقط إلى إلقاء نظرة على الوظيفة لقيمة هذا الكمبيوتر لمعرفة كيفية عمله وتعديله بالضبط. في المصفوفات ، يوفر تسلسل طرق JavaScript map و filter نفس قائمة المعالجة الخطية التي تقوم بها الأنابيب ، ولكن بطريقة أكثر وضوحًا ويمكن التلاعب بها بسهولة.

فائدة أي شيء محدد عالميا

إذا كنت بحاجة إلى تحديد وظيفة أو أي شيء آخر تريد الوصول إليه في جميع مكوناتك ، فإن Vue.prototype.whateverIWant = mySuperCoolFunction طريقة رائعة للقيام بذلك. أنا شخصياً لم أرغب قط في القيام بذلك. لقد فضلت دائمًا وضع طريقة مساعدة في وحدة نمطية واستيراد تلك الوحدة حيث أحتاج إليها. ولكن لا يزال من المهم ملاحظة أن تسجيل الكرة الأرضية - من أي نوع - ليس بالأمر الصعب.

حالة الأمر debounce

يجب أن أقول ، أنا معك بالفعل في هذا الأمر! لقد نظرت مؤخرًا في جميع مشاريع Vue الخاصة بي وكل مشروع يحتوي على input مكان ما يستخدم أيضًا debounce . في الواقع ، لم يستخدم أحد تطبيقاتي السابقة سوى debounce. في حين أن الأداة المساعدة من الناحية الفنية - لوداش والعديد من المشاريع القوية الأخرى تقدم حلولًا للخطأ - فإن هذه المشكلة عالمية جدًا لتطوير واجهة المستخدم ، لأي نوع من التطبيقات. إن كتابة وظيفة debounce الخاصة بك هي أيضًا غير تافهة بما يكفي لدرجة أنني ربما أرغب في استخدام تنفيذ لوداش لكل مشروع تقريبًا.

لا يزال هناك بعض الجدل الداخلي حول هذا ، لذلك سنرى إلى أين يذهب. لكن نعم ، بالنسبة لي شخصيًا ويبدو أيضًا أن إزالة debounce يزيل معظم الراحة التي يوفرها v-model .

مرة أخرى ، شكرا على شغفك!

على محمل الجد ، نحن نحب مدى حبك لـ Vue ويسعدنا حقًا أنك تعبر عن مخاوفك - وخاصةً بطريقة لطيفة ومحترمة! نحن نسمعك. يتكون الفريق الأساسي من جميع المصممين ومطوري الواجهة الأمامية والمتخصصين في تصور البيانات. نستخدم جميعًا Vue في عملنا الخاص ، وهو متنوع للغاية ، لذلك نحن ملتزمون بالتأكيد بالتخلص من طعام الكلاب ونريد أن نأكل أنفسنا. :-)

الكلام رخيص ، دعنا نبرمج لمعرفة ما إذا كان بدون مرشح ، كيف نطبق filterBy والعكس:

كتابة وظائف مرشح نقي عالمي في ملف منفصل لإعادة استخدام الكود

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

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

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

export {filterBy, reverse, findBy}

استخدام عوامل التصفية في نموذج App.vue

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

    <hr />

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

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

</template>

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

شاهد النتيجة هنا http://raywill.github.io/vuefilter/

إذا تم استخدام الفلتر ، فإن كود vue التالي سيفعل الشيء نفسه:

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

    <hr />

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

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

</template>

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

على ما يبدو ، مع دعم الفلتر ، يمكننا كتابة كود أقل تافهة.
أنا شخصياً أفضل طريقة vue 1.0 ، مما يجعل البرمجة أكثر متعة.

أما بالنسبة للمخاوف المعيارية - فهناك عدة طرق للتعامل معها.

1. صراحة الاستيراد / التصدير

مثل raywill الموضح أعلاه. إنها مطولة أكثر قليلاً ، لكن الفوائد هي:

1. لا يتعين عليك البحث عن وثائق عامل التصفية الخاص بـ Vue لفهم كيفية عملها. إنه واضح للغاية من أين تأتي الوظائف وكيف يتم تنفيذها.
2. الوظائف نفسها هي مجرد JavaScript. يمكنك تعديلها / تكوينها لتناسب حالات الاستخدامات الخاصة على عكس المرشحات المدمجة التي لا يمكنك لمسها.
3. يمكنك استيراد هذه الوظائف وإعادة استخدامها برمجيًا في الأساليب والخصائص المحسوبة وفي أي مكان تكتب فيه JavaScript.

2. قم بإرفاقهم بـ Vue.prototype

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

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

3. كن فعالاً (للمستخدمين المتقدمين)

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

حيث تبدو وظائف المساعد مثل:

// a function that returns a predicate function for array.filter()
function contains (value) {
  return thing => thing.indexOf(value) > -1
}

function by (getValue) {
  return (a, b) => {
    return getValue(a) > getValue(b) ? 1 : -1
  }
}

مرة أخرى ، من الاعتبارات المهمة جدًا في التصميم أن المرشحات المدمجة يمكن أن تكون مفيدة ، لكنها تفتقر إلى مرونة جافا سكريبت الخالصة . عندما لا تناسب الوظيفة المضمنة احتياجاتك ، ينتهي بك الأمر إلى إعادة تنفيذ شيء مشابه (وشحن كليهما في الكود النهائي ، حيث يصبح الرمز المدمج عديم الفائدة ، أو رمز ميت) ، أو تضطر إلى انتظار 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 / المتعاونون يناقشون خيارًا لتوفير حزمة أدوات مساعدة للفلاتر المدمجة الحالية. هناك الكثير من الموارد التي ستزودك بأدوات مساعدة لقاعدة الشفرة الخاصة بك.

أحد الأشياء الجيدة في إزالة المرشحات الأساسية ، هو أنه يمكنك الآن تخصيصها / تنفيذها بنفسك. مما يمنحك المزيد من المرونة.

يجب أن تكون تعبيرات القالب @ rigor789 بسيطة قدر الإمكان. من الناحية المثالية تمامًا مثل <div v-for="filteredData"> </div> . يمكن أن تكون هذه خاصية محسوبة ، يمكنها الاحتفاظ بالمنطق لإنشاء البيانات التي تمت تصفيتها. هذه طريقة أسهل للقراءة ، وهي أفضل من شيء مثل:

<div v-for="item in filters.orderBy(filters.filterBy(words, userInput), column, -1)"> </div>
أو
div v-for="item in data | filterBy | orderBy " إلخ

يمكن إعادة استخدامها كخاصية محسوبة بشكل أكبر ، ويمكن حتى تمريرها إلى المكونات الفرعية. ماذا لو أردت استخدام البيانات التي تمت تصفيتها في مكانين؟ من الأسهل والأبسط والموثوقية والأكثر قابلية للقراءة بالنسبة للقوالب أن تحتوي على تعبيرات بسيطة ، مقارنةً بوجود عوامل تصفية متسلسلة في التعبيرات.

لأي شخص يتابع ذلك ، أجبت على chrisvfritz هنا: http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

يحل ما يلي حالة الاستخدام الخاصة بي لعدد قليل من وظائف مساعد العرض الخالص المتاحة عالميًا. أنا أسحب مخاوف إزالة عامل التصفية. حرقهم! 🔥 تهانينا لـ chrisvfritz و @ yyx990803 لتغيير ملكي ) على الإنترنت!

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

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

أتفق تمامًا مع @ yyx990803 ، قم بإزالة المرشحات والتزم بوظائف JS العادية.

@ blake-newman هذه نقطة جيدة جدًا ، أنا مقتنع في الغالب في هذه المرحلة ، وأفكر في سهولة القراءة ، أعتقد أنه يمكن تحقيق شيء مثل هذا

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

هنا هو jsfiddle سريع للمفهوم

أحد الأشياء الجيدة في إزالة المرشحات الأساسية ، هو أنه يمكنك الآن تخصيصها / تنفيذها بنفسك. مما يمنحك المزيد من المرونة.

كنت دائمًا قادرًا على تخصيصها / تنفيذها بنفسك.

Vue ليست مكتبة أدوات مساعدة. وبصراحة ، لم تكن أي من المرافق التي قدمناها هي الأفضل في فئتها.

ما يهمنا هو إزالة وظيفة التصفية في القوالب. إن إزالة المرشحات المدمجة أمر منطقي للغاية - يمكن إعادة إنشائها بسهولة عن طريق إنشاء وكيل لها لتسطير أسفل السطر / مكتبات استخدام أخرى. بعد ذلك ، يمكن لشخص ما إصدار مكون إضافي واحد يعيد إنشاء جميع المرشحات المضمنة الحالية.

يوفر استخدام الخصائص المحسوبة بدلاً من المرشحات أيضًا ميزة أن القيمة المعالجة يمكن إعادة استخدامها بسهولة بطريقة جافة في أي مكان في المكون.

بالطبع يمكنك استخدام الخصائص المحسوبة إذا كان عليك إعادة استخدامها في مكان آخر. ولكن إذا لم تقم بذلك ، فسيظل المرشح أكثر ملاءمة.

هناك بعض النقاط الأخرى التي نشرتها في هذا الرابط الذي شاركته أعلاه.

لماذا لا تدعم صيغة المرشحات التي تعمل مثل بناء جملة ES7 المقترح؟ سيسمح ذلك للناس بالاستمرار في استخدام مرشحاتهم المحببة ، وجعلها تتماشى مع ما قد يحمله المستقبل. في النهاية عندما يكون لدينا أنابيب ES7 ، يمكنك تبديل التنفيذ الداخلي دون تغيير واجهة برمجة التطبيقات.

هل أنابيب ES7 معتمدة أم أنها تخضع للكثير من التغييرات؟

إنه من الناحية النظرية عرضة للتغيير ، لكن يبدو أنه ... مستقر؟
الحالة: mindeavor / es-pipeline-worker # 33

JosephSilber @ الشباب-steveothelinuxlich أعتقد أننا على نفس الصفحة حول قيمة الأنابيب بشكل عام. 😃 تتمثل إحدى ميزات المترجم الجديد في الإصدار 2.0 في أنه يمكننا توجيه رمز دالة التصيير الذي تم إنشاؤه عبر Babel. لا يزال هذا بحاجة إلى مزيد من الاستكشاف ، ولكن ليس من المستبعد أنه بمجرد أن يكتسب |> مزيدًا من الزخم ويتم تطوير مكون Babel الإضافي الخاص به ، يمكنك بسعادة ربط الطرق مع الأنابيب مرة أخرى - في كل مكان_ في تطبيقك. بصفتي معجبًا كبيرًا بـ LiveScript واللغات الوظيفية الأخرى ، فأنا بالتأكيد أدرك القيمة !

مشغل خط الأنابيب هذا ليس حتى في المرحلة 0

thelinuxlich نعم ، أعتقد أنهم ما زالوا ينتظرون بطلًا في TC39. 😞

@ Rigor789 هذا أحد البدائل التي أردت ذكرها أيضًا! تسمح لك قوة JavaScript بتحقيق التعبير عن اختيارك ، و imo أفضل من وضع منطق التصفية داخل القوالب.

@ 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 قال للتو ، إنه يشجع على تحسين JavaScript والتفكير المنطقي. نحن لا نقدم المنطق في Laravel's Blade أو أي طبقة عرض لإطار عمل آخر ، ولا ينبغي لنا في قوالب Vue.

ومع ذلك ، JosephSilber إذا نظرت إلى الزاوية الأخرى ، ستجدني هناك.

بالنسبة لي ، تبدو المرشحات جميلة جدًا ، فالصيغة هي بالضبط ما يجب أن تبدو عليه صيغة المرشح.

أحد الأشياء الجذابة في Vue بالنسبة لي هو أنه يأتي مع (بعض) البطاريات المضمنة. سيكون من المحزن حقًا أن تفقد أيًا من هذين الأمرين - وكلاهما ، في رأيي ، يجعل Vue تبرز.

عند القراءة من خلال سلسلة الرسائل ، يبدو أن أكثر ما يثير القلق بشأن المرشحات هو حقيقة أن Vue لديها مرشحات افتراضية ، وليست الوظيفة نفسها (أم أنها كذلك؟ ما زلت غير متأكد).

أحب التفكير في المكون الإضافي للمرشح من @ blake-newman ويجب أن تكون هناك أمثلة مسبقة الصنع. إذا توصل أشخاص آخرون إلى فلاتر أخرى ، فيجب توصيلهم وتشغيلهم. هذا سيكون رائع. أوافق تمامًا على أن إنشاء المرشحات هو مسؤولية Userland.

ما لا يزال مطلوبًا هو قدرات الأنابيب والتسلسل وعالمية ميزة المرشح الأصلية. تمت تغطية المخاوف بشأن العولمة من خلال @ yyx990803. ماذا عن التسلسل بالأنبوب؟ يساعد كثيرًا في قراءة القوالب وفهم ما يمكن توقعه كمخرجات. تمت مناقشة الأنبوب والسلاسل أعلاه. هل لا يزال من الممكن القيام به؟ لماذا هو أمر سيء على الإطلاق؟ بالنسبة للمصمم ، إنه ذهب! المرشح هو أداة المصمم ، وليس مبرمج JS. لذا ، فإن حجة كتابة JS بشكل أفضل تقع خارج السبورة ، في كتابي ، لكن يمكنني أن أفهم سبب رغبتها في ذلك. لكن ، كمصمم ، أريد كتابة كود أفضل أيضًا ، وتسمح لي المرشحات بذلك ، بشكل جميل. :ابتسامة:

سكوت

إليك الشيء المتعلق بالتسلسل - تُستخدم المرشحات بشكل أساسي لغرضين:

1. تنسيق النص
2. معالجة مجموعة.

في حالة تنسيق النص ، يتم استخدام طريقة أداة واحدة فقط بنسبة 90٪ أو أكثر من الوقت. التسلسل ليس مشكلة كبيرة في هذه الحالة.

بالنسبة للمصفوفات: لقد أشرت بالفعل إلى أن معالجة المصفوفات هي في الواقع منطقية وهي مناسبة بشكل أفضل في JavaScript. قد يبدو وجود عدة مرشحات مصفوفة متسلسلة جيدًا عندما يكون الأمر بسيطًا ، ولكن يمكن أن يصبح قبيحًا عند استخدام أكثر من وسيطة لكل منها. إنه يشجعك أيضًا على وضع الكثير من المنطق في القالب الخاص بك عندما لا يجب عليك ذلك. كما أنها غير مرنة (لا يمكنها بسهولة استعادة القيمة المعالجة). بالمقارنة مع ES2015 المثال الأصلي

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

يمكن كتابتها على النحو التالي:

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

إنها مجرد JavaScript ، ليس لديها سحر ، ولا توجد بنية بديلة وواجهة برمجة تطبيقات خاصة بالفلتر لتتعلمها. ويمكنك الوصول إلى القيمة المعالجة (المخزنة مؤقتًا بذكاء). أنت أيضًا حر في إضافة السكر فوق هذا كما هو موضح في التعليقات السابقة. بالإضافة إلى ذلك ، يبدو نموذجك أنظف:

<div v-for="filteredThings">

أعلم أن هذا مثل شيء مفيد يتم نقله بعيدًا ، ولكن بصراحة ، تبدو الحجج الخاصة بالفلاتر الآن بالنسبة لي وكأنها مجرد محاولة للحفاظ على بناء الجملة من أجل بناء الجملة. في رأيي ، يتطلب الأمر أكثر من مجرد "لأنها أنيقة" لتبرير ميزة - فهي تحتاج إلى توفير قيمة موضوعية. كان هذا هو الحال بالنسبة إلى inline-templates ، لكنني لا أرى ذلك للفلاتر.

@ yyx990803 - أعتقد أن مثالك يوضح المشكلة. مرة أخرى ، أنا لست أفضل مبرمج JS ، لكنني لست بحاجة إلى أن أكون مبرمج JS لأعرف filteredThings لا يقول شيئًا عما يفعله حقًا. بالنسبة لي ، هذه ممارسة سيئة. : ابتسامة: حقيقة أن طريقة التصفية عالمية تعني أيضًا أنني يجب أن أذهب للبحث في المستندات أو الشفرة أو فك تشفير المخرجات لمعرفة ما تفعله الطريقة. ليست أنيقة حقًا. حق؟

جيد. يمكن أن يكون لدينا اسم طريقة مثل "filterByOrderByAndLimit". ماذا عن الحجج؟

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

هل هذا يكون صحيحا؟

إذا كان الأمر كذلك ، فقد يكون ذلك ممكنًا. ومع ذلك ، لا تبدو جيدة.

والآن أريد فقط التصفية حسب والنظام OrderBy. هل أحتاج إلى طريقة منفصلة للقيام بذلك أيضًا؟ وبعد ذلك أريد إضافة تنسيق العملة. طريقة اخرى؟ تسلسل عوامل التصفية في القوالب يجعل معالجة العرض التقديمي مرنًا ومعبّرًا للغاية. لم يتم التعامل مع هذا القلق بشكل صحيح من خلال الأساليب (وافتقاري للمعرفة لا يسمح لي بفهم الأساليب التي يمكن أن تكون أفضل).

هل هذا ممكن؟

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

أوافق على أن القيام بالكثير من المنطق في قالب أمر يجب تجنبه. لكن ، تسلسل الفلتر والقدرة على إدخال مرشح في أي مكان في مكونات / قوالب التطبيق مفهوم رائع وكان هناك سبب لإضافته في البداية. ما هو هذا السبب أو الأسباب؟ إذا كان بإمكانك تسميتها ، فسأراهن بالمال الذي يفوقونه "لكنه يروج للممارسات السيئة" بمقدار ميل واحد.

يمكن استخدام أي شيء يسمح بالمرونة بشكل غير صحيح ، تمامًا مثل Vue نفسه. كانت الحجة الرئيسية لـ inline-template أنها مرنة وسمحت باستخدام Vue بطرق مختلفة. لا تختلف الفلاتر كثيرًا ، بخلاف أنها Vue داخلية ولا تؤثر على كيفية استخدام Vue خارجيًا. ومع ذلك ، هذا لا يقلل من أهميتها. تذكر أن الكثير من الأشخاص قالوا أيضًا إن هذا سيكون أمرًا محظورًا بالنسبة لهم للترقية. هذا مهم! :ابتسامة:

الطريقة الجديدة تحتاج فقط إلى نفس السمات التي كانت تتمتع بها الطريقة القديمة.

• قابل للسلاسل
• عالمي
• أضف إلى القوالب للتعبير بشكل جيد عن كيفية معالجة البيانات الموجودة في القوالب

(هل نسيت أي شيء؟)

إذا كان بإمكانه فعل كل ذلك ، فأنا متأكد من أن الجميع سيكونون راضين إلى حد كبير. أنا شخصياً لا أستطيع أن أرى ذلك يحدث بالطرق (حتى الآن).

سكوت

تضمين التغريدة

1. لقد ذكرت بوضوح أنه يجب عليك تقليل المنطق في القوالب الخاصة بك. هذا رأيي سواء أعجبك ذلك أم لا. من الواضح أنك حر في عدم الموافقة ، لكن لا يمكنني مساعدتك إذا كنت تريد العمل ضد أفضل الممارسات الموصى بها.
2. بالنظر إلى (1) - لقد أوضحت لماذا التسلسل ليس مشكلة لأنه يجب أن يتم المنطق المعقد في JavaScript.
3. لقد قدمت أيضًا أمثلة على كيفية إضافة الطرق المتاحة عالميًا.
4. رؤية @ rigor789 الصورة مثال على تركيب مخصص تسلسل مماثل إلى ما تريد.
5. الهدف من إطار العمل هو تقديم ما أعتقد أنه أفضل طريقة لتطوير تطبيقات الواجهة الأمامية ، وليس لإرضاء الجميع. لذا من فضلك لا تستخدم "لن أقوم بالترقية إذا لم تعيد هذه الميزة" - فهي لا تعمل.

لماذا لا تجربون إصدار ألفا الجديد هذا لمدة أسبوع ثم تأتيون ببعض التعليقات القيمة حقًا (بناءً على ممارستكم)؟ ربما تحاول إعادة هيكلة تطبيقك الحالي وإخبارنا بما هو مستحيل ، وما الذي تم تحسينه ، وما الذي ساء ، حتى نتمكن من مناقشته بشكل أفضل. سيكون ذلك مفيدًا للجميع على ما أعتقد.

@ yyx990803 - وافقت على 1. لذلك نحن نتفق. : ابتسم: أنا فقط لا أوافق على أنه سبب مناسب لإخراج شيء نال الكثير من الحب.

لذا ، أعتقد أنك قررت بمرور الوقت أن JS البراغماتية أفضل من HTML الواقعي؟

حجة عدم الذهاب لعدم الترقية هي ما قاله الآخرون. أنا فقط أحاول التواصل والتخفيف من ذلك.

حجة أخيرة من نفسي. انظر إلى هذا من وجهة نظر المستخدم. لنفترض أن لدي نظامًا مثل Laravel أو نظام MVC أو MVVM آخر يشتمل على Vue ، والذي يسمح أيضًا لمستخدم هذا النظام ببناء مكوناته الخاصة. يعمل المرشح ، كما كان ، على تبسيط منحنى التعلم ويسمح لمستخدمي هذا النظام بإنجاز الكثير ، دون لمس أي JS. أنا معجب بـ Vue ، لأنه أتاح للمبرمجين غير التابعين لـ JS الاستمرار في إنجاز الكثير. هذا هو نفس السبب الذي يجعلني لا أحب React و JSX. سيكون لهذه المجموعة قاعدة مستخدمين أصغر بكثير على Vue مع مرور الوقت. سأراهن بالمال عليها.

أفهم أيضًا أن المرونة الحقيقية تكمن في JS. ومع ذلك ، يُرجى عدم الاعتماد فقط على JS للحصول على المرونة في Vue. ضع في اعتبارك ، ليس كل شخص مبرمج JS قاتل. في الواقع ، معظم الناس ليسوا كذلك. كان المرشح طريقة رائعة لإنجاز الكثير لهؤلاء الأشخاص وكان خطوة لطيفة نحو مزيد من التلاعب في JS. المرشحات لا تستطيع إنجازها؟ تعمق في طرق JS.

موافق. كفى مني ..... انتهيت. وشكرًا على الاستماع بأي معدل. لا يزال Vue رائعًا! :ابتسامة:

@ azamat-sharapov - نقطة جيدة.

سكوت

إن رؤية أشخاص يحاولون تبرير الممارسات السيئة داخل JS تجعلني حزينًا. حقًا ، لست بحاجة إلى أن تكون محترفًا ، فقط قم بالواجب المنزلي الأساسي (أو لم يعد أساسيًا هذه الأيام؟)

المشكلة التي أواجهها مع أساليب المرشحات الداخلية هي مشكلة الدلالات.

في مصطلح عفوًا ، تكون المرشحات مثل الوظائف الثابتة بينما الطرق هي وظيفة غير ثابتة.

تنقل المرشحات دلالات مختلفة تمامًا عن الطرق. يتمثل الاختلاف الأكبر في أن المرشحات لا يمكنها استخدام this ، لكن الأساليب يمكنها ذلك.

@ yyx990803 أثناء استخدام Vue.prototype.filters يمكن أن يعمل ولكن تغيير Vue لا يبدو ممارسة جيدة بالنسبة لي. أفضل أن أؤيد إنشاء كائن منفصل (عالمي) يحتوي على جميع المرشحات.

لا يبدو أنها ممارسة جيدة لأن الكرة الأرضية ليست ممارسة جيدة. الأسلوب الموصى به هو استيراد الطرق المساعدة بشكل صريح. يعد إرفاق النموذج الأولي حلاً بديلاً لأولئك الذين لا يرغبون في استيراد الأساليب بشكل صريح.

أما بالنسبة للدلالات - فالمرشحات هي مفهوم مصاغ على أي حال. في JavaScript ، لن تخترع دلالات مختلفة فقط لأحرف سلسلة كبيرة - فأنت تستدعي دالة. وهذا ما هي عليه وظائف JavaScript.

سأدلي بتعليق آخر لمحاولة توضيح وجهة نظري الشخصية ، ويرجع ذلك أساسًا إلى التعليق "محاولة تبرير الممارسات السيئة داخل JS". أنا بالتأكيد لا أحاول القيام بذلك.

أدرك أن Vue هو أكثر من مجرد نظام قوالب ، ولكنه نظام قوالب أيضًا وأخشى أنه يحاول الابتعاد عن هذا الدور ، وهو ما أشعر أنه لا ينبغي. لذا ، كمحرك / نظام قالب ، خذ محرك قالب Twig كمثال ناجح للغاية لما يمكن أن يتوقعه المرء من نظام القوالب. لديهم قسم " لمصممي النماذج " وقسم " للمطورين " في مستنداتهم. كنظام قوالب ، يعد Twig قويًا لمصمم النماذج أيضًا ، لأنه مليء بالسلوكيات الافتراضية ، بما في ذلك المرشحات . يسمح لغير المطورين بعمل الكثير باستخدام نظام القوالب ، دون معرفة PHP مباشرة. عليهم فقط معرفة ما يقدمه Twig وكيفية استخدامه. أنا أبحث عن هذا في Vue أيضًا. أود أن أرى قسم "Vue لمصممي النماذج" في المستندات أيضًا. :ابتسامة:

أيضًا ، من المهم جدًا قابلية تمدد Twig. إذا كان هناك شيء غير متوفر في إصدار المخزون ، فيمكن إضافته. هذا عندما يتدخل المطور. الشيء الجميل أيضًا ، أنه يمكن مشاركة الإضافات ، مما يعني أنه يجب القيام بذلك مرة واحدة فقط.

الشيء الآخر اللطيف حول مصمم / مطور هذين المستويين هو أنك تحصل على قاعدة أوسع بكثير من المستخدمين. أوسع بكثير وهذا هو نفسه مع. وعندما لا تكون القيم الافتراضية للسلوك كافية ، فهذا عندما يبدأون في تعلم اللغة الأساسية عن طيب خاطر. وذلك عندما يتعلمون أفضل الممارسات والباقي.

إذا كنت تقول ، لا يمكن أن يكون Vue محركًا نموذجيًا دون الحاجة إلى تعلم JS ، فأنا أقول إنه يقلل من قيمته السوقية إلى حد كبير. إذا قلت ، ستترك الباب مفتوحًا للسماح للآخرين بصنع تلك الأدوات لمحرك القالب كمكونات إضافية ، رائعة. ولكن ، عندئذٍ سيقاتل الجميع من أجل ما يجب أن يكون في نظام القوالب. وهذا هو أيضا IMHO بنتائج عكسية.

يتحدث الطالب عن المرشحات ، مثل Evan ، هل كان شخصًا ما يتعلم JS أو شخصًا يتعلم محرك قالب؟ إذا كان هذا هو الأخير ، أراهن أن المحادثة ستسير بشكل مختلف.

على أي معدل. ما زلت أعتقد أن Vue هو نظام رابح. آمل أن تجعل أفكاري الآخرين يفكرون بشكل مختلف حول أدوار Vue بطريقة ما. :ابتسامة:

سكوت

@ yyx990803 إذا تم صياغة المرشحات ، فلماذا تم صياغتها في المقام الأول؟

أعتقد أنه بسبب داخل <template> ، يتم تحويل جميع المتغيرات الخارجية مثل $data أو abc إلى this.$data و this.abc ومن ثم تم تحديد وظائف js العادية خارج المكون لا يمكن الرجوع إليها. تم تقديم المرشحات للتغلب على هذا القيد.

لا يزال هذا القيد موجودًا - أفترض أنني على حق --- قد تتطلب إزالة القيد من المطورين كتابة رمز this.abc بشكل صريح للإشارة إلى وظائف this.abc والوصول إلى وظائف js كما سيشار إليها في شبيبة.

ولكن ستكون هذه ميزة قوية للغاية ، وعرضة لإساءة الاستخدام وترحيل الكود القديم سيكون أمرًا مزعجًا. يبدو بناء الجملة الحالي أفضل بكثير من ذلك بالنسبة لي.

أتفق معك في أن المرشحات هي في الأساس وظائف js ويجب استيرادها إلى المكون. أنا فقط لا أحب أن يتم تعريفهم في نفس المكان مثل الأساليب.

مرحبا جميعا. قرأت الموضوع بأكمله وهذا ما أعتقده.

• لن يفوت أي شخص المرشحات المضمنة مثل orderBy filterBy وأي فلاتر أخرى
• ما يريده الجميع هو مشغل الأنابيب في القوالب
• يقول الفريق الأساسي أن المنطق يجب أن يحتفظ بجافا سكريبت ، وليس في القوالب ، إلى جانب وجود ميزة es7 القادمة مع مشغل الأنابيب.

وجود هذا كملخص سريع ، ما أعتقد أنه يمكن أن يكون حلاً جيدًا حتى تقوم js بتنفيذ مشغل أنابيب أصلي ، سيكون أن يكون مشغل الأنابيب كمكوِّن إضافي مع الاحتفاظ بالإصدار 2.0 كما هو. لذلك ، يمكن للمستخدمين القيام به

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

بينما ننتظر تنفيذ الميزة الجديدة ، يمكن تضمينها مع بعض التحذيرات بشأن الإيقاف المقبل أو شيء من هذا القبيل. أعلم أنه يمكن لأي شخص تنفيذ هذا المكون الإضافي ، لكنني أعتقد أنه سيكون أفضل إذا تم توفيره والاحتفاظ به بواسطة فريق Vue ، فهل يمكن أن يكون ذلك ممكنًا؟

قد أكون مخطئًا ، لكن لا أعتقد أن Vue يسمح للمكونات الإضافية بالعبث مع مترجمها ..

@ azamat-sharapov بالطبع لا. لم أكن أعتقد أنه سيتسبب في العبث مع مترجم Vue: open_mouth:

YerkoPalma أنا أحب تمامًا مشغل الأنابيب. أستخدمه بقلق شديد في اللغات الوظيفية ولا أطيق الانتظار للحصول عليه في JavaScript! _But_ ، تخيل أن Vue لم يكن لديها مطلقًا مرشحات. هل تطلب أن يقوم إطار عمل الواجهة الأمامية بتمديد بناء جملة JavaScript؟ هذا هو مجال Babel أو لغة التحويل البرمجي إلى JS ، وليس إطار عمل واجهة المستخدم. إذا كنت تفضل استخدام لغة مثل LiveScript ، كما أفعل غالبًا ، يمكنك ذلك. لكن المشكلة هنا ليست مع Vue. إنه مع JavaScript نفسه ولسنا هنا لإصلاح ذلك.

بالإضافة إلى ذلك ، إذا كنا قادرين على توجيه نتائج التجسيد في 2.0 من خلال Babel كما نأمل ، فستتمكن حتى من استخدام المكون الإضافي المتتبع غير TC39 إذا كنت تريد - باستمرار ، في كل مكان في JavaScript ، بدلاً من فقط في النموذج. لذلك إذا كنت تريد فقط أنبوبًا ، فمن المحتمل أن تتمكن من الحصول عليه. ويمكنك الحصول عليه اليوم في 1.x - فقط كن حذرًا من أن الأنبوب الذي ستستخدمه في القوالب الخاصة بك من المحتمل أن يكون له أسبقية وسلوك مختلفين عن ذلك الموجود في Babel.

@ smolinari وغيرها. هناك جملتان (وأشكال مختلفة منها) ما زلت أسمع:

• "فكر في المطورين / وجهة نظر المستخدم"
• "فكر في المبتدئين"

كلاهما يشير إلى افتراض - أننا لا نفكر في هذه المجموعات.

لقد ذكرت هذا من قبل ، لكني أعتقد أنه يحتاج إلى تكرار. _الجميع_ في الفريق الأساسي إما مصمم أو مطور واجهة أو مزيج من الاثنين . نحن نستخدم هذه الأدوات كل يوم لعملنا الخاص. سنستخدم Vue 2.0 أيضًا. صدقني ، نحن نفكر في ذلك. 😉

بالنسبة للمبتدئين ، فقد قدمت قضية هنا ، لكنني أعتقد أنني سأخوض في مزيد من التفاصيل. أنا معلم. وكنت من دعاة القضاء على المرشحات _التفكير في المبتدئين_. لقد علمت شخصيًا مئات الأشخاص - وربما أكثر من ألف - كيفية ممارسة تطوير الويب ، عادةً من الصفر. لا توجد خبرة سابقة في الترميز. لقد فعلت ذلك مع طلاب المدارس المتوسطة والثانوية وطلاب الجامعات والكبار المحترفين وكبار السن.

من هذا المنظور ، يمكنني أن أخبرك أنه في حين أن المرشحات قد تبدو وكأنها سحر مثير في البداية ، فإنها في النهاية تبطئ تعلم الطالب عن طريق إدخال المزيد من التعقيد لراحة محدودة. إذا لم يكونوا في Angular أو Vue مطلقًا وتم عكس هذه المحادثة - كنا نحاول تقديمهم في الإصدار 2.0 - فسنجد صعوبة في شرح سبب الحاجة إليهم ومتى يجب عليك استخدامها.

قبل أن يكون هناك أي حديث عن الإهمال في الإصدار 2.0 ، كنت قد ألغيت عوامل التصفية من المناهج الدراسية في مدرسة الشفرات الخاصة بنا ، لأننا جمعنا أدلة كافية على أنها تضر أكثر مما تنفع للمبتدئين. نفضل أن يكتسبوا خبرة مع ميزات Vue الأكثر تنوعًا ، مثل الأساليب والخصائص المحسوبة. حتى أننا لم نشجع استخدام المرشحات ، لأنها سهّلت التقاط الممارسات السيئة.

نأمل أن يضع ذلك هاتين الشكويين في الفراش. سوف نرى. 😃

لكن ، تخيل أن Vue لم يكن لديها مرشحات أبدًا. هل تطلب أن يقوم إطار عمل الواجهة الأمامية بتمديد بناء جملة JavaScript؟

بالطبع سأفعل ، لأن المرشحات طبيعية جدًا للقوالب كما في Twig ، المذكورة سابقًا. أشعر أن وجود مشغل أنابيب أمر طبيعي مثل وجود صيغة الشارب في القوالب ، أعني أن الشوارب ليست بتنسيق html ، وليست جافا سكريبت ، فهل ستقومون بإزالتها أيضًا؟ ما هو الفرق مع مشغل الأنابيب؟

إن حجة "التفكير في الأطفال" مجرد غباء. على حد علمي ، لم يتم تصميم Vue لتعليم JavaScript ، ولكن لمطوري الواجهة الأمامية لإنجاز الأمور. للمرشحات الأخيرة كبيرة.

إذا لم يكونوا في Angular أو Vue مطلقًا وتم عكس هذه المحادثة - كنا نحاول تقديمهم في الإصدار 2.0 - فسنجد صعوبة في شرح سبب الحاجة إليهم ومتى يجب عليك استخدامها.

أنا لا أوافق كثيرا. لقد كنت أستخدم إطار عمل Python يسمى Django منذ عام 2005 ولغته النموذجية - التي كانت مصدر إلهام لمعظم لغات القوالب المولودة في وقت لاحق - تحتوي على مرشحات من اليوم الأول. بعد استخدامها مع مطوري الواجهة الأمامية على مدار عشر سنوات ، أصبحت أقدر جمالهم وفائدتهم. سيكون من المحزن أن نرى هذا النحو يزول.

(هذا ما يفعله Django بالفلاتر: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference)

Uninen يرجى مراعاة نبرة بالغباء ليس طريقة بناءة للمشاركة في مناقشة.

بالنسبة لأولئك الذين يرسمون تماثلاً للغات القوالب من جانب الخادم - أحد الجوانب المهمة التي يجب ملاحظتها هو أن لغات القوالب من جانب الخادم لا تتمتع بنفس القدر من المرونة التي تتمتع بها قوالب Vue (لا توجد خصائص محسوبة ، وتعبيرات محدودة). أيضًا - تم إنشاؤها لأغراض مختلفة تمامًا: إخراج سلاسل ثابتة. قوالب Vue هي تمثيلات لـ DOM التفاعلي - هناك روابط ثنائية الاتجاه ومعالجات الأحداث ودعائم المكونات والمزيد. تتلاءم المرشحات فقط مع حالة استخدام محدودة للغاية في سياق Vue: أعتقد اليوم أنها فكرة سيئة للسماح بالفلاتر في كل مكان ، على سبيل المثال المرشحات على طراز v و v-for و v-on تقدم تعقيدًا أكثر مما تنفع.

أحد البدائل الممكنة هو الاحتفاظ بالفلاتر ولكن فقط لعمليات الاستيفاء النصية - أي يمكنك استخدامها فقط داخل {{ }} s ، وليس في التوجيهات.

كمرجع مثير للاهتمام: لا يزال لدى Angular 2 مرشحات (أعيدت تسميتها بـ "الأنابيب") ولكنها أيضًا أزلت عن قصد قائمة الفلاتر.

آسف على لغتي ، لا أقصد إهانة أي شخص.

بالنسبة لي ، الغرض من إطار العمل هو القيام بالأشياء الصعبة وجعلها تبدو سهلة للمطورين الذين يستخدمون هذه الأدوات. ما زلت أجادل بأنه لا يمكن التغلب على بناء الجملة ، ومرة ​​أخرى ، سيكون من المحزن رؤيتها تذهب.

لا أعرف أو أفهم أن الكثير من الآليات الموجودة تحت غطاء المحرك ، ولكن من وجهة نظر المستخدمين ، فإن التطبيق العملي يتفوق على النقاء :)

في ملاحظة ذات صلة ، كان من المثير للاهتمام معرفة مقدار الشغف الذي يبدو أنه موجود في هذا المجتمع. بالنسبة لي ، كانت Vue أداة جديدة ومنشطة ، ربما لهذا السبب كان عليّ المشاركة في رسم هذه السقيفة بالذات :)

بالنسبة إلى نقطة بيانات أخرى ، لا يحتوي Ember على عوامل تصفية ولا يسمح بطرق المكونات ، على الرغم من أنه يحتوي على خصائص محسوبة.

بالنسبة لحالة استخدام الوظائف الصرفة التي تؤدي عمليات تحويل داخل القالب ، يجب عليك تسجيل مساعد مقود / مساعد مقود.
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

واستخدام مرشحات محددة من حزمة 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_ كود جافا سكريبت ، لكن الباقي من يستخدمه للأشياء الصغيرة لا يحتاج إلى معرفته.

إذا تحدثنا عن _ "لمصممي القوالب" _ فيمكننا وضع

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

واستخدام الكود الداخلي

Vue.use(VueUtils)

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

من المثال ويفخرون بأنفسهم ، ليست هناك حاجة لمعرفة js لتصفية المصفوفات وفرزها ، يريد الكثير من الأشخاص القيام ببعض الأشياء ، ولكن هناك صعوبة في فهم الكود مثل

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

لذلك لا داعي لعمل أشياء معقدة لهذا النوع من الأشخاص ، إذا كان بإمكاننا تقديم حل بسيط لذلك وكان مفيدًا للمطورين.

أحد البدائل الممكنة هو الاحتفاظ بالفلاتر ولكن فقط لعمليات الاستيفاء النصية - أي يمكنك استخدامها فقط داخل {{}} ، وليس في التوجيهات.

أعتقد أن هذا يمكن أن يكون تسوية جيدة للغاية. على الرغم من أنه لن يرضي الجميع ، إلا أنه كل ما استخدمته من أجل المرشحات وأجد أنه من الغريب أنهم يستطيعون حاليًا فعل أكثر من ذلك.

سيسمح بتنسيق النص بشكل ملائم إذا كنت تريد استخدام عوامل التصفية وتقليل التعقيد عن طريق إزالة عوامل التصفية ثنائية الاتجاه بشكل فعال.

في رأيي ، فإن مثال مرشح Momjs الخاص بك يمرر بالفعل الكثير من المنطق إلى القوالب.

على محمل الجد ، يجب أن توجه كل هذا "حب الأنبوب" إلى مستودع المواصفات حتى يصل إلى TC39 :)

يعجبني ما اقترحه كل من VitaliyLavrenko . يمكن أن يكون حل وسط جيد.

سكوت

يعجبني اقتراح VitaliyLavrenko ، لكن عندما أقول شيئًا مشابهًا ، حول وجود عامل تشغيل الأنابيب في مكون إضافي ، قال @ azamat-sharapov إن المكونات الإضافية يجب ألا تعبث مع المترجم ... لذلك أنا في حيرة من أمري إذا كان ذلك ممكنًا أو إذا كنت فقط أساء فهم التعليق؟

تضمين التغريدة

ما هو الأفضل لك أن تقرأ؟

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

فكر كمطور واسأل شخصًا لا يعرف جافا سكريبت.

بالنسبة لي ، بالنسبة إلى _ليس للمطورين_ أفضل شيء مثل هذا:

Vue.use(VueUtils)

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

إنه متوسط ​​، ويستخدم مثل vue-Resource فقط lib المشترك.

حول الأنبوب ، أنا سكر نحوي

الشيء في الأشياء | عامل التصفية "foo" | عن طريق "شريط" | بحد 5

ل

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

ما سهولة القراءة؟

إذا كنت بحاجة إلى تمرير البيانات إلى نموذجين مختلفين ، فهل تقوم بتخزين 2 أو 3 تعديلات لبيانات واحدة؟

إذا كان مثل:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

ليس لدي حالة مجردة ، ولكن إذا تم استخدامها في قالب واحد أو اثنين؟ هل تحتاج إلى تخزين البيانات لـ 10 أو 100 عنصر؟ زيادة استخدام الذاكرة؟ نعم يمكننا استخدام الأسلوب المساعد واستخدامه في القالب ، ولكن بالنسبة لـ _ "لمصممي القوالب" _ الذين يبتعدون عن جافا سكريبت أفضل شيء مثل العنوان | padLeft 10 ويجب أن تُترجم إلى استدعاء وظيفي ، فهي سهلة وعملية.

فكر في الأشخاص المختلفين ، يمكن للمطورين تسهيل القيام بذلك بطريقة مختلفة ، لكن الأشخاص الآخرين يريدون القيام بذلك ببساطة.

سأقولها مرة أخرى ، الكثير من المنطق في القوالب هو مضاد للنمط. بدلاً من الاضطرار إلى تعلم DSL (عوامل تصفية) معينة ، يجب أن تتعلم جافا سكريبت.

thelinuxlich فقط استخدم

ولكن مع Vue التي نحصل عليها ، يمكن للأشخاص الذين لا يعرفون جافا سكريبت ، ولكن باستخدام Google فعل شيء ما ، وإذا كنت لا تحب الأنبوب ، فلا تستخدمه. يمكننا فقط إضافة شيء مثل

Vue.config.pipeFuncCall = true

ويمكنك تشغيله / إيقاف تشغيله ، ولكن بالنسبة لبعض الأشخاص ، يكون الأمر سهلاً.

_ سأقول مرة أخرى ، ليس فقط مطوري JS يمكنهم استخدام Vue ، إنه الجانب الأقوى من Vue._

تحتاج الفلاتر العادية القياسية ، ولكن من الأفضل أن تكون في lib منفصل ويسهل إضافتها إلى vue والاستخدام.

أو تريد أن يكون Vue شيئًا مثل ASM ويمكن للمطورين الجيدين فقط استخدامه؟

يا رفاق ، أعتقد أن القرار الذي اتخذه فريق Vue الأساسي قد تم شرحه جيدًا. ألا يمكننا تكرار الشيء نفسه مرارًا وتكرارًا والتعليق فقط بشيء جديد وذا قيم ، إن وجد؟

إذا كان جزءًا من مبادئ Vue الأساسية أن تكون أسهل للمطورين من غير JS ، حتى لو كان ذلك يضر بمبادئ اللغة ، فسأوافقك الرأي ، لكن ربما لم يكن الأمر كذلك.

كما قلت من قبل أنا على ما يرام في الغالب مع استخدام المرشحات ، سأفتقدها بالتأكيد من أجل راحتهم ، لكنني متأكد من أنه يمكن تقديم نظام مرشح مشابه جدًا كمكوِّن إضافي.

لقد قدمت دليلًا على مثال على المفهوم قبل ذلك بقليل ، والذي يمكن استخدامه في الدعائم المحسوبة ، وكذلك المضمنة

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

من ناحية أخرى ، إذا أراد شخص ما الأنبوب ، فأنا متأكد من أنه يمكن القيام به ، بشيء من هذا القبيل

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

أو ربما ، إذا كان هناك خطاف يسمح للمكونات الإضافية بتحليل التعبيرات ومعالجتها كيفما تشاء ، فقد تكون هذه طريقة ممكنة أيضًا ، لكن هذا يعتمد فقط على مدى تعقيد التنفيذ ، والتأثيرات التي سيكون لها في إطار العمل (الأداء / الحجم) ، وإذا كان @ yyx990803 يريد بالفعل السير في هذا الاتجاه أم لا!

أشعر أنه إذا حصلنا على بدائل أنيقة وسهلة الاستخدام (المكونات الإضافية أو أي شيء في جوهرها) ، فسوف نتعود عليها بسرعة إلى حد ما.

@ Rigor789 لتصفية المصفوفات وفرزها ، وما إلى ذلك ، استخدام أفضل محسوبة ، إنه نظيف للغاية. لكنني أعتقد أن هناك مشكلة في عرض البيانات بتنسيق فرق:

إذا كان لدينا حقل 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. سيتم دعم المرشحات ، ولكن فقط داخل الإقحام النصي. هذا يقصرهم على أغراض تنسيق النص مع فرض منطق آخر في أرض JavaScript.
2. سيتم شحن Vue 2.0 بدون مرشحات مدمجة. يمكن للمجتمع إنشاء حزم التصفية الخاصة بهم إذا لزم الأمر.
3. ستتغير صيغة عامل التصفية لاستخدام صيغة استدعاء الدالة للوسيطات بدلاً من استخدام المسافات المحددة. هذا يجعله أكثر انسجامًا مع JavaScript ولغات النماذج الشائعة الأخرى (Jinja2 ، swig ، twig ...):

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

شكرا لاستماعك ايفان. هذا ما يجعل Vue رائعًا. لديها قائد عظيم. :ابتسامة:

سكوت

تضمين التغريدة

الشيء الوحيد الذي يبدو أنه قد تم دفنه في هذه المناقشة هو المرشحات ثنائية الاتجاه. المرشحات ثنائية الاتجاه هي الأكثر صعوبة في النسخ مع الحلول المقترحة الأخرى.

1. ضع في اعتبارك هذا المثال البسيط ، الذي نشرته في سلسلة رسائل المنتدى. استخدام الخصائص المحسوبة لهذا سيكون له عيبان رئيسيان:
   
   
   
   1. سيتعين عليك إنشاء خاصية محسوبة جديدة لكل قيمة ، مما ينتج عنه الكثير من التعليمات البرمجية المعيارية.
   
   
   2. لجعل الأمور أسوأ ، لا يمكن حتى أن تتداخل الخصائص المحسوبة. إذا كان لديك رسم بياني كائن أكثر تعقيدًا ، فيجب أن تكون جميع خصائصك المحسوبة في المستوى الأعلى. سينتهي بك الأمر بأسماء خصائص طويلة ومطوّلة تتطلب مزيدًا من الحمل المعرفي لتتبع مسارات الخصائص المحسوبة باستمرار والتي تتداخل مع القيمة.
   
   

إن رفض حالة الاستخدام هذه على أنها "تافهة" أو "أقل تعقيدًا" يؤدي إلى نتائج عكسية. لقد استخدمت هذا في كل من التطبيقات المتوسطة والكبيرة الحجم. لقد عملت العجائب! العرض التوضيحي بسيط بالضرورة ، لكن التقنية سليمة.

1. يكون هذا مرتبكًا بشكل أكبر عند التعامل مع مصفوفة في v-for ، كما في هذا المثال (مرة أخرى ، بسيط عن قصد). التكرار على مصفوفة لن تجد ملاذًا في الخصائص المحسوبة. الطريقة الوحيدة للتغلب على هذا هي من خلال وجود مكون منفصل لكل عنصر في المصفوفة ، وإضافة المزيد من النماذج المعيارية.

قارن هذا المثال بالفلاتر:

شبيبة
استيراد العملة من "مرشح بعض العملات" ؛
استيراد المنتجات من "كعب منتجات" ؛

نيو Vue ({
el: document.body،
البيانات: {products}،
الفلاتر: {currency} ،
}) ؛
""

لشخص بدون مرشحات:

شبيبة
استيراد العملة من "مرشح بعض العملات" ؛
استيراد المنتجات من "كعب منتجات" ؛

نيو Vue ({
el: document.body،
البيانات: {products}،
عناصر: {
منتج: {
الدعائم: ["المنتج"] ،
محسوب: {
السعر: {
احصل على() {
إعادة العملة. read (this.product.price) ؛
} ،
set (القيمة) {
this.product.price = currency.write (القيمة)
}
} ،
الشحن: {
احصل على() {
إعادة العملة. قراءة (this.product.shipping) ؛
} ،
set (القيمة) {
this.product.shipping = currency.write (القيمة)
}
} ،
معالجة: {
احصل على() {
إعادة العملة. قراءة (this.product.handling) ؛
} ،
set (القيمة) {
this.product.handling = currency.write (القيمة)
}
} ،
خصم: {
احصل على() {
إعادة العملة. read (this.product.discount) ؛
} ،
set (القيمة) {
this.product.discount = currency.write (القيمة)
}
}
}
}
}
}) ؛
""

أعرف أيًا مما سبق أريد كتابته.

_{(يمكن تنظيف هذا الأمر قليلاً عن طريق إنشاء مصانع عقارات محسوبة ، ولكن تظل النقطة أن هذه مطولة أكثر بكثير مما يجب)}

نظرًا لأن الفريق الأساسي يبدو معارضًا بشدة لبناء جملة أنبوب المرشح ، فهل من الممكن تقديم معلمة filter v-model للتوجيه $ # $ 2 $ # $؟

باستخدام المعلمة filter ، سنكون قادرين على الاحتفاظ بالإصدار الأول الأنيق من JS أعلاه ، وإعادة كتابة القالب ببساطة لاستخدام المعلمة بدلاً من صيغة الأنبوب السحري:

<tr v-for="product in products">
  <td><input type="text" filter="currency" v-model="product.price"></td>
  <td><input type="text" filter="currency" v-model="product.shipping"></td>
  <td><input type="text" filter="currency" v-model="product.handling"></td>
  <td><input type="text" filter="currency" v-model="product.discount"></td>
</tr>

سيحقق هذا التوازن الصحيح لعدم وجود بناء جملة سحري مع الاحتفاظ بالقدرة على تحويل الإدخال بسهولة ذهابًا وإيابًا دون الكثير من الصيغة المعيارية.

شكرا لاهتمامكم.

لقد أعدت كتابة المثال الخاص بك لدمج المرشح الخاص بك كتوجيه مخصص: jsfiddle .
على الرغم من أنه ليس موجزًا ​​مثل المرشح ، إلا أنه ليس مؤلمًا كما تخيلته. ولم يستغرق الأمر وقتًا طويلاً لتجميع القطع معًا من الأشياء المتوفرة بالفعل لنا جميعًا.

Nirazul إنشاء توجيهات مخصصة لكل مرشح تم اقتراحه من قبل . إن الحاجة إلى إنشاء توجيه جديد يعيد تنفيذ جميع وظائف v-model لكل نوع من أنواع الفلاتر التي تستخدمها في تطبيقك هو ببساطة أمر غير معقول.

بالإضافة إلى ذلك ، لا يعمل التوجيه الخاص بك بشكل كامل مثل المرشحات ؛ عدم وضوح الحقل بعد تغيير القيمة لا يؤدي إلى إعادة تنسيقه. علاوة على ذلك ، فإن v-model يقوم بأكثر مما تفعله في هذا التوجيه.

من الواضح أن التوجيه يمكن تعديله بمزيد من الميزات والإصلاحات ، ولكن تظل النقطة: هذه كلها أدوات مساعدة على رأس شيء يجب أن يكون بسيطًا حقًا.

لم أر أي اقتراح في هذا الموضوع يشير إلى التوجيهات المخصصة. هل تسمح من فضلك بتوجيهني إلى هذا التعليق؟

كما يمكنك أن تتخيل ، لم أقم بكتابته واختباره لتستخدمه في تطبيقك. أردت فقط أن أوضح ، ما هو ممكن الآن كبديل. إذا كان هذا ممكنًا بهذه السهولة ، فربما يكون هناك مجال للمكوِّن الإضافي لأتمتة العملية بشكل أكبر.
من الواضح أن هذا التوجيه المكتوب بسرعة يفتقر إلى الوظائف الكاملة للنموذج v. ربما يكون توجيه مرشح مخصص واحد مع المعلمات و / أو المعدلات كافياً لاستبدال المرشحات.

دعنا نظل بناءين ، حيث حاولت حل مشكلتك. من الأسهل دائمًا التعجيل بالحل بدلاً من تقديم مساهمة والمضي قدمًا.

JosephSilber تحتاج إلى الهدوء. "منافية للعقل" كلمة قوية.

مرحبًا ، هل يتم إزالة الفلتر بدافع تقليل ازدحام القالب أم أنه يؤثر بشكل خطير
التنفيذ الفني 2.0؟ إذا كانت مشكلة التأثير المرئي السابقة ، فماذا عن السماح
مرشح مثل الآن (ولكن مع شكل جافا سكريبت الجديد)
ولكن يتم تحديده لواحد فقط لكل تعبير ، مثل v-for = "i of list | orderBy ('key')" ، (ليس أكثر من علامة أنبوب واحدة)
هذا يمكن أن يجعل معالجة المرشح في 2.0 أبسط ويمكن التنبؤ به وأقل ازدحامًا بصريًا.
نظرًا لأنه سيتم توزيع عامل التصفية لـ {{}} ، فإن السماح به في التعبيرات الأخرى سيكون منطقيًا.
هذا من شأنه أن يستوعب جميع حالات / وظائف الاستخدام الحالية (مثل التصفية ثنائية الاتجاه ، والعنصر داخل v-for).
يمكن بسهولة دمج / ترقية أي استخدامات حالية لأكثر من مرشح واحد في واحد بواسطة المالكين.

tomsmithgroup ما اقترحته (وأكثر من ذلك) تقرر أن يظل مدعومًا في الإصدار 2.0.

سيحب @ yyx990803 & chrisvfritz سماع أفكارك بخصوص المرشحات ثنائية الاتجاه .

JosephSilber إذن مع مصنع العقارات المحسوب الذي أشرت إليه ، ليس هناك الكثير من النموذج المعياري:

import currenciesFactory from 'some-computed-currencies-factory'
import products from 'products-stub'

new Vue({
  el: 'body',
  data: { products },
  components: {
    product: {
      props: ['product'],
      computed: currenciesFactory(['price', 'shipping', 'handling', 'discount'])
    }
  }
})

على الرغم من أنني شخصيًا ، لن أقوم بإنشاء مصنع لهذا المثال ، لأن كل خاصية من هذه الخصائص هي في الواقع مخاوف منفصلة _ تظهر_ كما هي الآن. عند إزالة المرشحات ، يصبح من الواضح أكثر مدى تعقيد هذا المكون الواحد. هذا ما تراه كنموذج معياري.

وهذا سبب كبير لوجود المكونات. لتقسيم التعقيد إلى مخاوف يمكن التحكم فيها. عندما أنظر إلى أحد المكونات ، فإن كل ما يفعله يحتاج إلى أن يتناسب بسهولة مع ذاكرتي العاملة وإلا يصبح التطوير أبطأ بكثير وأكثر عرضة للخطأ. إخفاء التعقيد خلف صيغة المرشحات لا يزيل هذا التعقيد.

لتوضيح ذلك ، دعنا ننظر إلى ما يحدث عندما تفي المشكلة بمتطلبات العالم الحقيقي المتغيرة: لنفترض أنك قررت عدم السماح للخصم بأن يكون أكبر من السعر + الشحن + المناولة. أو يجب ألا تتجاوز المناولة X كمية. أو يجب أن يكون حقل الخصم نسبة مئوية ، بدلاً من عملة. أو إذا تجاوز الإجمالي مبلغًا معينًا ، فيجب تطبيق حد أدنى للخصم تلقائيًا.

قد تميل إلى جعل المرشح أكثر تعقيدًا بخيارات إضافية ومنطق شرطي. أثناء تحديث واجهة برمجة تطبيقات المرشح والمنطق الداخلي ، عليك الآن التفكير في كيفية تأثير تغييراتك على أي شيء آخر يستهلك الفلتر - ربما حتى خارج المكون الحالي ، إذا كان هذا عامل تصفية مشترك. إذن أنت الآن في موقف حيث يبدأ إجراء تغييرات على تطبيقك بالشعور بالضيق. وكل ذلك بسبب أن عامل التصفية الثنائي المشترك قد سمح لك بتفويض حالة المكون الداخلي إلى خارج المكون ، وانتهاك حدود المكون ، وزيادة الاقتران ، وإخفاء التعقيد الذي ما زلت بحاجة إلى التفكير فيه في كل مرة تعمل فيها على المكون.

من خلال تقسيم الأشياء إلى مكونات متعددة وأقل تعقيدًا بشكل فردي ، مع خصائص محسوبة محددة بشكل منفصل أو دعائم مرتبطة ، غالبًا ما تقوم بتحديث سطر واحد للتكيف مع المتطلبات المتغيرة. لا توجد خيارات أو شروط إضافية. لا إعادة بناء ديون لتلبية تعقيد التحجيم. لست مضطرًا للتفكير في أي شيء خارج المكون _ أو حتى خارج تلك الخاصية الفردية_. كان طلبك من البداية ولا يزال من السهل التفكير فيه وتحديثه.

أعتقد أن ما يجعل المرشحات مغرية في البداية في هذه الحالة ، هو أنها علاج يسهل الوصول إليه من أجل التكرار. لكن النسخ ليس نموذجيًا عندما يكون عرضيًا (أي أن الكود هو نفسه الآن ، قبل أن تبدأ مشاكل العالم الحقيقي حتمًا في الظهور).

ولا يمكنني أن أضعها أفضل من ساندي ميتز:

الازدواجية أرخص بكثير من التجريد الخاطئ

لا علاقة لفلاتر filter="currency" من الناحية النظرية هو نفس المعلمة number . من الواضح أنه لا ينبغي التعامل مع متطلبات العمل في المرشحات.

لنفترض أنك قررت عدم السماح للخصم بأن يكون أكبر من السعر + الشحن + المناولة. أو يجب ألا تتجاوز المناولة X كمية.

ثم يمكنك استخدام بعض وحدات التحقق المناسبة ، على غرار vue-validator . سيبقى عامل تصفية العملة في مكانه بغض النظر عن ذلك ، ويعرض ببساطة القيمة الأساسية.

يجب أن يكون حقل الخصم نسبة مئوية بدلاً من عملة.

ثم من الواضح أن نوعه لم يعد عملة. لا يختلف عما إذا كنت تستبدل type="text" بـ type="email" عندما تتغير متطلبات اسم المستخدم. أو حتى عند إزالة المعلمة number عندما لا يكون الحقل رقمًا.

إذا تجاوز الإجمالي مبلغًا معينًا ، فيجب تطبيق حد أدنى للخصم تلقائيًا.

مرة أخرى ، سيتم تطبيق الحد الأدنى ، لكن مرشح العملة سيبقى في مكانه. ما زلت ترغب في عرضها كعملة.

أثناء تحديث واجهة برمجة تطبيقات المرشح والمنطق الداخلي ، عليك الآن التفكير في كيفية تأثير تغييراتك على أي شيء آخر يستهلك عامل التصفية [...] سمح لك عامل التصفية الثنائي بتفويض حالة المكون الداخلي إلى خارج المكون

لا. أنت لا تضع أبدًا أي منطق أو حالة في الفلتر نفسه. المرشح هو وظيفة غير فعالة بشكل صارم لتنسيق القيم. من الناحية المثالية ، لا ينبغي حتى تنفيذه في سياق الجهاز الظاهري ؛ يجب ألا يحتوي على this من خلاله سحب بيانات إضافية.

الازدواجية أرخص بكثير من التجريد الخاطئ

... عندما ، كما قلت ، تقوم باستخلاص الشفرة التي تصادف أنها هي نفسها الآن. من ناحية أخرى ، فإن المرشحات هي وظائف بسيطة غير فعالة تقوم بتنسيق القيمة. إنهم ليسوا فكرة مجردة على الإطلاق.

tl ؛ فلاتر type و v-model s number param.

مرشح ثنائي الاتجاه هو بالتأكيد فكرة مجردة. يخفي السلوك الحالي للفلاتر ثنائية الاتجاه على v-model الكثير من السحر في الداخل - على وجه التحديد ، يسمح لقيمة DOM للإدخال بأن تكون غير متزامنة مؤقتًا مع النموذج الأساسي ، و "تزامنها" فقط عندما طمس المجال. راجع BTWJosephSilber تم تنفيذ هذا السلوك على وجه التحديد بناءً على طلبك ، لذلك يمكنني أن أفهم سبب شعورك الشديد حيال ذلك.

ومع ذلك ، فإن أكبر مشكلة أراها مع المرشحات ثنائية الاتجاه هي أن المنطق الأساسي هو الصندوق الأسود ، وليس لدى المستخدم أي طريقة لتخصيصه بشكل أكبر بخلاف تقديم طلبات الميزات. بالنسبة لي ، الخيار الأفضل هو توفير اللبنات الأساسية المناسبة لتنفيذ مثل هذا السلوك بنفسك. واسمحوا لي أن أوضح لكم كيف يمكن ذلك في 2.0:

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

لدينا هنا مكوِّن أساسي CustomInput بتنفيذ السلوك "out-of-sync-until-blur" للفلاتر ثنائية الاتجاه الحالية. نظرًا للتغييرات في 2.0 ، يمكنك استخدام v-model على المكونات المخصصة طالما أن المكون يقبل أحداث value $ ويصدر input أحداث. بالإضافة إلى ذلك ، يقوم أيضًا بتنسيق القيمة في أحداث change ، وهو أمر غير ممكن حاليًا باستخدام الفلاتر ثنائية الاتجاه . يمكنك أيضًا تعديل هذا المكون للحصول على أي سلوك تريده دون أن تكون مقيدًا بكيفية تنفيذ المرشحات ثنائية الاتجاه بواسطة إطار العمل.

لا ينفذ المكون الأساسي منطق التحليل / التنسيق - يمكنك توسيعه باستخدام الأساليب parse و format للحصول على مكونات إدخال مخصصة مصممة لحالات استخدام محددة. في هذه الحالة ، مكون CurrencyInput .

المكون الأساسي أكثر تعقيدًا من المرشحات ثنائية الاتجاه ، لأننا نقوم الآن بتنفيذ السلوك السحري السابق بأنفسنا. ومع ذلك ، ما عليك سوى تحديد هذا المكون مرة واحدة. في المقابل ، يمكنك التحكم بشكل كامل في الطريقة التي يجب أن تتصرف بها في حال كنت ترغب في تغييرها لاحقًا. أعتقد أن هذه مقايضة جديرة.

هذا مثال على الكيفية التي يجب أن نفكر بها أكثر في المكونات لأنها تجريد موحد لإعادة الاستخدام يمنحك أكبر قدر من التحكم. راجع أيضًا مثال 2.0 كتوجيه ، ولكنه الآن مكون بنفس واجهة v-model .

بالنسبة لي ، الخيار الأفضل هو توفير اللبنات الأساسية المناسبة لتنفيذ مثل هذا السلوك بنفسك.

هذا شيء رائع وبالتأكيد ما يحتاجه Vue ، لكنني كنت أرغب في قراءة هذا

بالنسبة لي ، الخيار الأفضل هو توفير اللبنات الأساسية المناسبة للبدء بـ Vue ولتوسيع Vue أيضًا بسلوك التصفية الجديد بنفسك.

بمعنى آخر ، ألا يمكن أن يكون مكون إدخال العملة مع عدد من مكونات التصفية الافتراضية الأخرى جزءًا من Vue؟ لأن الجميع يستخدم العملات في مرحلة ما ، أليس كذلك؟ لماذا ترك الأمر للآخرين للقيام بنفس العمل مرارًا وتكرارًا؟ يعد تنسيق العملة قياسيًا بما يكفي لجعله جزءًا من حقيبة أداة مكون التصفية الخاصة بـ Vue وهي مثال أساسي رائع للآخرين لتعلم إنشاء مكونات التصفية الخاصة بهم أيضًا.

و ..... لا يوجد سوى شيء واحد مفقود من المثال ليكون مكونًا نهائيًا لإدخال العملة وهي ميزة i18n ، والتي أعتقد أن Vue يجب أن تستلزمها أيضًا. يجب أن يتغير تنسيق رقم العملة اعتمادًا على اللغة المحددة للشخص (العارض). أعني البيانات المحلية أي. "DE_de" لتنسيق العملة والأرقام الأخرى كما هو موضح في مستكشف الإعدادات المحلية هذا (والذي ينبع من معيار). أضف ذلك إلى Vue ولديك نظام مكون رائع لتنسيق العملة / الأرقام مدمج في Vue ، بحيث لا يحتاج الآلاف من المطورين الآخرين الذين يستخدمون Vue إلى إنشاء أنفسهم ، بل يمكنهم استخدامه في الحال ، عندما يحصلون على Vue . هذا يجعل Vue نظام قوالب قوي!

إذا كان استخدام "مكون تنسيق i18n" لا يمكن استخدامه بطريقة قابلة للتسلسل كمرشح مثل في 1.0 ، فيجب أن يكون قابلاً للإضافة. سيكون ذلك جيدًا أيضًا. هذا ما تفعله Aurelia وهذا ما يفعله Twig أيضًا بامتداداته . قد يظل مكون إدخال العملة <currency-input> .

يحتاج i18n ومرشحات القوالب القياسية الأخرى إلى أن تكون شيئًا لا يحتاج الآخرون إلى إعادة إنتاجه باستمرار ، إذا لم يكن عليهم ذلك. إذا أوضحت لي كيفية إنشاء مثل هذا المكون الإضافي ، فسأقوم حتى بعمل المكون الإضافي i18n نيابة عنك. أنا مهتم بهذا كله!: ابتسامة:

سكوت

لأن الجميع يستخدم العملات في مرحلة ما ، أليس كذلك؟

لا حقا لا. أنا ، على سبيل المثال ، لم أستخدمه أبدًا حقًا :) ينطبق الشيء نفسه على جميع المرشحات المضمنة الأخرى - بعضها مفيد للبعض منا ، عندما يكون الآخرون عديم الفائدة. أثناء تواجدنا في هذا الموضوع ، كنت أرغب في معظم الأوقات في استخدام عامل تصفية مدمج ، انتهى بي الأمر بكتابة نسختي الخاصة على أي حال ، مما يجعل الإصدار المدمج رمزًا ميتًا.

ميزة i18n ، والتي أعتقد أن Vue يجب أن تتضمنها أيضًا.

هذا ، مرة أخرى ، قابل للنقاش للغاية. يمكن أن يكون دعم i18n الشامل معقدًا جدًا ، ولا تنتمي IMO إلى Vue ، خاصة عندما لا يحتاجها معظم المستخدمين على أي حال.

الآن ، أود أن أثير هذا: في كل مرة نحاول فيها إجراء مقارنة بين Vue وقالب / إطار عمل آخر ، هناك شيء مهم يجب أخذه في الاعتبار: على عكس Django / Laravel / Twig ، فإن Vue هي في الأساس مكتبة عميل ، وبالتالي يجب أن يكون خفيف الوزن قدر الإمكان. سيكون من المنطقي أن تبقي الأمر بسيطًا بدرجة كافية - مع الاحتفاظ بجميع ميزات _core_ بالطبع - بدلاً من إضافة "ميزات" و "أدوات" فقط من أجل ما يسمى بـ "الفائدة" أو "الأناقة". إذا كنت تريد أي شيء بخلاف الوظائف الأساسية ، فإن الطريقة الأكثر تفضيلًا هي استخدام مكون إضافي أو حتى تطوير مكون إضافي خاص بك. خذ هذا كمثال: بالنسبة إلى SPA الشائعة ، هل i18n / Currency أكثر أهمية من جهاز التوجيه أو مدير الدولة؟ لا أعتقد ذلك. ومع ذلك ، فإن vue-router و vuex لا ينتميان إلى Vue ، لكن لهما مستودعات خاصة بهما. بمعنى آخر ، Vue تقدمي .

إذا أوضحت لي كيفية إنشاء مثل هذا المكون الإضافي ، فسأقوم حتى بعمل المكون الإضافي i18n نيابة عنك. أنا مهتم بهذا كله!

أعتقد أن هذا نهج أكثر عقلانية ، وأشكرك على اهتمامك :)

إذا كان هناك الكثير من الحاجة إلى استخدام i18n في بعض المناطق)) أعتقد أنه يمكنني الدخول في الكود وتغيير بعض أسماء بعض الأشياء يدويًا ، من أجل الجمال.
على سبيل المثال: قبل بضع ساعات فقط ، استغرق الأمر مني butstrap.datepikker - لا يمكنني الاتصال ، i18n على الرغم من حقيقة وجود مثل هذا الاحتمال. سريع 60 ثانية. "يدويا" استبدلت أسماء أيام الأسبوع والأشهر وكل شيء - طيب! ))

phanan - حجتك هي سبب ذكر "الإضافات". أوافق ، لن يرغب الجميع في استخدام العملة أو وظيفة i18n والذين لا يريدون الاحتفاظ بتطبيقهم خفيفًا ، ولكن كنظام قوالب ، أعتقد (وهذا رأيي الشخصي إلى حد كبير) يجب أن يكون لدى Vue أيضًا مثل هذه الوظائف القياسية المتاحة جدا. والأهم من ذلك ، وما يقلقني ، هو أنه لا ينبغي أن يضطر الجميع إلى إعادة اختراع i18n أو عجلات مكونات مرشح العملات. بمعنى آخر ، تمامًا مثل Vue-Router و Vuex ، هناك إضافات متاحة إلى Vue ، يمكن أن يكون عددًا كبيرًا من المرشحات القياسية مثل العملة و i18n أيضًا.

أوه ، ومن المثير للاهتمام ، أن Angular لديها i18n مدمجة على ما يبدو.

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

يدعم Angular i18n / l10n لمرشحات التاريخ والأرقام والعملات.

يبدو أن Ember و React قد سلكا طريق "دع عالم التطوير يفعل ذلك بمفرده".
فيديو ممتع.
https://www.youtube.com/watch؟v=Sla-DkvmIHY

ربما يحتاج Vue فقط إلى تكامل FormatJS؟ VueIntl؟ :ابتسامة:

تحرير: لا يمكن أن يكون بهذه البساطة ، أليس كذلك؟ https://github.com/learningequality/vue-intl/blob/master/index.js

سكوت

يحتوي Angular على i18n مدمج على ما يبدو.

يأتي Angular أيضًا مع جهاز توجيه ng والذي ، مما سمعته ، تم تجنبه بواسطة مجتمع ng لصالح جهاز التوجيه ui.

الآن ، إذا استبدل فريق Angular ng-router بـ ui-router ، فسيؤدي ذلك إلى كسر التغييرات والألم.

إذا حاولوا تحسين ng-router ، فإنهم يضيعون وقتهم لأن الحل الأفضل (ui-router) موجود بالفعل.

إذا بدأت Vue في دعم i18n والعملة وما إلى ذلك في جوهرها ، فسيحدث نفس الموقف أيضًا.

أجد الفلاتر المدمجة مريحة ، لكن في هذا الشأن أتفق مع فريق vuejs ..

ثم نتفق جميعًا على عدم وجود المرشحات في Vue core. أنا أيضًا من محبي المكونات. ولكن ، ألا تستطيع Vue تقديم المرشحات كمكونات إضافية أساسية أيضًا؟ مثل Vuex و Vue-Router؟

سكوت

ولكن ، ألا تستطيع Vue تقديم المرشحات كمكونات إضافية أساسية أيضًا؟ مثل Vuex و Vue-Router؟

هذا بالضبط ما شاركه @ blake-newman سابقًا.

مرحبًا: أشارت صفحة القرار النهائي إلى السماح فقط بتصفية النص
عرض {{}} (v-text)
ليس لتعبيرات أخرى مثل v-for = "item of list | sortBy"
أم أنني أسأت الفهم؟
ما قصدته هو الاستمرار في استخدام مرشح كما في 1.0 ولكن مع تقييد مرشح واحد فقط
لكل تعبير

في الأحد 1 مايو 2016 الساعة 10:24 مساءً ، كتب Phan An [email protected] :

tomsmithgroup https://github.com/tomsmithgroup ما اقترحته
(وأكثر من ذلك) قد تقرر
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244 ل
تظل مدعومة في 2.0.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@ yyx990803 هل لي أن أستنتج من ردك أن عوامل التصفية ثنائية الاتجاه لن يتم دعمها في الإصدار 2.0؟

fnlctrl هذا صحيح. فقط قم ببناء المكونات الخاصة بك.

سأخرج قليلاً عن الموضوع: هل هذه الفلاتر ثنائية الاتجاه مفيدة حقًا في الإنتاج؟
أعني ، هل من المقبول حقًا السماح للمستخدم بكتابة أي شيء في الإدخال ثم إعادة تنسيقه بعد أن يكون غير واضح؟
يطلب فريق العمل الخاص بي دائمًا مدخلاتنا للتصرف على هذا النحو: لا يمكنك كتابة أي شيء خطأ. حتى الآن مع Vue نستخدم قناع jquery.inputmask لهذا الغرض منذ أن تم إهمال التغيير الفوري ثنائي الاتجاه (هذا الذي أفتقده حقًا ...)
أعني ، هل هناك حقًا مشكلة في تلك المرشحات ثنائية الاتجاه أم أن الناس يفكرون فيها أكثر من اللازم؟ :)

fullfs تُستخدم المرشحات ثنائية الاتجاه على نطاق واسع في تطبيق الإنتاج لدينا (الكثير من <input> s) للراحة ، ولكن كما أراها الآن ، لماذا تصفية القيم في الوقت الفعلي بدلاً من ترشيحها مرة واحدة فقط قبل أن تصبح تم النشر على الخادم؟ سيستغرق الأمر بعض الوقت لإعادة تشكيل الكود ، لكنني أعتقد أنني لن أفوتهم: د

إذا كنت تريد تحديثًا متفائلاً لواجهة المستخدم (وهو المعيار الحالي IMHO ، خاصةً للجوال) ، فستحتاج إلى تنسيق الإدخال بشكل صحيح عمليًا في الوقت الذي تم فيه تقديم الإدخال.

سكوت

الفلاتر ثنائية الاتجاه رائعة حقًا. يمكنك دائمًا إنشاء المكونات المخصصة الخاصة بك ، مع توفر المرشحات أو بدونها ، ولكن هذا يستغرق وقتًا. يجب أن توفر المكتبة المرونة ولكن أيضًا طريقة أسرع وملائمة للقيام بالأشياء. لن يؤدي تضمين المرشحات ثنائية الاتجاه إلى منع الأشخاص من بناء مكوناتهم الخاصة إذا اضطروا إلى ذلك ، ولكنه سيسمح بالتطوير بشكل أسرع عندما تناسب الوظيفة الحالية الاحتياجات ، وهو في معظم الأوقات. إنه دائمًا حل وسط بين سطح API والراحة. يجب العثور على التوازن ، وكان Vue بالفعل رائعًا. يبدو أن التخلص من المرشحات هو خطوة إلى الوراء من النقطة الصحيحة في التوازن. تصبح المكتبة أصغر حجمًا ، لكن قاعدة الشفرة والنموذج المعياري لكل مشروع يستخدمها يكبر.

إذا كان سيتم إهمال المرشحات حقًا ، فربما يكون من الجيد توفير بديل يكون قادرًا على تحديد المحلل اللغوي والمنسقين لتوجيهات v-model ، بطريقة سهلة. باستخدام المرشحات ، يمكنك كتابة هذا الجزء فقط من المثال @ yyx990803 المقدمة:

const CurrencyInput = CustomInput.extend({
  methods: {
    parse(val) {
      var number = +val.replace(/[^\d.]/g, '')
      return isNaN(number) ? 0 : number
    },
    format(val) {
      return '$' + Number(val).toFixed(2)
    }
  }
})

بدون مرشحات ثنائية الاتجاه ، يتعين على المرء أيضًا أن يكتب

const CustomInput = Vue.extend({
  template: `
    <input type="text"
      @focus="onFocus"
      @blur="onBlur"
      @input="onInput"
      @change="setDisplayValue">
  `,
  props: ['value'],
  watch: {
    value() {
      if (!this.focused) {
        this.setDisplayValue()
      }
    }
  },
  ready() {
    this.setDisplayValue()
  },
  methods: {
    onInput() {
      this.$emit('input', {
        target: {
          value: this.parse(this.$el.value)
        }
      })
    },
    onFocus() {
      this.focused = true
    },
    onBlur() {
      this.focused = false
      this.setDisplayValue()
    },
    setDisplayValue() {
      this.$el.value = this.format(this.value)
    }
  }
})

لذلك ، مزيد من المرونة ، ولكن أيضًا المزيد من التعليمات البرمجية لنفس النتيجة.

aristidesfl - لا يتم إهمال الفلاتر. لقد ربحنا المعركة جزئياً. مضحك جدا! ستقتصر على استخدامها فقط في الاستيفاءات النصية. انظر هنا: https://github.com/vuejs/vue/issues/2873

سكوت

شكرا @ smolinari . كنت أشير بشكل خاص إلى المرشحات ثنائية الاتجاه.

إرجع من فضلك! نحن في حاجة إليه ، وأنا أوافق على كل ما قلته. لكن الأمر سهل للغاية ، فنحن مستخدمون كسالى ، ونريد فقط طريقة سهلة وهادئة. تمامًا مثل البقاء على قيد الحياة.

قد تكون هناك طريقة لإضافة مُعدِّلات مخصصة للنموذج v (http://rc.vuejs.org/guide/forms.html#Modifiers)

إنها تعمل مثل مرشحات ثنائية الاتجاه.

وافق ecmel . هذا هو الطريق للذهاب.

افتح مشكلة طلب ميزة ثم :)

ecmel فكرة مماثلة ، على الرغم من وصفها كمعدلات النوع ، تمت مناقشتها هنا .

rpkilby هذه المناقشة مغلقة أيضًا ، ربما يجب أن نفتح واحدة جديدة لمعدلات نموذج v المخصصة.

لم يعد قادرًا على القيام بذلك:

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

يبدو الحد من عوامل التصفية على {{ }} أمرًا غريبًا ، فهناك الكثير من المرات التي تريد فيها استخدام مرشح في ربط السمة (لا يمر على خاصية) ، ولا يمكننا استخدام {{ }} في السمات بعد الآن !

تم فتح LinusBorg https://github.com/vuejs/vue/issues/3666

يبدو الحد من عوامل التصفية على {{ }} أمرًا غريبًا ، فهناك الكثير من المرات التي تريد فيها استخدام مرشح في ربط السمة (وليس تمرير خاصية) ، ولا يمكننا استخدام {{ }} في السمات بعد الآن !

تمت إزالتها لأنه يمكن استبدالها بسهولة بخصائص وطرق محسوبة ، بينما لديهم واجهة برمجة تطبيقات أكثر محدودية ولا توجد إمكانية لظهور نتائج التخزين المؤقت.

لذا:

• API واحد أقل
• استخدم نفس الأساليب في النموذج ورمز JS ، ولا داعي لتكرار سلوك الفلتر لاستخدامه في كود التطبيق.
• يمكن تخزين الدعائم المحسوبة مؤقتًا
• المزيد من المرونة لأنها مجرد JS

الكود الكاذب إلى الأمام:

<!-- method, suitable in v-if  -->
<span :title=" date(item.Modified, 'dd-mmmm-yyyy H:MM:ss')>

<!-- computed prop, more suitable for single values -->
<span :title="formattedModified">
<script>
computed: {
  formattedModified () { return date(this.item.Modified, 'dd-mmmm-yyyy H:MM:ss') }
}
</script>

آسف ، أنا "جديد" فقط.
ولكن من Angular 1 ، فإن عدم وجود مرشحات يبدو أمرًا غريبًا حقًا وغير بديهي ، فلماذا يكون من الأفضل أن يقوم كل مطور بتطوير مجموعته الخاصة من المرشحات وتعيين الإدخالات المحسوبة بأنفسهم وما إلى ذلك أفضل من جعلها مدمجة؟
وما يعتبر الآن أفضل ممارسة لتصفية مصفوفة كبيرة حقًا ، حسب الكائنات الموجودة في العنصر. مع الزاوية ، كان هذا سطرًا واحدًا فقط من التعليمات البرمجية. كان من الممكن تصفية مصفوفة لإدخال بحث وستقوم بكل السحر ، والتي يجب أن تكون وظيفة إطار عمل.

وما يعتبر الآن أفضل ممارسة لتصفية مجموعة كبيرة حقًا

ما هي حقا مجموعة كبيرة؟ من الناحية النظرية ، فإن الخاصية المحسوبة ستفيد في التصفية أيضًا.

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

لماذا يكون من الأفضل أن يقوم كل مطور بتطوير مجموعته الخاصة من المرشحات وتعيين الإدخالات المحسوبة بنفسها وما إلى ذلك بشكل أفضل من جعلها مدمجة؟

اعتدت أن أفكر بنفس الطريقة (ولماذا بدأت الموضوع) ، ولكن منذ أن علمت أن إنشاء هذه الأنواع من الفلاتر بنفسك هو عبارة عن قطعة من الكعكة ، وأن هناك الكثير جدًا من الأشياء التي قد يرغب كل مطور في تنفيذها كمرشح (أو خاصية محسوبة) ، أدركت أن عدم وجود فلاتر مضمنة ليس بهذه الأهمية.

سكوت

في حالتي ، يساوي أكثر من 10.000 سطر في json المقدمة بواسطة قاعدة بيانات Firebase.
أرى سبب تفكيرك بهذه الطريقة ، وقررت إسقاط الميزة ، ومع ذلك فهي مشكلة إضافية للمطورين.

لقد شورت كمانًا ليكون متوافقًا مع هيكل البيانات الخاص بي:
https://jsfiddle.net/nw5yhLwv/
لذا أحتاج إلى ترميز البحث عن سلسلة في موضوعي يدويًا؟

أنا لا أفهم سؤالك. آسف. يشبه الكمان الذي نشرته.

سكوت

الفلاتر المحسوبة مقابل الفلاتر

من المحتمل أن تكون المرشحات سيئة للأداء ، حيث يتم حسابها لكل عرض (تمامًا مثل الطرق) والخصائص المحسوبة سهلة مثل الكعكة ، ولا يُعاد حسابها إلا عند الضرورة ، وإلا يتم تخزين النتائج مؤقتًا ، مما يعني أن Vue يمكن أن تطير.

أوه. ولدينا كلاهما. 😄

سكوت

مرحبًا ، لقد قمت ببعض العبث والآن فهمت ، إنه مفهوم رائع! 😄

سأغلق هذا الخيط الآن ، حيث انتهى النقاش حول هذا لفترة طويلة - Vue 2.0 خرج منذ شهرين ، وتراجع النقد حول انخفاض المرشحات إلى حد كبير.

مزيد من المناقشة في هذا الموضوع ليست مثمرة. إذا رأيت زاوية جديدة للموضوع الذي تعتقد أنه يحتاج إلى مناقشة ، فيرجى فتح عدد جديد.