Vue: 2.0 التغييرات

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

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

شكرا @ yyx990803. لا يزال لدي المزيد من الأسئلة بخصوص المترجم والميزات الأخرى ، لكني استخدمت المنتدى لذلك.

هل تم إجراء أي تغييرات مقلقة على المستندات يجب أن أراجعها بأي فرصة؟ عمل عظيم! إستمر ​​في ذلك يا هذا. أنت تعيد تعريف تطوير الويب. شكرا لك!

هل يمكنني الحصول على this.arg من توجيهي؟

أرى أن vnode.data.directives لديه arg ، لكن عندما يكون لدي توجيهان أو أكثر ، لا يمكنني معرفة index .

<!-- show @ 0, img @ 1-->
<img v-show="true" v-img:200*200="imgSrc">

<!-- img @ 0, show @ 1-->
<img v-img:200*200="imgSrc" v-show="true">

هل يجب علي استخدام forEach ؟ شكرا لك!

banricho نقطة جيدة ، تم التغاضي عنها! راجع التوقيع المحدث لوظيفة التوجيه.

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

<carousel>
  <img src="..." alt="..." desc="..." is="argument">
  <img src="..." alt="..." desc="..." is="argument">
</carousel>

آمل أن يكون الأطفال بمثابة نوع من الحجج ، وليس فقط تقييد الصفات
في الوقت الحالي يمكنني إنشاء مكون ، مثل الاستخدام

<carousel items="[{}, {}, {}]"></carousel>

لكنني أعتقد أنه ليس جيدًا تمامًا ، وآمل أن يكون مثل هذا الذي صنعته من قبل في React coverflow

andyyou - ربما يكون من الأفضل نشر هذا السؤال في المنتدى ، لأنه ليس مشكلة ، ولا اقتراحًا واضحًا ، ولا أي مساعدة حقيقية لهذه المشكلة.

http://forum.vuejs.org/

إذا اكتشفت أنه لا يمكن تلبية متطلباتك مع Vue في موضوع المنتدى الخاص بك ، فيمكنك فتح مشكلة جديدة هنا.

سكوت

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

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

jrenton بشكل عام ، يمكننا اعتبار نظام الحدث ببساطة كمكون A يخبر المكون B أن يغير حالته ، أو A يخبر B أن يفعل شيئًا آخر.
لذلك بالنسبة للحالة الأولى ، يمكننا استخدام إدارة الحالة (إدارة حالة مشتركة لـ A و B) بدلاً من استخدام نظام الأحداث للسماح لـ A بإخبار B بتغيير الحالة.
بالنسبة للحالة الثانية ، أعتقد أنه يمكن التعامل معها من خلال نهج "حافلة الحدث" بشكل جيد.

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

أنا أستخدم Twig مع Vue.

حتى الآن (vue 1.0) كنت أقوم بتمرير البيانات إلى المكونات الخاصة بي مثل هذا:

<my-component data="{{ DATA }}"><my-component>

(لاحظ أن {{ و }} هي علامات غصين - بالنسبة إلى vue ، كنت أستخدم محددات مخصصة ${ و } )

إذا كنت أفهم الأشياء بشكل صحيح ، فيجب أن أفعل ذلك في Vue 2.0 على النحو التالي:

<my-component :data=" '{{ DATA }}' "></my-component>
حق؟

gholol لا ، إنه مجرد

<my-component :data="{{ DATA }}"></my-component>

في الواقع ، يبدو أن استخدامك القديم لا ينبغي أن يعمل في المقام الأول.

حسنًا ، لقد عملت بشكل جيد ...

كما قلت ، البيانات تأتي من محرك قالب غصين. الآن في Vue 2.0 لا يعمل. لقد كنت أحاول تمريرها كما قلت (بدون فاصلات مفردة) ولكن خاصية البيانات تصبح غير محددة.

خطأ: SyntaxError: مفقود} بعد قائمة الخصائص

تحرير: إنه يعمل ، لقد نسيت أن أذكر أن متغير البيانات عبارة عن سلسلة

jrenton فكرتي template .

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

@ yyx990803 أراد الشعور بالمغامرة اليوم معرفة مقدار الجهد الذي يتطلبه ترحيل بعض 1.0 إلى 2.0a ، لسوء الحظ لأنه لا يمكن استخدام الاستيفاء البسيط بعد الآن ، كيف يمكنني القيام بشيء بسيط مثل <input type="text" name="account[categories][{{ category.id }}]"> في 2.0؟

تعمل القوالب المضمنة ES6 في التعبيرات الملزمة:

<input type="text" :name="`account[categories][${ category.id }]`">

https://jsfiddle.net/Linusborg/cm4v75xh/

إذا كانت هذه هي الطريقة الوحيدة لجعل هذا يعمل على 2.0 ، فلا تمانع في أن أقول إن هذا تراجع في الصيغة الجميلة 1.0 جعلنا نتعود - نعم أعلم أن هذا مجرد ES2015.

أفترض أنه تمت إزالة الاستيفاء لأسباب تتعلق بالأداء؟ أنا فقط آمل أن يكون الأمر يستحق الصيغة القبيحة.

oskarkrawczyk أفترض أنك تريد أن تنتهي بشيء مثل name="account[categories][fruits]" في DOM الخاص بك ، لأن هذا هو ما سيعرضه تعبيرك .

الإصدار 2.0 (و 1.0 المناسب ، في الواقع) سيكون :name=" 'account[categories][' + category.id + ']' " .

تضمين التغريدة أعتقد أن {{ }} أفسدني قليلاً.

@ yyx990803 يمكنني إدراج عنصر ديناميكيًا ، مثل هذا؟

    render () {
        return this.$createElement('div', { staticClass: 'list-container' }, this.list)
    },
    data () {
         return {
               list: []
         }
    },
    method: {
         a () {
               this.list.push(this.$createElement('myComponent', {}))    
         }
    }

كيف يمكنني ربط قيم قليلة لسمة تعتمد على التعبير؟ فمثلا:

new Vue({
  el:'body',
  data:{
    flag: true
  }
})

<input type="text" v-bind:placeholder="{test: flag, test2: !flag}" />

أتوقع النتيجة التالية:

<input type="text" placeholder="test" />
<!-- or -->
<input type="text" placeholder="test2" />

nervgh ليس هذا هو المكان المناسب لطرح هذا السؤال.
استخدم التعبير الثلاثي ، v-bind:placeholder="flag ? 'test' : 'test2'" .

simplesmiler ، شكرا لإجابتك. أحاول أن أقول إن _Object-Syntax_ سيكون مفيدًا في هذه الحالات ، لكنه لا يعمل كما أتوقع.

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

رد: .once و .sync تم إهمالهم.

أليس هذا الانقطاع عن أنماط التصميم الشائعة حقًا؟

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

لدي مكونات بسيطة لأنواع مختلفة من حقول النموذج ، على سبيل المثال ، ها هو قالب مكون "textbox" الخاص بي:

<label>{{type.caption}}:<input type="text" v-model="data"></label>

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

ثم أستخدم هذه المكونات على سبيل المثال:

<div v-for="field in type.fields">
    <component :data.sync="data[field.name]" :is="field.ctype" :type="field">

ملاحظة: كل هذه المكونات لها دعائم: data و type . data هي العقدة في بنية البيانات التي يتم تحريرها بحيث يكون المكون مسؤولاً عن توفير واجهة مستخدم للتحرير ، و type هي العقدة في بنية البيانات (الضخمة والثابتة) التي تحتوي على الأنواع / التسلسل الهرمي.

كيف يمكن لمثل هذه الأشياء أن تعمل بدون .sync ؟

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

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

JasonWoof v-model في الإصدار 2.0 يمكنه العمل على المكونات المخصصة. يحتاج المكون ببساطة إلى:

1. كشف خاصية باسم value
2. إرسال حدث input عندما تحتاج القيمة إلى المزامنة مع الأصل ، على سبيل المثال ، this.$emit('input', value)

انظر المثال .

@ yyx990803 شكرا على الشرح

لماذا إزالة .sync ؟

لا أرى الميزة ، فقط العيوب. يوضح المثال الذي ربطته أنه يمكنك تحقيق نفس الشيء باستخدام :selected.sync أو v-model . لا أرى سوى عيوب طريقة النموذج الخامس:

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

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

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

أنا جديد على Vue.js (منذ 3 أيام) ولكن مما يمكنني رؤيته حتى الآن ، فإن Vue.js قيمة بشكل أساسي بسبب شيئين:

1. سهولة التلاعب في دوم باستخدام القوالب
2. نشر تغيير القيمة / البيانات التلقائي ، بما في ذلك إطلاق تغييرات القالب

على الأقل هذا ما اكتشفته حتى الآن.

يبدو لي أن إزالة .sync يجعل من الصعب جعل Vue.js يقوم بالثانية باستمرار.

JasonWoof لأن الآثار الجانبية الصريحة مقابل الضمنية خارج نطاق المكونات الخاصة تحدث فرقًا كبيرًا في إمكانية الصيانة على المدى الطويل.

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

لذلك هذا قرار تصميم لإجبار الأشخاص على القيام بذلك بشكل صحيح من البداية.

مثال:

• نقوم بمزامنة قيمة name بين أحد الوالدين والطفل. كل شيء على ما يرام.
• نحن نقرر - "هم ، عندما تتغير هذه القيمة ، نحتاج إلى القيام بشيء في الوالدين!" _
• لذلك ، قمنا بإنشاء دالة watch . لطيف!
• ندرك لاحقًا أن المراقب يبدو وكأنه يطلق النار عندما لا نريده. لكن لا يمكننا تحديد السبب حقًا ، لأننا لا نستطيع حقًا وضع console.log() أي مكان لتتبع السلوك.
• بعد الكثير من التفكير الجاد ، ندرك أننا - حقًا - نريد فقط أن يحدث هذا الشيء عندما تتغير القيمة في الوالد ، وليس في الطفل أو "الجد".
• نحاول الآن إيجاد طريقة للتمييز بين هذه السيناريوهات في وظيفة watch بطريقة أو بأخرى.
• فقط لإدراك أن هذا يجعل الشيء البسيط معقدًا للغاية
• وفي النهاية ، يخبرنا أحدهم بإزالة المزامنة ، لذلك نتخلص منها بالكامل ونستخدم خاصية أحادية الاتجاه وحدثًا منبعثًا للتعامل مع الموقف - تصبح الشفرة أبسط وأكثر وضوحًا ، لذلك من السهل التفكير في كيفية و عندما تتدفق البيانات ويصبح من السهل تصحيحها. تم العثور على الخطأ بسرعة ويمكننا المضي قدمًا.

... وهذا يصبح أكثر جنونًا عندما تقوم بالمزامنة بعمق أكثر من مستوى.

هذا هو النمط (المضاد) الذي رأيناه مرارًا وتكرارًا في المنتديات وفي الدردشة الجذابة.

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

موافق. شكرا لك على شرح.

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

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

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

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

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

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

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

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

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

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

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

بالتأكيد. ونحن لن نفرض عليهم "القوة" ، لأنه قد تكون هناك بعض الحالات الحرجة حيث قد يظل هذا ضروريًا. لذلك لا يزال بإمكانك الوصول إلى this.$parent ، يمكنك تمرير $data خلال دعامة وما إلى ذلك ، ولكن بصراحة تامة لن يكون القيام بذلك أكثر ملاءمة لأن $emit في حدث معظم الوقت ، لذلك لن تكون جذابة مثل .sync السكر.

أيضًا ، $parent et.al. ليست جزءًا من الدليل الرسمي ، لذا فإن المستخدمين الذين يستخدمونها يعملون بنشاط حول أفضل الممارسات المقترحة - وهو ما يمكنهم فعله بحرية ، لكننا لا نشجع هذا السلوك.

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

هل يودا لديها نسخة صينية؟ .

كيف يبدو التوافق لجهاز التوجيه vue؟

اضحك

هناك بعض التغييرات اللازمة لتكون متوافقة ، ونأمل في دمج جهاز التوجيه بشكل أفضل في Vue.

@ بليك نيومان

هل يمكننا الحصول على نموذج معياري معًا على vue-cli؟ لا يمكنني الحصول على أي من هذا العمل

اضحك

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

هل هناك وقت مقدر لمرشحي الإصدار التجريبي / الإصدار؟

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

@ blake-newman أشكرك على هذا الرد السريع والموجز والكامل. هؤلاء هم الأفضل. :-د

أي حل بديل لـ replace: false في vue 2.0؟

مرحبًا ، هل JSX قابلة للاستخدام بالفعل؟

reohjs - لا وأنا شخصياً أرى ذلك كخطوة حقيقية إلى الوراء لـ Vue ، إذا كان يدعم JSX.

سكوت

reohjs في تيار إيفان الليلة الماضية ، ذكر أنه يمكن إنشاؤه باستخدام مكون إضافي ، لذلك أتخيل أنه بمجرد دخول هذا الإصدار التجريبي ، لن يستغرق الأمر وقتًا طويلاً حتى يقوم شخص ما بإنشائه. أنا سعيد لأنه ليس في جوهره ولكن المكوِّن الإضافي لـ JSX يبدو فكرة رائعة.

أنا سعيد لأنه ليس في الصميم

👍 👍 👍 👍

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

يجب أن يكون تجميع JSX سهل التحقيق باستخدام هذا البرنامج المساعد: https://babeljs.io/docs/plugins/transform-react-jsx/

أعتقد أن الوظيفة _h ستكون استبدال React.createElement

ماذا عن توفير واجهة لإنشاء معدِّلات نموذجية مخصصة كطريقة لاستبدال المرشحات ثنائية الاتجاه؟ يبدو أنه يتم استخدامها بالفعل لتحليل إدخال المستخدم (على سبيل المثال v-model.trim ). إذا كان التحليل / التنسيق بسيطًا ومستقلًا عن خاصية بيانات معينة ، فإن استخدام المُعدِّل سيسمح بإعادة استخدام التحليل / التنسيق باستخدام صيغة معيارية أقل بكثير من تعيين خاصية محسوبة لكل خاصية بيانات فردية ، أو إنشاء مكون جديد لكل منها نوع الإدخال حيث نريد تطبيق التحليل / التنسيق.

مرحبًا ، أنا أعمل حاليًا على مكون إضافي لدعم gettext في Vue.js 1.0 ولدي توجيه يستخدم vm.$interpolate .

أتساءل كيف أقوم بترحيل الكود الخاص بي إلى 2.0 منذ:

• سيتم إهمال vm.$interpolate
• لن يكون للتوجيهات مثيلات في 2.0

أم أن هناك طريقة أفضل من التوجيه؟

import languages from 'src/plugins/translate/languages'
import translateUtils from 'src/plugins/translate/utils'

const translateDirective = {
  terminal: true,
  params: ['translateN', 'translatePlural'],
  paramWatchers: {
    translateN: function () {
      this.translate()
    },
  },
  isPlural: function () {
    return 'translateN' in this.params && 'translatePlural' in this.params
  },
  bind: function () {
    this.boundTranslate = this.translate.bind(this)
    this.msgid = this.el.innerHTML.trim()
    this.translate()
    languages.eventEmitter.on(languages.languageChangedEventName, this.boundTranslate)
  },
  unbind: function () {
    languages.eventEmitter.removeListener(languages.languageChangedEventName, this.boundTranslate)
  },
  translate: function () {
    let n = this.isPlural() ? parseInt(this.params.translateN) : 1
    let translation = translateUtils.getTranslation(this.msgid, n)
    this.el.innerHTML = this.vm.$interpolate(translation)
  },
}

export default translateDirective

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

مجد لهذا الإصدار _Next_! 🎆

kemar لست على دراية بـ gettext ، لكنني سأقوم ببساطة بتوسيع Vue.prototype باستخدام طريقة ترجمة $ ، ثم أفعل

{{ $translate('some.Key.path') }}

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

components: [compA, compB, compC]

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

أرى أنك تذكر rendering to native interfaces on mobile بـ weex وكنت أتساءل كيف سيكون من السهل إجراء حديث vue و Nativescript .

هناك شيء آخر على غرار Nativescript for Vue سيكون إما Weex ، الذي ذكرته ، أو Quasar .

سكوت

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

jrenton المستمعون <child @some-event="parentHandler">

عمل رائع يا رفاق.

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

بدون ذلك ، ستكون حقيقة بياناتك متناسبة معكوسًا مع بعدك عن المكون الأعلى.

فقط أريد أن أقول ما يلي:

render (h) {
    return (
    <div>
      {this.things.map(thing => <Thing thing={thing}></Thing>)}
   </div>
 );

يجعلني سعيد

هل من المتوقع أن يتم إضافة المزيد إلى هذه القائمة قبل إصدار 2.0؟ مجرد فضول لأن القضية لا تزال مفتوحة.

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

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

مع إزالة $broadcast ، كيف يمكنك إخبار الطفل المباشر بفعل شيء ما عند حدوث شيء معين؟ سيكون هذا سيناريو حيث لم تتغير أي بيانات بالفعل ، لذا لا يبدو أن الدعائم التفاعلية مناسبة.

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

هناك $emit في الطفل يمكن للوالد الاستماع إليه باستخدام مستمع مضمن ، فهل هناك أي شيء آخر؟

يمكنني تمرير مثيل للباعث عبر دعامة ، ثم emmiter.on في الطفل ، هل يبدو ذلك فظيعًا؟

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

// Vuex store
state: {
  items: [],
},
mutations: {
  ITEM_REMOVED: function(state, id) {
    var io = state.items.findIndex(item => item.id === id);
    state.items.splice(io, 1);
  },
},

// within the parent component
vuex: {
  getters: {
    items: state => state.items,
  },
  actions: {
    removeItem(store, id) {
      store.dispatch('ITEM_REMOVED', id);
    },
  },
},

<!-- within the parent template -->
<item v-for="item in item"
  :item-data="item.data"
  @removed="removeItem(item.id)"
>
</item>

<!-- within the child template -->
<button @click="$emit('removed')">Remove</button>

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

fergaldoyle نظرًا لأن الوالد يعرف دائمًا أنه أطفال ، يمكنك وضع v-ref:some-child على الطفل للحصول على المرجع إلى vm للطفل ، ثم إما $emit عليه ، أو فقط استدعاء طريقة مباشرة بـ this.$refs.someChild.<methodName>(...) .

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

كنت ألعب مع vuejs 2 ولاحظت Snabbdom إذا مررت

h('div', {style: {color: '#000'}}, [
  h('h1', 'Headline'),
  h('p', 'A paragraph'),
]);

إلى وظيفة التجسيد التي تحصل عليها

<div style="color:#000;"><h1>Headline</h1><p>A paragraph</p></div>

ولكن في vuejs تحصل عليه

<div style="color:#000;"><h1></h1><p></p></div>

هل هناك طريقة لتعديل محتوى النص (داخل <h1> )؟

dubcanada لماذا لا تمر هؤلاء كأطفال؟

الحق سيكون له معنى. شكرا

مرحبا. لدي بعض الأسئلة حول نظام الانتقال في Vue 2.0 أو بالأحرى اقتراح لأنني لا أرى أنه موجود في خطط Vue 2.0. في Vue 1.0 ، غالبًا ما واجهت الحاجة إلى اكتشاف وقت انتهاء بعض الانتقالات / الرسوم المتحركة التي قمت بإعدادها. الآن أفعل ذلك باستخدام setTimeout ، لكن هذه طريقة مبتذلة وقبيحة للغاية ، يمكننا أن نتفق جميعًا. لذا فإن سؤالي هو ، هل سيكون في Vue 2.0 طريقة ما لاكتشاف نهاية انتقال CSS عندما نستخدم الانتقال جنبًا إلى جنب مع v-show / v-if ، ربما عبر حدث؟

<my-comp v-show="isVisible" @transition-end="onTransitionEnd" transition></my-comp>

سأكون سعيدًا جدًا برؤية شيء كهذا في إصدار Vue التالي :) شكرًا لسماعك

sqal يمكنك فعل ذلك باستخدام خطافات النقل: https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

dubcanada سيتم دعمه في الإصدار التالي (حذف البيانات عند إنشاء العنصر)

شكرًا fergaldoyle و simplesmiler على التلميح الذي

لم أكن أعلم أن الوالد قادر على الاستماع إلى الأحداث التي أطلقها الطفل. بالطبع من المنطقي الاستماع إلى هذا الحدث غير المتدفق بعد ذلك.

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

لقد كنت أعمل مع Angular و React و Vue وبالنسبة لي فإن Vue هي الأكثر منطقية! أثناء القراءة عن React ، صادفت مشروع لوحة التفاعل. الشيء المثير للاهتمام هو أنه بدلاً من تحويل DOM الظاهري إلى عقد DOM حقيقية ، فإنهم يرسمونها على لوحة الرسم.

نظرًا لأن Vue 2.0 يستخدم أيضًا DOM الظاهري ، كنت أتساءل عما إذا كان يمكن القيام بشيء مثل هذا أيضًا؟

مرحبا،

فقط بعض التوضيحات حول إزالة .sync وما قد يبدو عليه سير العمل العام للتعامل مع الدعائم على مكون عام.

لذلك ، الانتقال من
<component :value.sync="some.value"></component>
ل
<component :value="some.value" @update="updateSomeValue"></component>

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

props: ['value'],
computed: {
    _value: {
        get(){
            return this.value;
        },
        set(newVal) {
            this.$emit('update', newVal);
            return newVal;
        }
    }
}

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

هل هذا يعني أننا الآن بحاجة إلى القيام بشيء مثل هذا:

props: ['value'],
data() {
    return {
        _val: this.value
    }
},
watch: {
    value(newVal) {
        this._val = newVal;
    }
},
computed: {
    _value: {
        get(){
            return this._val;
        },
        set(newVal) {
            this._val = newVal
            this.$emit('update', newVal);
        }
    }
}

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

أم أنني أفتقد القليل من التفاعل السحري هنا؟

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

Towerful ماذا this._value = newValue ) بدلاً من الصريح this.$emit('value-updated', newValue) ؟

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

simplesmiler باستخدام خاصية محسوبة يسمح لك v-model .
كما أن وجود أداة الضبط والجمع في مكان واحد يجعل من السهل الذهاب ورؤية الوظيفة عندما يتم تحديث القيمة ، بدلاً من وجود طرق مختلفة للوصول إلى القيمة وتغيير القيمة داخل المكون ، ومشتتة في جميع أنحاء الكود.
في حالة استخدام الطريقة الصريحة داخل النموذج ، وعدم استخدام المُحدِدين ، يبدو أن الكائن methods سوف يتم ازدحامه باستخدام أساليب النوع updateValue للقالب ، على عكس الطرق الفعلية.

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

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

Towerful - أنت لست الوحيد ....

سكوت

@ قوي :

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

بالنسبة لهذه الأنواع من المكونات ، يمكنك استخدام v-model على المكونات في 2.0:

<my-input v-model="myValue">

// in my-input.vue
<input :value="value" @change="$emit('input', $event.target.value)">

export default {
  props: ['value']  //special prop received from v-model
}

هذا يجعل الواجهة الحقيقية لعناصر <input> ومكونات الإدخال المخصصة متطابقة بشكل أساسي ، وربط ثنائي الاتجاه.

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

يجب أن يقرر الوالد ما يجب فعله بالقيمة التي يتلقاها من الطفل ، ولا يجب تغيير بياناتها ضمنيًا كما يفعل .sync .

هل يمكنك تقديم مثال _not_ solvabel بنهج v-model أعلاه وما زال مستفيدًا من استخدام .sync ؟ قد يكون هذا أساسًا للمناقشة أفضل من النظرية المجردة.

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

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

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

إعادة: طرق التشوش. بالنسبة للحالات البسيطة ، يمكنك دائمًا إجراء @value-updated="value = $arguments[0]" . بالنسبة للحالات المعقدة ، من الجيد أن يكون لديك طريقة ، حيث يمكنك ضبط الحالة للحفاظ على اتساقها (على سبيل المثال ، تشغيل التحديثات يدويًا). سيجواي إلى النقطة التالية.

رد: الابتعاد عن التفاعلية. أنا لا أتفق مع هذا البيان. بالنسبة للحالات البسيطة ، لا تحتاج إلى السحر لجعل الطفل يلتقط القيمة ، محدثة بـ value-updated="value = $arguments[0]" .

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

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

@ yyx990803 هل يمكننا تنفيذ طريقة للاستماع إلى إصدار $ ، على غرار الطريقة التي عقدنا بها أحداثًا لـ $ dispatch و $ بث في vuejs1؟

يشعر بمزيد من vuejs-esque ، شيء على غرار هذا ("تشغيل" أو "استمع"):

Vue.component('cart', {
  template: "#cart-template",
  data () {
    return {quantity : 0 }
  },
  watch: {
    'quantity': function (quantity, oldQuantity) {
      console.log('quantity changed from %s to %s', oldQuantity, quantity)

      bus.$emit('cart.quantity-changed', quantity)
    }
  }
});

new Vue({
  el: '.container',
  data : function () {
    return {
      quantity: 0
    };
  },
  on: {
    'cart.quantity-changed': function (newQuantity) {
      console.log('quantity change emitted');

      Vue.set(self, 'quantity', newQuantity);
    }
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

سيؤدي هذا بشكل أساسي إلى إرفاق نفسه تلقائيًا بالحافلة العالمية.

لا تعد حافلات الأحداث نمطًا نريد تشجيعه - إنها مفيدة فقط في بعض الحالات المتطورة. بشكل عام ، يُفضل نمط المتجر ، مثل vuex.

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

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

مثال بسيط على كود بدون استخدام حل متجر حقيقي مثل vuex:

var store = {
  cart: {
    quantity: 0
  }
}
Vue.component('cart', {
  template: "#cart-template",
  data () {
    return store.cart
  },
});

new Vue({
  el: '.container',
  data : function () {
    return store.cart;
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

أود أن أقول إن الفكرة العامة لـ vue2 هي جعل إطلاق النار على نفسك أكثر صعوبة
في القدم.

يوم الأحد 3 يوليو 2016 الساعة 11:24 صباحًا ، Thorsten Lünborg [email protected]
كتب:

حافلات الأحداث ليست نمطًا نريد تشجيعه - إنها فقط
مفيدة بعض الحالات الحافة. بشكل عام ، يُفضل نمط المتجر ، مثل vuex.

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

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

kharysharpe $emit s معدة للاستماع بـ v-on في المثيل الفرعي . هذا أيضًا له فائدة إضافية تتمثل في القدرة على الاستفادة من السياق الأصلي لمكان استخدام المثيل:

<list-item v-for="(item, index) in items"
  :title="item.title"
  @remove="items.splice(index, 1)"
>
</list-item>

هل هناك موعد لإصدار 2.0؟ أنا متحمس جدًا للتغييرات. مبروك!
أفكر في استخدام Vue 2.0 + Redux.

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

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

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

const mutations = {
  LOGIN (state) { state.loggedIn = true },
  LOGOUT (state) { state.loggedIn = false }
}

export const types = Object.keys(mutations)

// For now we dynamically generate all the actions like this.
// It's rare when anything more complicated is needed, but there
// is an example here:
// http://vuex.vuejs.org/en/actions.html
export const actions = types.reduce((o, el) => {
  var action = S(el.toLowerCase()).camelize().s
  o[action] = ({dispatch}, ...args) => dispatch(el, ...args)
  return o
}, {})

ماذا عن خارطة طريق vue 2 و vuex 2. هل من المخطط إطلاقهما معًا أو أحدهما قبل الآخر وماذا عن توافق الإصدارات المختلفة؟

فيما يتعلق بالسؤال أعلاه ، ما هي الحالة مع vue-router - هل سيحصل على دعم Vue 2 قريبًا أم هل يجب إجراء اختبار Vue 2 بدون جهاز التوجيه؟

gwildu من المحتمل أن يتم إصدارهما معًا إلى حد ما وسيدعم Vuex 2.0 Vue 2.0 فقط. سيستمر برنامج Pre 2.0 Vuex في تلقي الدعم حتى يصبح Vue 1.x غير مدعوم.

سيتلقى جهاز التوجيه

شكرا على nfo chrisvfritz :)

chrisvfritz تصحيح Uninen : Vuex 2.0 يعمل أيضًا مع Vue 1.x.

الإصدار الرئيسي التالي من vue-router سوف يدعم Vue 2.x.

Runtime build only: نظرًا لأنه لا يتضمن المترجم ، فأنت بحاجة إما إلى قوالب مجمعة مسبقًا في خطوة ترجمة ، أو وظائف تصيير مكتوبة يدويًا.

هل هناك / هل ستكون هناك طريقة للترجمة المسبقة للقوالب دون استخدام ملفات vueify / vue-loader و .vue ؟ إذا لم يكن كذلك، فإنه سيكون فكرة جيدة أن يكون المساعد بابل لتحويل template: خصائص ل render ظائف في المكونات؟

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

هل سيكون من الممكن إنشاء مكون طرفي ، الآن ذهب هذا elementDirective؟

كما ذكر:

لم يعد الطراز v يهتم بالقيمة الأولية المضمنة. سيعامل دائمًا بيانات مثيل Vue على أنها مصدر الحقيقة.

اعتبر ذلك

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value" />
  <label :for="_uid"><slot></slot></label>
</child-component>

كيف يمكنني التعامل مع مربع الاختيار مع المصفوفات بين المكونات المخصصة؟

_محدّث 1: _
تم حلها. تحويل الخاصية type="checkbox" إلى المكون الفرعي في المكون الرئيسي.

<parent-component>
  <child-component type="checkbox" v-model="parentModel" value="apple"  />
  <child-component type="checkbox" v-model="parentModel" value="orange" />
  <child-component type="checkbox" v-model="parentModel" value="banana" />
</parent-component>

ثم يمكنك الحصول على قيمة مضمنة عبر {props: [ 'value' ]} .
قم بإرسال حدث change للمكوِّن الأصلي لتخبر أن القيمة قد تغيرت.

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value"
    @change="$emit('change', $event)"
  />
  <label :for="_uid"><slot></slot></label>
</child-component>

هذا لأن المترجم يجمع التوجيه v-model وفقًا لـ type . وسيقوم المترجم بإنشاء الخاصية checked وربط حدث change به.

_محدّث 2: _
ومع ذلك ، لا يتم تشغيل خطاف دورة الحياة updated بسبب v-model مباشرة يغير السمة checked (هذا يعني أنه لا يمكنك الحصول على حدث change لمكون مربع اختيار html أصلي عن طريق تعديل قيمة v-model ).
لذا ، @ yyx990803 ، هل يمكنك تشغيل حدث change بعد تغيير v-model ؟

@ YunSun-CN الطريقة الوحيدة التي تمكنت من خلالها من التغلب على مشكلتك هي إضافة خاصية محددة للقيمة ، ala val ، واستخدامها لتعيين القيمة الفعلية ، ثم إرسال التغييرات فقط إلى إدخال v-model ' حدث.

johnleider لقد كتبت توجيهًا مخصصًا لمحاكاة ما يفعله v-model .
بالمناسبة ، يجب عليك إنشاء نماذج بطريقة صارمة ليس فقط التحقق من type prop ولكن التحقق من اسم عنصر العنصر. وإلا ، فقد يستبدل مكون مخصص آخر يحتوي على type prop سلوك النموذج الافتراضي الخاص به.

مرحبا. هل نعرف موعد الافراج؟

thanosalexander لم نقرر موعدًا بعد ، لا. لقد أدخلنا للتو بعض التغييرات الرئيسية في نظام Transition مع الإصدار 2.0.0 bet.2 ، والتي يجب اختبارها بشكل كامل. لذلك ، سيظل هناك أسبوعان حتى نتمكن من التفكير في إصدار ، في رأيي.

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

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

هل توجد أي خطط لتنفيذ وضع الانتقال خارج تبديل المكون في 2.0؟
https://github.com/vuejs/Discussion/issues/156

@ miljan-aleksic Docs سيكون جاهزًا عندما يتم إصدار الإصدار 2.0 رسميًا. ما زلنا في مرحلة تجريبية. ؛)

حتى ذلك الحين ، يمكنك متابعة التقدم في التوثيق هنا (أو حتى المساهمة)

aristidesfl تم بالفعل. 🎉

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

نتفق أيضًا على أن التوثيق الممتاز هو جزء حيوي من Vue. حتى دان أبراموف من فريق React يحب مستنداتنا. 😄 لهذا السبب يعد أحد أهدافي الشخصية أن تكون مستندات 2.0 _حتى أفضل_. في غضون ذلك ...

بالنسبة لأي شخص يريد التعرف على الإصدار 2.0 مبكرًا ، أوصي باختبارات وحدة الميزات باعتبارها أحدث الموارد المتاحة.

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

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

لا يبدو أن createElement في دالة التصيير التي تستخدم on تتعامل مع المصفوفات (مثل snabbdom) هل هناك طريقة لتمرير البيانات إلى الوظائف التي تم استدعاؤها؟

على سبيل المثال في snabbdom يمكنني استخدامها

{on:{click: [function, dataToPass]}}

وسيحصل function على dataToPass كوسيطة أولى. ولكن يبدو أن هذا خطأ في vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function . هل هناك طريقة لتمرير البيانات والحدث باستخدام عنصر on from create؟

dubcanada ،

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

@ miljan-aleksic جرب تصييرها ، والحصول على محتوى العنصر بـ innerHTML ، ثم إخفاء العنصر باستخدام display: none في css.

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

في هذه الحالة ، قم بتصيير الإخراج في عنصر مختلف عن العنصر الأصلي.

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

أنت محق Kingdaro ، الأفضل هو عدم خلط المفاهيم وإبقائها بسيطة. كان من الجيد أن يكون لديك hihgligthig ، على الرغم من :)

عند استخدام v-on التوجيه و $arguments متغير غير متوفر بعد الآن. لا أرى أي إشارة إلى هذا التغيير هنا. هو خلل أو مرجع مفقود؟

@ miljan-aleksic فقط استخدم arguments .

يجب أن يكون مطور PHP (مثلي) ... أعرف كيف تشعر. مضحك جدا!

سكوت

@ yyx990803 ، smolinari أنا ...

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

<button ref="button"...></button>
<foo :connect="$refs.button"></foo>

في الوقت الذي يتم فيه عرض Foo ، لا يزال $refs.button غير محدد. في Vue 1 يعمل كما هو متوقع. ما الذي أفتقده هذه المرة؟

إنك تفتقد إلى أنه لا يجب عليك تمرير عناصر DOM أو مثيلات المكون كعوامل خاصة ...

لماذا هذه فكرة سيئة؟ لنفترض أن لدي مكون منسدلة أريد توصيله بزر (المشغل). كلاهما مكونان مستقلان وبدلاً من توصيلهما من خلال استعلام أقوم بتمرير المرجع مباشرة.

@ miljan-aleksic من الأفضل توصيلهم عبر الحالة:

• يتم الحفاظ على حالة الفتح / الإغلاق في الوالد المشترك
• يقوم الوالد بتمرير الحالة إلى القائمة المنسدلة كدعم
• يستمع الوالد إلى حدث الزر لتبديل الحالة

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

ليس من السهل التخلص من العادات القديمة. هل يجب أن ألوم jQuery أم أنا بشكل أساسي؟ :د

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

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

لا يزال يمكن؟ يمكنك إجراء addEventListener('body', ... ) بالكامل من مكوّن القائمة المنسدلة لتسجيل النقرات الخارجية وما إلى ذلك ... يمكن أن ترسل القائمة المنسدلة ببساطة حدثًا "قريبًا" للوالد عندما ينقر شخص ما بالخارج ، للحصول على جهاز.

نعم! نعم. حان الوقت لإعادة بناء بعض المكونات :) شكرا للجميع! مجتمع رائع.

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

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

blocka ليس لديك حق الوصول إلى التوجيهات المضمنة إذا كنت تستخدم وظيفة render . سيكون عليك التعامل مع المنطق المكافئ بنفسك. على سبيل المثال ، v-if مجرد تعبير ثلاثي ، v-for array.map() تعبير v-model (على عنصر <input> عادي ) وترجمتها إلى value ملزمة و input المستمع الحدث.

@ yyx990803 هذا ما برزت. من المحتمل أن ينتهي بي الأمر بالتعامل مع ذلك باستخدام HOC (أقوم بالفعل بتسليم الشروط الشرطية بنفس الطريقة (على الرغم من أنني أفكر في استخدام هذا )

مع vue 1 ، كانت هناك ميزتان معلنتان عن vuex مقابل redux.

1. الأداء أفضل لأن vuex يغير الحالة ، والذي يعمل بشكل أفضل مع vue (استبدال الحالة القديمة كان أداء مكافئًا لـ "الفحص القذر")
2. إن Vuex "تدرك" أنها في تطبيق vue

هل استخدام النطاق الافتراضي يخفف بعض أو كل 1؟

blocka يخفف بعضًا منها ، لكن الأداء العام سيظل أفضل بكثير من Redux.

ما تغير في 2.0 هو دقة التفاعل. دعونا نجري مقارنة:

• في Vue 1.x ، تكون التفاعلية دقيقة للغاية. كل توجيه وكل نص ملزم له مراقب مناظر. ينتج عن هذا تحديثات دقيقة عندما تتغير البيانات ، ولكن على حساب المزيد من التبعية لتتبع النفقات العامة عند التقديم الأولي ، واستخدام أعلى قليلاً للذاكرة.
• مع Redux ، التفاعل ليس له تفاصيل على الإطلاق. عندما يتغير أي شيء ، يحتاج التطبيق بأكمله إلى إعادة تصيير. في React ، يقوم ارتباط Redux ببعض التحسين على الحاويات المتصلة ، ولكن لا يزال المستخدم بحاجة إلى تنفيذ shouldComponentUpdate على نطاق واسع للحصول على أداء أفضل.
• في Vue 2.0 ، يكون للتفاعل حبيبات متوسطة. يحتوي كل مكون على مراقب مقابل يتتبع تبعيات ذلك المكون. عندما تتغير البيانات ، ستحتاج المكونات التي تعتمد على التغيير فقط إلى إعادة تقديم DOM الظاهري. يعد هذا في الأساس أفضل سيناريو لـ React ، لكنك لست بحاجة إلى فعل أي شيء لتحقيق ذلك في Vue 2.0.

بشكل عام مع الإصدار 2.0 ، سترى (مقارنة بـ 1.x)

• تحديثات أبطأ قليلاً (ولكن لا تزال سريعة جدًا) لتغييرات البيانات الصغيرة
• تحديثات أسرع بشكل لائق لتغييرات البيانات المتوسطة إلى الكبيرة
• تصيير أولي أسرع بشكل ملحوظ

مهلا،
لا أحصل على انتقالات مع animated.css للعمل.

<transition enterClass="fadeIn" leaveClass="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

هل لدى شخص ما فكرة؟

أسماء وسائل الدعم الخاصة بك خاطئة.

camelCase vs kebap-case لا يزال ساريًا في

<transition enter-class="fadeIn" leave-class="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

LinusBorg أنا آسف ، لقد حاولت ذلك بالفعل. هنا لدي كمان صغير. مع انتقالات css وعلامة الاسم ، تعمل بشكل جيد.
https://jsfiddle.net/z0nyfba0/

عند استخدام v-model على أحد المكونات ، هل سيكون للمكون رؤية لأية مُعدِّلات مستخدمة مع v-model ؟

على سبيل المثال ، إذا كان لدي مكون يُصدر حدث input ، فإن إصدار هذا الحدث يعتمد على ما إذا كان المُعدِّل lazy مستخدمًا أم لا.

fergaldoyle لقد لعبت مع هذا قليلاً وأعتقد أنه لا يمكنك استخدام معدّلات نموذج v على عنصر مخصص لأنك تحتاج إلى إرسال حدث الإدخال يدويًا. إذا كنت ترغب في تحقيق سلوك كسول ، فأنت بحاجة إلى ربط حدث change بالإدخال ، على سبيل المثال https://jsfiddle.net/cynhtLty/1/

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

https://jsfiddle.net/Linusborg/z0nyfba0/1/

1. يجب عليك استخدام enter-active-class و leave-active-class
2. يجب أن تضع class="animated" على عنصر <router-view> .

fergaldoyle وفقًا lazy ، سيتفاعل النموذج v مع change بدلاً من input . يمكنك استخدام هذا لتغيير السلوك ، وإصدار input أو change لإعطاء نتائج مختلفة اعتمادًا على ما إذا كان يتم تقديم lazy أم لا.

لقد كنت أخدش رأسي أثناء اللعب بمثال بسيط v-for . لسبب value ملزمة لا يعمل ل select العناصر في 2.0: https://jsfiddle.net/972eL5fL/

ومن المحتمل أيضًا أن نلاحظ في المستندات أن نطاقات v-for مثل "i in 10" تبدأ من 1 بدلاً من 0 كما في 1.0.

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

لقد كنت أخدش رأسي أثناء اللعب باستخدام حرف v البسيط على سبيل المثال. لسبب ما ، لا يعمل ربط القيمة مع عناصر محددة في 2.0: https://jsfiddle.net/972eL5fL/

يبدو أنه يعمل كما هو متوقع بالنسبة لي ، ما الذي لا يناسبك؟

إعلان الخدمة العامة

نحن نشجعك على طرح أسئلة الدعم على المنتدى أو على gitter .

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

شكرا لك.

لماذا تم إهمال vm. $ get؟
لماذا لا Vue.get بدلا من ذلك؟
إنه مفيد جدًا في تقييم عمليات الإجهاد المحسوبة مثل هذا
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

iagafonov @ ليس هناك الكثير من السيناريوهات التي يكون فيها هذا مفيدًا ، لذلك لا ينبغي أن يكون جزءًا من جوهرها.

إذا كنت بحاجة إلى وظيفة لواحد من السيناريوهات القليلة ، فيمكنك بسهولة إضافة سلوك مشابه بمساعدة مثل: لوداش:

import get from 'lodash/get';
Vue.prototype.$get = get

//in any component
var value = this.$get(this.someObject,'some.path.to.value')

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

تضمين التغريدة بادئ ذي بدء ، أنا لا أستخدم اللوداش أو شيء من هذا القبيل.
ثانيًا ، تنفيذ اللوداش بطيء ، لأنه في وقت التشغيل حاول التعمق في هيكل الانحدار. يتوافق vue مع الوظيفة المحددة الجديدة (عن طريق parseExpression) ، المرتبطة بالنطاق.
إنه ليس بالجزء التافه ، من الصعب جدًا إعادة تطبيقه.
بالطبع ، $ get compile function في كل مرة). سيكون لطيفًا إذا كان parseExression جزءًا من واجهة برمجة التطبيقات في Vue.util ، على سبيل المثال.

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

ما هي بعض البدائل لسمات المعاملات المتوقفة الآن؟

هل تتحدث عن المعلمات في التوجيه؟ ثم يمكنك العثور على جميع السمات المرتبطة داخل كائن vnode

<button v-test="123" color="red" type="button">click me</button>

bind (el, binding, vnode) {
 // vnode.data.attrs -> { color: 'red' }
}

sqal ، هل هذا رد على سؤالي؟ إذا كان الأمر كذلك ، فأنا أتحدث عن السمات المميزة مثل كسول ، وعدد ، و debounce. على سبيل المثال ، قبل الإصدار 2.0 ، كان بإمكاني فعل هذا <input type="text" v-model="msg" number> (الرقم هو سمة معلمة هنا). كيف يمكنني الحصول على نفس النتائج بدون استخدام سمة البارامتر؟

@ p-adams التي ورد ذكرها في المنشور - إنها معدِّلات الآن <input v-model.number="msg">

أجد في Vue 2.0 ، عندما تتغير الخاصيات ، يتم استدعاء وظيفة التقديم دائمًا ، لذلك أتساءل أن 2.0 سوف يدعم shouldComponentUpdate لتقرير ما إذا كان سيتم إعادة التصيير.

@ yyx990803 حسنًا ، أراها الآن في The lazy and number params are now modifiers .

شرح HeChenTao Evan هذا قليلاً هنا https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

HeChenTao لا يتم استدعاء وظيفة التصيير "دائمًا" ، فقط عندما تكون مطلوبة:

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

يمكن فعل نفس الشيء في التفاعل مع mobx. أنا متأكد تمامًا من أنك لست مضطرًا إلى تنفيذ shouldComponentUpdate . ومع ذلك ، مثل vue ، تصر mobx على حالة قابلة للتغيير. إذا كنت قد اشتريت ، لسبب ما ، مفهوم الحالة الثابتة. في هذه الحالة ، استفد من رد الفعل بـ shouldComponentUpdate .

فهل هذا يعني أنه إذا أصر شخص ما على حالة غير قابلة للتغيير ، فلن يكون vue مناسبًا؟

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

المكونات الوظيفية هي مجرد وظائف وبالتالي ليس لديهم أطفال. IMHO ، يجب إهمال الأطفال والاحتفاظ بالفتحات على أنها ليست كسولة.

blocka يمكنك تنفيذ البيانات التفاعلية بالتفاعل مع mobx ، صحيح. لكن التفاعلية هي جوهر وظائف Vue. لذلك إذا لم يكن هذا هو فنجان الشاي ، فهذا الشخص في الطرف الخطأ.

@ ميليان-اليكستش children هي خام (يمكنك الحصول على كل عقدة بغض النظر عن ما فتحة يجب أن تذهب إلى)، slots ستحل على أساس slot الأسماء على الأطفال واردة.

شكرا @ yyx990803. ربما تتجنب المزيد من التفاصيل حول هذا الأمر في المستندات الالتباس ،chrisvfritz.

@ miljan-aleksic سأضيف ملاحظة. 👍

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

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

@ yyx990803 ، ما رأيك في تعيين مرجع $context إلى النموذج الأولي للمكون؟ كما هو الحال مع $parent أو $root وجدت نفسي في كثير من الأحيان يصل إلى السياق الذي لا يتوفر حاليًا إلا من خلال الكائن $vnode .

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

@ miljan-aleksic هل يمكنك مشاركة حالات الاستخدام التي تقوم فيها بالوصول إلى السياق بشكل متكرر؟

Kingdaro هل يمكنك فتح مشكلة لذلك؟ يبدو جيدًا إذا كان ذلك ممكنًا.

@ p-adams لا يزال بإمكانك استخدام خاصية محسوبة مع Array.prototype.filter .

chrisvfritz ، بشكل أساسي

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

سأكتفي بمعرفة كيفية الوصول إليه بطريقة مناسبة.

هناك موقف آخر يكون فيه $context مفيدًا عند إعادة استخدام أحد المكونات كجذر لمكون آخر.

<template>
  <Foo>
    <child/>
  </Foo>
</template>
<script>
{ name: 'Bar' ... }
</script>

في المثال ، سيعيد child.$parent المكون Foo بدلاً من Bar ، والذي يكون si صحيحًا ولكن إذا كان الوالد والطفل يعتمدان على بعضهما البعض ، فيمكن أن يكون الاتصال المباشر بينهما من خلال السياق.

@ miljan-aleksic سأترك هذا واحد ل @ yyx990803. أود أن أقول أنه تمامًا مثل $parent ، من المحتمل أن يكون الوصول إلى $context الطريقة الخاطئة 99.9٪ من الوقت ، وأعتقد أنني ربما لن أستخدمه أبدًا.

لدي حالة مع v-show والتحولات. في هذا السيناريو ، يوجد مشروط يكون افتراضيًا "عرض: لا شيء" في CSS. عند دمجه مع v-show لن يتم عرضه أبدًا لأن التوجيه يزيل خاصية العرض ، ثم تستمر CSS. لا يمكنني تغيير CSS (متطلبات المشروع) ولا يمكنني استخدام توجيه مخصص كما يبدو أن انتقالات Vue تعتمد عليه بشكل خاص.

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

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

فشل تجميع النموذج إذا كان يحتوي على "<" (وربما أحرف أخرى حساسة لـ html) في الإصدار 2.0.0-beta7

https://jsfiddle.net/x0r59ur1/

نجح هذا في 1.0.26.

يؤدي الهروب من "<" إلى "<" إلى حل المشكلة.

GlurG من المتوقع أن يهرب "<" بشكل صحيح.

@ yyx990803 ، إذا كنت أرغب في استخدام الانتقالات في قائمة المكونات من نفس النوع والاحتفاظ بحالتها ، فكيف أفعل ذلك؟ بعد متابعة المستندات ، أرى فقط كيف تختلف المكونات.

دعنا نقول مكون Tab ونقل عناصره. لا أجد طريقة :(

<tabs>
  <transition>
    <tabs-item>Content 1</tabs-item>
    <tabs-item>Content 2</tabs-item>
    <tabs-item>Content 3</tabs-item>
  <transition>
</tabs>

@ miljan-aleksic <transition> للعنصر الفردي فقط. تحتاج <transition-group> لعناصر متعددة.

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

@ yyx990803 ، LinusBorg أقدر المساعدة ولكن الحل ليس واضحًا. أعرف كيف يتم تطبيق التحولات ، ما لا يمكنني تحديده هو كيفية keep-alive المكونات المنقولة.

لقد خلق جديد قضية من أجل الوضوح مع المثال jsfiddle على ذلك كيف يتم إنشاء المكونات في كل مرة.

@ yyx990803 ، شكرًا جزيلاً لك على تحسين ميزة البقاء على قيد الحياة ، فهي تعمل الآن كما هو متوقع.

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

@ miljan-aleksic هناك غمزة لحملة باتريون .

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

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

function mounted() {
  Vue.nextTick(() => {
    //...
  });
}

GlurG نعم ، هذا سيعمل. وبالمناسبة ، كان هذا أيضًا nessariy بـ ready'() في 1.0 في كثير من الحالات.

هل هناك أي سبب لا يمكن أن يكون هناك خطاف لهذا بغض النظر؟ أنا أيضا
عبر هذا ... حتى في الإصدار 1.0 ، ولجأ إلى أشياء مثل التكرار باستخدام raf إلى
تحقق مما إذا كان في dom ، إلخ.
في 10 أغسطس 2016 ، 6:26 مساءً ، "Thorsten Lünborg" [email protected]
كتب:

GlurG https://github.com/GlurG نعم ، هذا سيعمل. وبالمناسبة،
كان ذلك أيضًا نصاريًا بجاهز '() في 1.0 في كثير من الحالات.

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

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

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

@ miljan-aleksic آسف ، لقد حذفت تعليقي لأنني لاحظت أنه يعمل فقط مع v-show أو التوجيهات المخصصة ، ونعم ، كما قلت في حالة v-model ، يلزم إضافة مستمع إدخال / تغيير وتحديث بياناتنا يدويًا

هل من المفترض أن يتم استدعاء الخطاف الجديد activated عند تشغيل مسار يقوم بتنشيط / تركيب router-view ؟ أنا لا أرى هذا السلوك حاليا.

wprater لا ، إنها مرتبطة فقط بـ <keep-alive> ولا شيء آخر.

@ yyx990803 أنا أغلّف عرض جهاز التوجيه الخاص بي في حالة mounted ولا activated . أريد أن أتأكد من تقديم دوم.

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

هل يدعم Vue JSX عامل انتشار الكائن؟ لقد جربتها لكنها لا تعمل.

إنه كذلك و @ yyx990803 بذل الكثير من الجهد

أنا أفعل هذا <Component {...{ props } }></Component> وهو يعمل كما هو موثق.

@ blocka شكرا! اعتقدت أن اسم الخاصية props غير مطلوب 😂

@ yyx990803
خيارات components لا تدعم نوع المصفوفة ، لكنها تعمل في 1.x.

على سبيل المثال

var Parent = Vue.extend({
  name: 'parent',
  template: '<div><slot></slot></div>'
})

var Child = Vue.extend({
  name: 'child',
  template: '<span>hello</span>'
})

new Vue({
  el: '#app',

  components: [
    Parent,
    Child
  ],

  replace: false,

  template: '<parent><child></child></parent>'
})

إنها حشرة؟

@ QingWei-Li هم ببساطة لم يعدوا مدعومين بعد الآن ، لأنها لم تكن أبدًا ميزة موثقة رسميًا. السبب هو أنه مع ES2015 يمكنك فقط كتابة components: { Parent, Child } .

مجرد اقتراح صغير ،
هل هناك أي فرصة لتكرار المصفوفة العادي نستخدم v-foreach وفي النطاق نستخدم v-for .

والتي ستكون أكثر منطقية للمستخدمين القادمين من php وحتى مع .each في JQ أو foreach في JS

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

لا أعتقد أن النفقات العقلية البالغة v-for="item in items" كبيرة بما يكفي لتبرير ذلك.

مع هذا الإصدار الجديد ، أود التعامل مع هذه القضية.

لدي عنصر تقويم (يأتي من واجهة المستخدم الدلالية) ، والذي يستخدم إدخال نص كلاسيكي ، ويعرض التاريخ بتنسيق بشري (مثل "10 يوليو 2016" على سبيل المثال). مع الإصدار 1.0 ، كنت أستخدم عامل تصفية بطريقتين لتحويل هذه السلسلة إلى تاريخ مناسب ، لذا كانت بيانات الكائن جاهزة للإرسال مباشرةً. ولكن نظرًا لأن المرشحات لن تعمل بعد الآن في نموذج v ، كيف يمكنني فعل الشيء نفسه الآن في الإصدار 2.0؟

شكرا

shadowRR هل من الممكن رؤية بعض التعليمات البرمجية؟

@ p-adams بالتأكيد. ها أنت ذا.

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

Vue.filter( 'formatDate', {
        read( date ) {
            return date;
        },
        write( date ) {
            if( !date ) return null;
            return moment( date, 'D MMMM YYYY' ).format( 'YYYY-MM-DD' );
        }
    } );

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

<div class="required field">
        <label>Start date</label>
         <div class="ui calendar">
                 <div class="ui input left icon">
                      <i class="calendar icon"></i>
                      <input v-model="section.start | formatDate" type="text">
                 </div>
         </div>
</div>

أوصي بقراءة منشور @ yyx990803 هنا: https://github.com/vuejs/vue/issues/2756 حيث يناقش الفلاتر ثنائية الاتجاه على v-model . أيضًا ، قد يكون من الأفضل طرح أسئلة مثل هذا هنا: http://forum.vuejs.org/

فاتني المنشور الذي تتحدث عنه ، سأرى ذلك ، شكرًا ؛)

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

@ f15gdsy mounted يتوافق مع destroyed . لا توجد أجزاء عداد attached / detatched في 2.0 - تحتاج إلى إجراء فحص in-dom بنفسك. إذا كانت الأحداث الخاصة بك لا تهتم بـ in-dom / off-dom ، فإن mounted و beforeDestroy هي الأماكن المناسبة للقيام بذلك.

عند استخدامه على مكون مخصص ، فإن v-on الآن يستمع فقط إلى الأحداث المخصصة $ المنبعثة من هذا المكون. (لم يعد يستمع إلى أحداث DOM)

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

1.0:

<foo @click="bar"></foo>

2.0:

<div @click=bar>
  <foo></foo>
<div>

fnlctrl ، استخدم المعدل الأصلي: @click.native="bar" .

@ miljan-aleksic شكرا جزيلا لك! أعتقد أنه يجب إضافة هذا المُعدِّل إلى Directives -> v-on -> modifiers في هذه المشكلة

هل يمكنني استخدام Koa (1.x أو 2.x) كخادم؟ هل هناك أي مشكلة في vue-server-renderer مع Koa؟

@ yyx990803

import Vue from 'vue'

Vue.component('expanding', {
  functional: true,
  render (createElement, { children }) {
    const data = {
      props: {
        name: 'expanding',
      },
      on: {
        beforeEnter ($el) {
          $el.classList.add('collapse')
          console.log('beforeEnter')
        },
        enter ($el) {
          $el.classList.remove('collapse')
          $el.classList.add('collapsing')
          $el.style.height = `${$el.scrollHeight}px`
          console.log('enter')
        },
        afterEnter ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse', 'in')
          console.log('afterEnter')
        },
        beforeLeave ($el) {
          $el.classList.add('collapsing')
          $el.classList.remove('collapse', 'in')
          $el.style.height = 0
          console.log('beforeLeave')
        },
        leave ($el) {
          console.log('leave')
        },
        afterLeave ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse')
          $el.style.display = 'none'
          console.log('afterLeave')
        }
      }
    }
    return createElement('transition', data, children)
  }
})

        <a href="#" :aria-expanded="showItem ? 'true' : 'false'" @click="showItem = !showItem">
          <span class="icon is-small"><i class="fa fa-table"></i></span>
          Tables
          <span class="icon is-small is-angle"><i class="fa fa-angle-down"></i></span>
        </a>
        <expanding appear="true">
          <ul v-show="showItem">
            <li>
              <router-link to="/tables/basic">Basic</router-link>
            </li>
            <li>
              <router-link to="/tables/handsontable">Handsontable</router-link>
            </li>
          </ul>
        </expanding>

لماذا لا تستدعي خطاف الدخول؟

fundon يجب عليك طرح السؤال على المنتديات أو الدردشة المهلكة

قفل هذا الموضوع بسبب:

1. نحن الآن في وضع تجميد API في RC لذا لن يتم تحديث هذا المستند بعد الآن.
2. يستخدم الكثير من الأشخاص هذا كسلسلة أسئلة شائعة عامة ، وهذا ليس الغرض منه.

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

تحديث : للحصول على قائمة أكثر تحديدًا وتفصيلاً بالتغييرات في الإصدار 2.0 ، راجع دليل الترحيل الجديد.