لا يمكن إعادة استخدام خصائص posva المحسوبة.

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

في الثلاثاء ، 13 سبتمبر 2016 ، الساعة 18:48 ، فرانسيسكو لورنسو ، [email protected]
كتب:

posva https://github.com/posva الخصائص المحسوبة غير قابلة لإعادة الاستخدام.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/vuejs/vue/issues/3666#issuecomment -246746524 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAoicf33lCvETQc9LBQ5GGZ93ExPcLS_ks5qptPegaJpZM4J7vQ0
.

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

بعبارة أخرى ، لا يمكن إعادة استخدام الخصائص المحسوبة. يمكنك استخدام وظائف المصنع + mixins كحل بديل ، ولكن لا تقارن قابلية الاستخدام وقابلية القراءة.

بالنسبة لمشروعي ، كنت في حاجة ماسة إلى هذه الميزة ، لذلك استخدمت نهج الإدخال المخصص الموصى به:

InputCustom.js

define(function () {
  return Vue.extend({
    data: function () {
      return {
        focused: false
      };
    },
    template: '<input @focus="onFocus" @blur="onBlur" @input="onInput" @change="setDisplayValue">',
    props: ['value'],
    watch: {
      value: function () {
        if (!this.focused) {
          this.setDisplayValue();
        }
      }
    },
    mounted: function () {
      this.setDisplayValue();
    },
    methods: {
      onInput: function () {
        this.$emit('input', this.parse(this.$el.value));
      },
      onFocus: function () {
        this.focused = true;
      },
      onBlur: function () {
        this.focused = false;
        this.setDisplayValue();
      },
      setDisplayValue: function () {
        this.$el.value = this.format(this.value);
      }
    }
  });
});

InputText.js

define(['js/InputCustom'], function (InputCustom) {
  return InputCustom.extend({
    methods: {
      parse: function (val) {
        val = val.trim();
        return val === '' ? null : val;
      },
      format: function (val) {
        return val === null ? '' : val;
      }
    }
  });
});

في رأيي ، هذا النهج مناسب جدًا وقررت عدم استخدام أي مُعدِّلات طراز v على الإطلاق بما في ذلك .lazy .

لمزيد من حالات الاستخدام المخصصة التي لا تستطيع المُعدِّلات المضمنة دعمها ، فإن ما ذكره ecmel هو الأسلوب الموصى به. سنقوم بتوثيق ذلك بمزيد من التفاصيل في الدليل الرسمي.

فكرة اقتراح هذه الميزة هي الاستفادة من التوجيه الحالي v-model ، والذي يعمل بالفعل مع كل عنصر input . لحفظ عمل كتابة _InputCustom.js_ في كل مشروع ، لأن ذلك قد تم بالفعل في v-model ، ما عليك سوى كتابة ما يعادل _InputText.js_ في معدل مخصص ، والذي يحتوي على كل المنطق الذي يحتاج إلى يمكن تعديلها في معظم الأحيان. حقيقة أن v-model يشحن بالفعل مع المعدلات يثبت أنه نمط بديهي ومرغوب فيه. من الطبيعي فقط تسهيل إنشاء معدّلات مخصصة ، لحفظ عمل إنشاء عناصر مخصصة والاضطرار إلى تنفيذ ربط dom / Model يدويًا.

إذا كان الأمر منطقيًا من منظور API ، فسيكون من المثير للاهتمام معرفة القيود الفنية التي تقود قرار عدم تنفيذ هذه الميزة.

هل هناك أي فرصة يمكننا إعادة فتح هذه القضية؟ حالة الاستخدام الشائعة بالنسبة لي هي الحاجة إلى تنسيق البيانات تلقائيًا في حقل ما أثناء كتابتها. شيء مثل أخذ "101216" وتحويله إلى "10/12/16". القدرة على إنشاء مُعدِّل نموذج v مخصص من شأنه أن يبسط الكود الخاص بي إلى حد كبير حيث يمكنني كتابة v-model.date بدلاً من الاضطرار إلى إنشاء مكون إدخال مخصص مع الدعائم والأحداث.

بعد استخدام vue js لفترة من الوقت الآن في مشروعي ، أعتقد أنه يجب إعادة فتح هذه المشكلة بالفعل.

على الأقل نحتاج إلى مُعدِّل undef .

أوافق على إعادة فتح هذه المشكلة. لست متأكدًا مما كان من المفترض أن يفعله undef ، لكني أرغب في استخدام مُعدِّل v-model الذي يضبط المتغير الخاص بي على null في حال كانت قيمة الإدخال التي تم اقتطاعها عبارة عن سلسلة فارغة.

أحب أن أكون قادرًا على القيام بذلك بنفسي بطريقة مباشرة.

تمت إضافة وظائف أكثر من ذلك على سبيل المثال مع https://github.com/vuejs/vue/issues/5194 . من الخارج ، يبدو أن Vue تتنازل ببطء عن بعض مبادئها لصالح الاتفاقيات والممارسات التي يروج لها مجتمع التفاعل. انحرفت قليلاً عن الصفات التي جعلتها تبرز في المقام الأول. سيكون من المثير للاهتمام معرفة ما إذا كان هذا قرارًا واعًا بقصد جعل الهجرة من رد الفعل أسهل ، أو مجرد مصادفة.

كتابة المكونات المخصصة أمر جيد ولكن إذا كنت تريد استخدام مكون مخصص تابع لجهة خارجية مثل https://github.com/text-mask/text-mask/tree/master/vue#readme ، فلا توجد طريقة مباشرة لتعقيم المقنع إدخال قيم النموذج باستثناء استخدام الخصائص المحسوبة.

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

ولكن أفضل حل على الإطلاق هو دعمه محليًا كما هو الحال في مربع الاختيار وحقل الإدخال القياسي الآخر ، فلماذا يعتبر "التاريخ" شيئًا مميزًا؟

+1 للمُعدِّلات المخصصة. يبدو وكأنه لا عقل ، ما لم يكن هناك سبب وجيه لعدم؟

يعد إخفاء المدخلات وتحليل القيمة لاستخدام التطبيق ممارسة شائعة جدًا ، كما أن صنع بعض "السكر التركيبي" مثل v-model.lazy.currency = "amount" سيكون أمرًا رائعًا!

1+ للمعدِّلات المخصصة.
لديّ إدخال راديو بسيط بقيم صحيحة | خاطئة يتم تقييمها على السلاسل - لكنني أحتاجها باعتبارها قيمة منطقية - لن تكون الخصائص المحسوبة ذكية في هذه الحالة لأنني بحاجة إلى إعادة تنفيذ خاصية محسوبة لكل إدخال لاسلكي. على سبيل المثال ، سيؤدي وجود 100 إدخال راديو إلى 100 خاصية محسوبة

+1 للمُعدِّلات المخصصة ولكني أتفق مع tobei - يجب أن يعمل الإدخال [type = date] تلقائيًا.

+1 للمُعدِّلات المخصصة.

لقد جئت من خلفية Angular ، وبدأت للتو مع vue ، ورأيت هذا الموضوع.

أشعر أنه سيساعد حقًا وجود شيء مثل الموزعين والمنسقين في Angular ، في Vue أيضًا. إذا كان بإمكاني فعل شيء مثل v-model.dateFormat وأنتج شيئًا مثل mm / dd / yyyy ، فسيكون ذلك رائعًا حقًا.

تحرير: يبدو أنه تكرر على ما قاله @ restored18 . +1 لك أيضًا

+1 لمعدِّلات نموذج v المخصصة.

في حالتي ، أقوم بعمل حلقة حول عدد قليل من الكائنات المتداخلة التي تم استردادها في JSON ، واستخدم قالب HTML واحدًا (بدلاً من قالب لكل كائن). في هذه الحالة أعتقد أن الخصائص المحسوبة لا تعمل؟

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

+1 لهذا. كان متوفرا قبل 2.2. يمكنك الوصول إلى الممتلكات من خلال ،

this.$vnode.data.directives

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

+1 لهذا.

ستكون معدّلات نموذج v المخصصة رائعة!

أنا أيضا

+1 في 2018 أيضًا ...

+1 إنها ميزة ضرورية لكود DRY في رأيي. يتعين علي الآن إنشاء 10 مراقبين يفعلون نفس الشيء لنموذج مع الكثير من المدخلات. معدّل مخصص من شأنه أن يحل كل شيء.

+1 لقد بدأت للتو vue وأحتاج بالفعل إلى هذا النوع من المرشحات ثنائية الاتجاه ...

+1 مطلوب بالتأكيد

+1

يمكنك بناء مساعدين مثل هذا لمعظم حالات الاستخدام IMO

nickmessing الذي لا يغطي حالة الاستخدام (المفيدة حقًا) الموضحة هنا ، والتي تعد تعديلًا موضعيًا لنص الإدخال. إذا كان لديك مربع إدخال تريد تنسيقه دائمًا مثل الهاتف ، فسيكون لديك <input v-model.phone="some_data"> . عندما يقوم المستخدم بإدخال نص ، فإنه يقوم بتنسيقه تلقائيًا.

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

أتفقbbugh تمامًا ، لدي حالة مماثلة مع تنسيق IBAN وستكون طريقة لطيفة وممتعة لوضع v-model.iban="payment.iban" هناك ...

franciscolourenco ربما يمكن لشخص ما أن يضع بعض الأسباب وراء عدم دعم إطار العمل لهذا الأمر حتى يصبح أكثر وضوحًا.

+1 للمُعدِّلات المخصصة ، هناك الكثير من حالات الاستخدام التي يمكن إنجازها باستخدام هذه الميزة

يوجد في تطبيقنا القليل من المدخلات المختلفة لتنسيق العملات ، فنحن دائمًا نخزن مبلغ السنتات في النموذج ، لكننا نعرض مبالغ الدولارات المنسقة بشكل جيد في المدخلات (لذلك 123456 في النموذج المعروض على أنه 1،234.56 <input v-model.dollars="cents" /> أمريكيًا)

حالة الاستخدام الأخرى هي تطهير وإلغاء إلغاء حقول html من أجل منع XSS atacks (مخازن النموذج " A & B " بينما يظهر الإدخال " A & B ") <input v-model.html="text" />

+1

+1

+1 للمُعدِّلات المخصصة.
لقد فوجئت حقًا بأنني لا أستطيع فعل شيء مثل v-model.trim.uppercase=...

+1

+1

+1

+1
ستكون معدّلات الإدخال الأصلية v-model ميزة رائعة. كما يذكر الناس هنا ، هناك الكثير من حالات الاستخدام. كنت بحاجة لمعدلات التاريخ والعملات لجميع المشاريع التي كنت أعمل عليها.

هل يجب أن نفتح قضية هنا؟ https://github.com/vuejs/rfcs

لقد أجريت 1+ لهذا بالفعل ، ولكني أرغب في إرسال ملاحظة للأشخاص الذين يحتاجون إلى شيء "الآن"

في حين أن المُعدِّل أكثر فاعلية ، فقد تمكنت من تحقيق نفس التأثير باستخدام إدخال / مكون شفاف مع حقل getter / setter محسوب.

يمكنني مشاركة مثال إذا احتاجه شخص ما

لم ننفذ هذا لأن هناك العديد من الأشياء التي يجب مراعاتها في هذه الميزة التي تبدو سهلة:

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

• لتكوين وقت التشغيل ، ما نوع واجهة برمجة التطبيقات التي يجب أن نكشف عنها لهذا؟

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

  • السبب في أن لدينا .number و .trim هو أنهم في الحقيقة عبارة عن تحويلات أحادية الاتجاه (يتم تطبيقها فقط عند مزامنة قيمة DOM مع بيانات المكون) وبالتالي ضمان الاستقرار.

• كيف يجب أن تتصرف المُعدِّلات المخصصة عند استخدام v-model في أحد المكونات؟

• كيف يجب أن تتصرف المُعدِّلات المخصصة في أنواع الإدخال غير النصي ، على سبيل المثال radio و checkbox والأهم من ذلك <select> ؟

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

rkingon يوجد بالفعل مثال في https://github.com/vuejs/vue/issues/3666#issuecomment -249583603 ، ولكن إذا كان ما يخصك مختلفًا / أفضل ، فما عليك سوى نشره. يمكن أن تكون مفيدة للمبتدئين.

Gotterbild لقد فاتني هذه العينة ، لكنها معقدة على نطاق واسع في الإصدارات الأحدث من Vue (كان من الممكن أن يكون دعم مكون شفاف مسبقًا)

هذه طريقة بسيطة جدًا لدي والتي تحول النسبة المئوية إلى رقم عشري (على سبيل المثال: 4.5 -> .045) والعكس بالعكس (قيمة "العرض" وقيمة "النموذج")

<template>
    <input type="number" v-on="listeners" v-model="innerValue">
</template>

<script>

    export default {
        props: ['value'],
        computed: {
            listeners () {
                const { input, ...listeners } = this.$listeners
                return listeners
            },
            innerValue: {
                get () {
                    return (this.value) ? `${(this.value * 100)}` : ''
                },
                set (_val) {
                    const val = (_val) ? (_val / 100) : ''
                    this.$emit('input', val)
                }
            }
        }
    }

</script>

هذا أكثر بساطة مما ورد أعلاه حيث لا يتعين عليك إعادة تحديد كل التركيز / التمويه / إلخ

@ yyx990803 شكرًا على تقديم مزيد من المعلومات الأساسية حول هذا الموضوع.

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

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

لقد جئت إلى هنا لأنني كنت أتطلع إلى عمل معدل لتحويل سلسلة إلى أحرف كبيرة
كنت أرغب في إنشائه مثل v-model.uppercase="username"

انتهى بي الأمر باستخدام التوجيه المخصص

Vue.directive('uppercase', {
    update (el) {
        el.value = el.value.toUpperCase()
    },
})

<input type="text" v-model="username" v-uppercase>

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

Christhofernatalius مع الأخذ في الاعتبار أن v-model هو مجرد توجيه ، ألا يمكنك حذف $ v-model لصالح التوجيه المخصص؟ بهذه الطريقة أنت لا تقوم بالتحديث مرتين؟

Christhofernatalius مع الأخذ في الاعتبار أن v-model هو مجرد توجيه ، ألا يمكنك حذف $ v-model لصالح التوجيه المخصص؟ بهذه الطريقة أنت لا تقوم بالتحديث مرتين؟

rkingon هل يتم التحديث مرتين؟
لذا ، إذا لم أستخدم نموذج v ، فحينئذٍ أحتاج أيضًا إلى إضافة ربط ربط وفك ربط لمستمع الإدخال ، وتحديث قيمة اسم المستخدم؟

تحرير: ألا يتم تحديث الاستخدام المحسوب مع setter و getter مرتين أيضًا؟
تحرير 2: جربت تسجيل وحدة التحكم للمراقب والتوجيه ، كل منهما يطبع مرة واحدة فقط لكل ضغطة مفتاح.

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

يحتوي الحل البديل للمكوِّن الخاص بي على قيود أيضًا ، وهذا هو السبب في أنني ما زلت أؤيد المُعدِّل - أي: يتطلب عنصرًا ، ووقت عرض أكثر ، ويعمل فقط كمكون في كيفية تعريف هذا المكون (على سبيل المثال: حقل إدخال ) مقابل القدرة على استخدامه ببساطة على عنصر / عنصر تعسفي وهو قوة التوجيه.

طريقتان لجلد القط ، من الجيد أن يكون لديك خيارات :)

هل يوجد RFC لهذا؟

لا أعتقد ذلك

يمكنني إنشاؤه ولكن هل هذا يعني فقط إضافة مشكلة في RFC repo أو أي شيء آخر؟

https://github.com/vuejs/rfcs#what-the-process- هل هذا يجيب على سؤالك؟

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

Vue.directive('number', {
  update: function(el, binding, vnode) {
    el.value = el.value.replace(/[^\d.]/g, '');
  },
});

إذا أضفت هذا التوجيه (جنبًا إلى جنب مع النموذج الخامس) وكتبت الأحرف بسرعة كبيرة مع كل ضغطات مفاتيح أخرى ، فسيخرج v-model من المزامنة مع el.value . ونظرًا لأنه لا يمكنك تعديل كائن الربط الذي تتلقاه ، فلا توجد طريقة "لإعادة تنفيذ" نموذج v داخل هذا التوجيه

jeankvd أعلم أنه يبدو وكأنه مبالغة ، لكن مكون الغلاف سيكون الأكثر موثوقية (انظر المثال أعلاه).

سيسمح لك مكون الغلاف "بعمل المزيد" أيضًا. في مثال "الرقم" ، من الناحية المثالية ، يصبح نموذج v فعليًا Number . في نهجك ، لا يزال String .

ماذا لو كنت تريد تخصيص القيمة الفارغة؟ سلسلة فارغة؟ باطل؟ غير معرف؟ - يمكنك تمرير الدعامة مقابل emptyValue وتعيينها على هذا النحو.

بينما كنت مدافعًا عن هذا مرة واحدة ، أدركت بعد فترة وجيزة أن للمعدلات الكثير من القيود وأن مجرد وجود مكون هو أفضل بكثير (على الأقل imo).