Vue: الحل البديل لحساسية حالة HTML

<MyComponent :myProp="msg"></MyComponent>

+
غالبًا ما أرغب في الكتابة بهذه الطريقة لمعرفة الفرق بين المكونات والعلامات

+1

هل يعقل تطبيع جميع أسماء الأحداث إلى أحرف صغيرة؟

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

هل هذا يعني أن Vuejs ستبتعد عن مواصفات HTML متبعة نهجًا مشابهًا مثل Angular ؟

هل هناك بعض القلق بشأن الأداء؟

بعض الأفكار حول المخاوف المحتملة:

1. ما دام التوافق مع الإصدارات السابقة موجودًا ، سأكون رائعًا مع كل ما يتم تحديده في النهاية ، ولكن من المحتمل أن أستمر في استخدام طريقة علبة الكباب
2. قد يكون عدم التمييز بين حالة الجمل وحالة الإبل السفلية مربكًا للبعض. بشكل عام ، يشير var CamelCase إلى فئة و var camelCase يشير إلى متغير غير فئة ، var camelCase = new CamelCase(); . لكن ، لا أعتقد أن هذه ستكون مشكلة ، لأنك لا تريد إنشاء فئات تمت تسميتها على اسم المكونات الخاصة بك.
3. أوافق على أن إنشاء حدثين فريدين مميزين فقط من خلال الحالة سيكون برمجة سيئة للغاية.

أكثر ما يقلقني هو تقديم تناقضات غريبة مع كيفية برمجة الأشخاص. على سبيل المثال ، كل هذه العناصر صالحة ومتطابقة: :myprop="" :myProp="" :mYpRoP="" :my-prop="" .

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

أتفق مع Teevio ، سيضيع التناسق

يستخدم HTML حالة الكباب وهو معيار مجتمع مقبول أن ECMAScript هي لغة حالة الجمل. يجب أن نبقيهم منفصلين بدلاً من إخفاء_ (في رد الفعل ، الطريقة الوحيدة التي يمكنك من خلالها التفاعل لتقديم السمة المخصصة هي عبر data- * & aria- * ، التي تفرض الاتساق).

إن شرح سبب (قل عبر رابط MDN أو حتى هنا) camelCase <-> kebab-case إلى _beginner_ سيساعد بشكل كبير على فهم HTML للمبتدئين.

اتفق مع إيفان ، فإن سهولة القراءة واتساق الكود أكثر أهمية!
+1

بالنسبة لي ، سيبدو غريبًا حقًا أن يكون لديك إطار جمل داخل HTML.

HTML هي HTML ، JS هي JS

الإصدار الحالي على ما يرام

بعد أن كنت أستخدم Vue لمدة 6 أشهر ، هذا - لا يزال يجذبني في كل مرة :( ليست مشكلة كبيرة لأن التحذير لـ Vue جيد جدًا ، فأنا أعرف ما فعلته ، لكن يمكنني فهم الفكرة تمامًا هنا ، ودعمها +1

+1 التوافق مع الإصدارات السابقة أيضًا.

+1
قد وافقت. نحن بحاجة إلى الحفاظ على التوافق مع الإصدارات السابقة.

هل يعقل تطبيع جميع أسماء الأحداث إلى أحرف صغيرة؟

أتفق مع @ azamat-sharapov

مكونات Teevio Vue عبارة عن فئات تقريبًا: عندما تفعل var MyComp = Vue.extend({ .. }) يمكنك حينها القيام بـ var myComp = new MyComp() . بالنسبة لمشكلة بناء الجملة المتعددة الصالحة ، فهي موجودة بالفعل: :my-prop ، :MY-PROP و :mY-pRop تعمل جميعها بنفس الطريقة الآن ، لأن HTML يتخلص ببساطة من جميع معلومات الحالة. لا يختلف الأمر كثيرًا عن الميزة المقترحة. كما هو الحال مع جميع الحجج المتعلقة بالأسلوب ، فإن الأمر كله يتعلق باختيار نمط والتشبث به.

Re @ jamesxv7 @ moe- szyslakjonagoldman والآخرين الذين لديهم مخاوف بشأن الابتعاد عن معيار HTML: من الصحيح تمامًا كتابة علامات / سمات حالة الجمل في HTML ، إنها مجرد مطابقة اسم العلامة / السمة سيتم إجراؤها بطريقة غير حساسة لحالة الأحرف . هذا ما تقوله المواصفات :

في المستندات بصيغة HTML:

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

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

وعلى وجه الخصوص ، re @ jamesxv7 : هذا يختلف عما يفعله Angular 2. Angular 2 تجعل قوالبها حساسة لحالة الأحرف من خلال تقديم محلل HTML مخصص. على العكس من ذلك ، تتبع Vue المواصفات بجعل نظرائها في JS غير حساسين لحالة الأحرف.

أفضل الاحتفاظ بالكباب بصيغة html. تعجبني فكرة الاتساق ولكني أحب فكرة الامتثال للمواصفات أكثر.

تم العثور على علامة حالة الجمل:. HTML غير حساس لحالة الأحرف. يستخدمبدلا من. سيطابقها Vue تلقائيًا مع المكونات المحددة بمعرفات camelCase في JavaScript.

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

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

إذا كان kebab-case لا يزال يعمل وكان استخدام camelCase / PascalCase خيارًا لا يكسر BC ، فعند استخدامه ، لا يمكنني أن أعارض الإضافة. إنه ليس تغييرًا يجبرني على القيام بشيء مختلف. إنه مجرد خيار جديد.

الشيء الوحيد الذي يمكنني قوله أو اقتراحه هو التأكد من أن هذا الخيار موثق جيدًا و- عمل جيد ، كما هو الحال دائمًا إيفان!

سكوت

ربما يمكننا أن نجعل منه خيارًا: التحذير أو التجاهل.
لنفترض أن لدي مكوّنًا: myComponent
وأنا أشير إليه في html كـ mycompOnent أنا شخصياً أفضل تحذير ، مثل:
we found something that would match "myComponent": "mycompOnent" (line 152), use "my-component" instead
الشيء نفسه بالنسبة للدعائم بالطبع.
أعتقد أن القراءة اللاحقة أكثر أهمية من العمل في المحاولة الأولى.

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

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

ماذا عن أشياء مثل atone مقابل a-tone مقابل at-one ؟ أتخيل أنها نادرة الحدوث بالرغم من ذلك.

ستظل دعائم علبة الكباب simplesmiler متوافقة مع حساسية حالة الأحرف باستخدام القواعد القديمة.

هذا لا يعزز الشفافية لمعايير الويب. تنص مواصفات العناصر المخصصة على أن الأسماء يجب أن تحتوي على واصلة: <my-component/>

ماذا عن ما قاله simplesmiler : addOne و adDone سينفّذان الكود نفسه. سيكون هذا سيئًا بشكل خاص عند تنفيذ الأحداث ،

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

أيضا ، نحن نستخدم الواصلة الفاصلة في أسماء الملفات. هل يجب إزالتها هناك أيضًا ، والبدء في إضافة الغلاف؟

أخيرًا: وجود نظام hypen & casing يعمل معًا يعزز أنماط تشفير مختلفة للمطورين الجدد في الفريق.

أنا أفضل نهج paulpflug ؛ من شأن التحذيرات المناسبة في هذا المجال أن تساعد كثيرًا.

لست من محبي صنع حافظة HTML Pascal / Camel. إنه يكسر معايير الويب ، وأنا أعلم أنه من الجيد الحفاظ على الاتساق.

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

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

حجة جيدة حول سبب عدم تنفيذ ذلك: http://eisenbergeffect.bluespire.com/on-angular-2-and-html/

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

@ blake-newman: فيما يتعلق بهذا ، أعتقد أن @ yyx990803 تحدث بالفعل عنها في تعليق سابق.

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

@ yyx990803 هل تخطط للنمط <MyComponent> ليكون النمط الذي تمت ترقيته (على سبيل المثال ، سيتم كتابة المستندات والأمثلة بهذا الشكل) ، أم سيكون مجرد خيار ، وسيظل نمط حالة الكباب هو النمط الأساسي؟

@ blake-newman تقرأ هذا التعليق - إنه يتوافق مع المعيار :)

paulpflugguidobouman : توجد بالفعل تحذيرات لعلامات وسمات حالة الجمل إذا كنت تستخدم أحدث إصدارات vue-loader أو vueify . ومع ذلك ، يجب إجراء فحوصات حالة الجمل في وقت الترجمة لأنه في وقت التشغيل ، قد تكون معلومات الحالة قد ضاعت بالفعل بسبب سلوك محلل HTML. لذلك إذا كنت تستخدم Vue بدون vue-loader أو vueify ، فلن تكون هناك (ولا يمكن) وجود أي تحذيرات.

@ yyx990803 - لكن المواصفات @ blake-newman المرتبطة بمكونات الويب توضح هذا:

يحدد نوع العنصر المخصص واجهة عنصر مخصص وهو عبارة عن سلسلة من الأحرف التي يجب أن تتطابق مع إنتاج NCName ، ويجب أن يحتوي على حرف _U + 002D HYPHEN- MINUS_ ، ويجب ألا يحتوي على أي أحرف ASCII كبيرة_ .

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

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

لذا ، أقول إن المواصفات يجب أن تتغير أولاً ، للسماح بإصدار camelCase و PascalCase.

سكوت

smolinari ، تقول مستندات Vue إنه "مصمم بشكل فضفاض" وليس "صارمًا" وفي رأيي يترك مجالًا لهذا التغيير.

@ yyx990803 قد يتم فقد معلومات الحالة ، ولكن لا يزال هناك تحذير.
عندما كتبت "mycOmponent" في القالب ، سيتم تحليله إلى mycomponent لكن من المتوقع أن يكون my-component ثم Vue (في وضع التصحيح) يجب أن يبحث عن mycomponent بجانب my-component وحذرني من الاستخدام الخاطئ. معلومات الحالة المفقودة لا تهم هنا.
قد يكون هناك خيار لإلغاء التحذير والمطابقة مباشرة بدلاً من ذلك (يساوي سلوكك المقترح).

-1 للهجرة إلى camelCase / PascalCase. سيكون من التناقض إلى حد ما رؤية صيغة تشبه JS في HTML. نفس السبب الذي يجعلني لا أتحمل jsx.
+1 لاقتراحpaulpflug . إذا كانت المشكلة تتعلق بإعداد المبتدئين ، فلماذا لا نصدر تحذيرًا يُعلم المستخدم بالمشكلة؟

paulpflug التي تبدو فكرة صحيحة!

أوافق ، مع وجود تحذير يقول 'mycomponent' is missing, did you mean 'my-component'? يبدو أفضل من الاستبدال الصامت.

@ yyx990803 هل من الممكن القيام بذلك على خيار API عالمي؟
على سبيل المثال
Vue.config.kebab = true (افتراضيًا) -> <my-component :my-prop="msg"></my-component>
Vue.config.kebab = false -> <MyComponent :myProp="msg"></MyComponent>

@ yyx990803
فقط أتساءل ما هو النموذج المثالي الذي نسعى إليه؟
كما قال rpkilby ، يبدو <MyComponent myCustomProp="myProp" data-name="prop" aria-label="Close" onclick="myDialog.close()"> غريبًا.

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

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

@ prog-rajkamal نعم ، أنا الآن أميل إلى مجرد تنفيذ التحذير.

أنا أصوت الآن: +1: بمجرد إضافة التحذير أيضًا.

سكوت

: +1: لإضافة تحذير

: +1: للتحذير أيضا

مغلق عبر ccf9bede6bc39fb62e43e1efe98136c5f35dae6b & d7b55c4ee8491dbd853e28a1527050d2d1e7deab

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

هناك تحذير عندما يكون لديك مكون أو خاصية مقابلة من شأنها أن تستجيب لإصدار kebab-case PascalCase لمكون أو خاصية $ # $ 1 $ # $ الخاصة بك. إذا قمت بخطأ إملائي في حدث ما ، فليس هناك الكثير مما يمكن لـ Vue فعله حيال ذلك.

أو هل تقصد بدعائم الأحداث الافتراضية الموجودة مثل v-on:keyup أو @keyup باختصار؟

guidobouman في ملف القالب الخاص بي كان لدي <my-component v-on:customEvent="myMethod"> . في المكون الفرعي ، كان لدي this.$emit('customEvent'); . الحدث الفعلي الذي يستمع إليه الوالد هو customevent وليس customEvent ، بالطبع ، لكن الأمر استغرق مني الأعمار لمعرفة ذلك لأنه ليس من السهل تصحيحه. كنت أفكر أنه سيكون من الجيد التحذير من أن سمة حالة الجمل لن يتم تحليلها على هذا النحو ، بالنسبة للقوم النسيان مثلي. ربما سبق أن نوقش هذا أعلاه ، وإذا كان الأمر كذلك فأنا أعتذر.

anthonygore للأسف هذا مستحيل ، لأن المتصفح يحول html إلى أحرف صغيرة قبل أن تتاح لـ Vue فرصة الوصول إليه.

سؤالي هو ، لماذا لا تستطيع Vue تحويلها لنا؟ لماذا علينا أن نتذكر حالة الكباب في

القاعدة الوحيدة للالتزام بالذاكرة: HTML = kebab-case, JavaScript = camelCase

أعني بـ HTML السمات والعلامات. قيم السمات هي تعبيرات JavaScript عند استخدام v-bind ، لذلك يتم تطبيق العبارة الثانية.

سؤالي هو ، لماذا لا تستطيع Vue تحويلها لنا؟ لماذا علينا أن نتذكر حالة الكباب في ملفات vue؟ إنه يجعل الأمور أكثر صعوبة بالنسبة للمبتدئين ... لقد أهدرت 20 دقيقة فقط من أجل ذلك ...

ضاع آخر 1.5 ساعة لأنني لم أجربها فقط ... dxmn