Vue: HTML केस सेंसिटिविटी वर्कअराउंड

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

+
मैं अक्सर घटकों और टैग के बीच अंतर देखने के लिए इस तरह लिखना चाहता हूं

+1

क्या सभी ईवेंट नामों को लोअरकेस में सामान्य करना समझ में आता है?

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

क्या इसका मतलब यह है कि वूज एंगुलर जैसे समान दृष्टिकोण का पीछा करते हुए एचटीएमएल स्पेक से दूर जा रहे हैं?

क्या कुछ प्रदर्शन चिंता है?

संभावित चिंताओं पर कुछ विचार:

1. जब तक बैकवर्ड संगतता मौजूद है, मैं अंततः जो भी तय किया गया है, उसके साथ शांत रहूंगा, लेकिन शायद कबाब केस पद्धति का उपयोग करना जारी रखूंगा
2. ऊंट-केस और निचले ऊंट-केस के बीच अंतर की कमी कुछ के लिए भ्रमित करने वाली हो सकती है। आम तौर पर बोलना var CamelCase एक वर्ग को संदर्भित करेगा और var camelCase एक गैर-वर्ग चर, var camelCase = new CamelCase(); को संदर्भित करेगा। लेकिन, मुझे नहीं लगता कि यह कोई मुद्दा होगा, क्योंकि आप ऐसी कक्षाएं नहीं बनाना चाहेंगे जिनका नाम आपके घटकों के नाम पर रखा गया हो।
3. मैं इस बात से सहमत हूं कि केवल मामले से अलग दो अनूठी घटनाओं को बनाना बहुत खराब प्रोग्रामिंग होगा।

मेरी सबसे बड़ी चिंता अजीब विसंगतियों को पेश कर रही है कि लोग कैसे कोड करते हैं। उदाहरण के लिए, ये सभी मान्य और समान हैं: :myprop="" :myProp="" :mYpRoP="" :my-prop="" ।

मार्कअप में कबाब-केस और कोड में ऊंट केस रखें। यह एचटीएमएल स्पेक का हिस्सा है और मामले को अनदेखा करना अन्य ढांचे से आने वाले लोगों के लिए एक बड़ा सीखने की अवस्था होगी या जो पहले से ही मानक सीख चुके हैं।

मैं @Teevio से सहमत हूं, निरंतरता खो जाएगी

HTML कबाब-केस का उपयोग करता है और यह एक स्वीकृत सामुदायिक मानक है कि ईसीएमएस्क्रिप्ट एक कैमलकेस भाषा है। हमें उन्हें _hiding_ के बजाय अलग रखना चाहिए (प्रतिक्रिया में कस्टम विशेषता प्रस्तुत करने के लिए प्रतिक्रिया प्राप्त करने का एकमात्र तरीका डेटा-* और एरिया-* है, जो निरंतरता को लागू करता है)।

यह समझाते हुए कि क्यों (एमडीएन लिंक या यहां तक ​​​​कि यहां के माध्यम से कहें) कैमलकेस <-> कबाब-केस से _beginner_ की शुरुआत करने वाले की HTML समझ में बहुत मदद मिलेगी।

इवान से सहमत, पठनीयता और कोड स्थिरता अधिक महत्वपूर्ण है!
+1

मेरे लिए एचटीएमएल के अंदर कैमलकेस रखना वाकई अजीब लगेगा।

एचटीएमएल एचटीएमएल है, जेएस जेएस है

वर्तमान संस्करण ठीक है

6 महीने के लिए Vue का उपयोग करने के बाद, वह - अभी भी मुझे हर बार मिलता है :( कोई बड़ी बात नहीं है क्योंकि Vue के लिए चेतावनी इतनी अच्छी है कि मुझे पता है कि मैंने क्या किया, लेकिन मैं यहाँ इस विचार को पूरी तरह से समझ सकता हूँ, और इसका समर्थन कर सकता हूँ +1

+1 पश्चगामी संगतता भी।

+1
मैं सहमत। हमें पश्चगामी संगतता बनाए रखने की आवश्यकता है।

क्या सभी ईवेंट नामों को लोअरकेस में सामान्य करना समझ में आता है?

मैं @azamat-sharapov . से सहमत हूं

@Teevio Vue घटक मोटे तौर पर वर्ग हैं: जब आप var MyComp = Vue.extend({ .. }) करते हैं तो आप var myComp = new MyComp() कर सकते हैं। जहां तक ​​कई मान्य सिंटैक्स समस्या का सवाल है, यह पहले से मौजूद है: :my-prop , :MY-PROP और :mY-pRop सभी अभी की तरह ही काम करते हैं, क्योंकि HTML केवल सभी केस की जानकारी को फेंक देता है। यह प्रस्तावित सुविधा से बहुत अलग नहीं है। सभी शैली तर्कों की तरह, यह शैली चुनने और उसके साथ बने रहने के बारे में है।

पुन: @ Jamesxv7 @ moe-szyslak @jonagoldman और अन्य जिन्हें HTML मानक से दूर जाने की चिंता है: यह HTML में कैमलकेस टैग/विशेषताएं लिखने के लिए पूरी तरह से मान्य है, यह केवल टैग/विशेषता नाम मिलान केस-असंवेदनशील तरीके से किया जाएगा . यह वही है जो युक्ति कहती है :

HTML सिंटैक्स में दस्तावेज़ों में:

HTML तत्वों के लिए टैग नाम लोअरकेस और अपरकेस अक्षरों के किसी भी मिश्रण के साथ लिखे जा सकते हैं जो इस दस्तावेज़ के HTML तत्व अनुभाग में दिए गए तत्वों के नाम के लिए केस-असंवेदनशील मिलान हैं; अर्थात्, टैग नाम केस-संवेदी होते हैं।
HTML तत्वों के लिए विशेषता नाम लोअरकेस और अपरकेस अक्षरों के किसी भी मिश्रण के साथ लिखे जा सकते हैं जो इस दस्तावेज़ के HTML तत्व अनुभाग में दिए गए विशेषताओं के नामों के लिए केस-असंवेदनशील मिलान हैं; अर्थात्, विशेषता नाम केस-संवेदी होते हैं।

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

और विशेष रूप से, फिर से @ Jamesxv7 : यह एंगुलर 2 जो कर रहा है उससे अलग है। कोणीय 2 एक अनुकूलित HTML पार्सर पेश करके अपने टेम्पलेट्स को केस-संवेदी बना रहा है। इसके विपरीत, Vue वास्तव में JS समकक्षों को केस-असंवेदनशील बनाकर कल्पना का अनुसरण करता है।

मैं कबाब को html में रखना पसंद करता हूं। मुझे निरंतरता का विचार पसंद है लेकिन मुझे कल्पना अनुपालन का विचार अधिक पसंद है।

कैमलकेस टैग मिला:. HTML केस-असंवेदनशील है। उपयोगबजाय। जावास्क्रिप्ट में कैमलकेस आईडी के साथ परिभाषित घटकों के खिलाफ Vue स्वचालित रूप से इसका मिलान करेगा।

यह चेतावनी पहले से ही काफी संक्षिप्त है कि घटक पंजीकरण कैसे काम करता है। उस ने कहा, जैसा कि अन्य ने उल्लेख किया है, मुझे लगता है कि HTML में कैमलकेस को अनुमति देना बहुत अच्छा है, जब तक कि कबाब लिखना जारी रखने का विकल्प अभी भी है।

@ yyx990803 हाँ, सहमत हुए। मैं इसके खिलाफ जितने तर्क दे सकता था, सोचने की कोशिश कर रहा था, लेकिन ईमानदारी से मेरे पास ऐसा कोई तर्क नहीं है जो टिक सके। जैसा कि आपने उल्लेख किया है, दिन के अंत में हम शैलीगत विकल्पों पर बहस कर रहे हैं। मैं व्यक्तिगत रूप से सोचता हूं कि जब तक हम नई सामग्री का उपयोग करने का विकल्प रखते हुए हमारे पास पहले से मौजूद हैं (लेकिन मजबूर नहीं) मैं उल्लिखित परिवर्तनों से शांत हूं।

यदि कबाब-केस अभी भी काम करता है और कैमलकेस/पास्कलकेस का उपयोग करना एक विकल्प है जो बीसी को तोड़ता नहीं है, जब मैं उनका उपयोग करता हूं, तो मैं अतिरिक्त के खिलाफ नहीं हो सकता। यह कोई बदलाव नहीं है जो मुझे कुछ अलग करने के लिए मजबूर करता है। यह सिर्फ एक नया विकल्प है।

केवल एक चीज जो मैं कह सकता था या सुझाव दे सकता था वह यह सुनिश्चित करना है कि यह विकल्प अच्छी तरह से प्रलेखित है और - अच्छा काम, हमेशा की तरह इवान!

स्कॉट

हो सकता है कि हम इसमें से एक विकल्प बना सकें: चेतावनी या अनदेखी।
मान लें कि मेरे पास एक घटक है: 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 केस असंवेदनशील है, इसलिए लाइब्रेरी से केसिंग के विचार का परिचय नहीं देता है। यह कार्यान्वयन केवल एचटीएमएल में आवरण को बढ़ावा देगा, जो मेरी राय में एक बुरा विचार है।

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

अंत में: हाइपेन और केसिंग सिस्टम का सह-अस्तित्व होने से टीम में नए डेवलपर्स के लिए विभिन्न कोडिंग शैलियों को बढ़ावा मिलता है।

मुझे @paulpflug का दृष्टिकोण पसंद है; इस क्षेत्र में उचित चेतावनियाँ बहुत मदद करेंगी।

मैं HTML पास्कल/ऊंट केस बनाने का प्रशंसक नहीं हूं। यह वेब मानकों को तोड़ता है, मुझे पता है कि निरंतरता बनाए रखना अच्छा है।

चीजों को सबसे नन्हा सा सुसंगत बनाने की कोशिश करके आप जटिलता की एक और परत जोड़ते हैं। यह बुरी प्रथाओं को लुभाने वाला भी हो सकता है। एक पुस्तकालय को मानकों पर बने रहने को बढ़ावा देना चाहिए और डेवलपर्स को गुमराह नहीं करना चाहिए, क्योंकि एक दिन उन्हें Vue का उपयोग न करने वाली जगह पर काम करना पड़ सकता है, जिसके परिणामस्वरूप यह समझ में नहीं आता है कि HTML को अलग तरीके से क्यों पार्स किया जा रहा है।

मैं @paulpflug से पूरी तरह सहमत हूं: चेतावनी जोड़ने का मतलब उत्पादन कोड के लिए कम काम है और डेवलपर्स को वैध कोड लिखने के लिए वापस ट्रैक पर रखता है।

एक अच्छा तर्क यह है कि इसे क्यों लागू नहीं किया जाना चाहिए: http://eisenbergeffect.bluespire.com/on-angular-2-and-html/

यह आमतौर पर एक हाइलाइट किया गया कारण है जो लोग एंगुलर 2 को नापसंद करते हैं। मैं पुस्तकालयों को मानकों के अनुरूप रखने से पूरी तरह सहमत हूं। इसे एक बार HTML के केस सेंसिटिव होने के लिए तैयार किया गया था, और बहुत अधिक मुद्दों और बहुत अधिक लचीलेपन की स्थितियों को खोलने के कारण इसे बाहर निकाल दिया गया था।

@ ब्लेक-न्यूमैन: इसके बारे में, मुझे लगता है कि @ yyx990803 पहले से ही इसके बारे में पिछली टिप्पणी में बात कर चुके हैं।

@ Jamesxv7 वह टिप्पणी इसे बहुत अच्छी तरह बताती है; इवान एचटीएमएल स्पेक को बदलने का प्रस्ताव नहीं दे रहा है, वह यह बदलने का प्रस्ताव कर रहा है कि वीयू घटक नामों का पता कैसे लगाता है। कबाब को ऊंट में बदलने और मिलान करने वाले घटक को खोजने के बजाय यह संभवतः डैश (कबाब को समायोजित करने के लिए) को हटा देगा और फिर बिना केस संवेदनशीलता वाले घटकों को खोजेगा। HTML स्वयं विशिष्टताओं के अनुरूप बना रहेगा। यह हमें किसी भी मामले का उपयोग करने की अनुमति भी देगा जो हम चाहते हैं। ऐसा लगता है कि मेरे लिए कोई बुराई या बुरी पसंद नहीं है :)

@ yyx990803 क्या आप <MyComponent> शैली को प्रचारित शैली बनाने की योजना बनाते हैं (अर्थात दस्तावेज़ और उदाहरण इस तरह लिखे जाएंगे), या यह केवल एक विकल्प होगा, और कबाब-केस शैली प्राथमिक रहेगी?

@ ब्लेक-न्यूमैन इस टिप्पणी को पढ़ते हैं - यह मानक के अनुरूप है :)

@paulpflug @guidobouman : यदि आप vue-loader या vueify के नवीनतम संस्करणों का उपयोग कर रहे हैं तो कैमलकेस टैग और विशेषताओं के लिए पहले से ही चेतावनियां हैं। हालाँकि, कैमलकेस की जाँच संकलन समय पर की जानी चाहिए क्योंकि रनटाइम के दौरान HTML पार्सर व्यवहार के कारण मामले की जानकारी पहले ही खो गई होगी। इसलिए यदि आप vue-loader या vueify के बिना Vue का उपयोग कर रहे हैं, तो कोई चेतावनी नहीं होगी (और नहीं हो सकती)।

@ yyx990803 - लेकिन, वेब घटकों के लिए लिंक @ ब्लेक-न्यूमैन की कल्पना यह बताती है:

कस्टम तत्व प्रकार एक कस्टम तत्व इंटरफ़ेस की पहचान करता है और वर्णों का एक क्रम है जो NCName उत्पादन से मेल खाना चाहिए, इसमें एक _U+002D HYPHEN-MINUS वर्ण_ होना चाहिए, और _कोई अपरकेस ASCII अक्षर नहीं होना चाहिए_ ।

मुझे यकीन नहीं है कि यह Vue घटकों से कैसे संबंधित है। डॉक्स में, आप कहते हैं, आप वेब घटकों के मानक का शिथिल पालन करने का प्रयास करते हैं।

आपने देखा होगा कि Vue.js घटक बहुत हद तक कस्टम तत्वों से मिलते-जुलते हैं, जो वेब घटक युक्ति का हिस्सा है। वास्तव में, Vue.js के घटक सिंटैक्स को कल्पना के बाद शिथिल रूप से तैयार किया गया है।

इसलिए, मैं कहूंगा कि कैमलकेस और पास्कलकेस को अनुमति देने के लिए पहले कल्पना को बदलने की जरूरत है।

स्कॉट

@smolinari Vue डॉक्स का कहना है कि यह 'ढीले ढंग से तैयार किया गया' है न कि 'कड़ाई से' और मेरे दिमाग में जो इस बदलाव के लिए जगह छोड़ता है।

@yyx990803 मामले की जानकारी खो सकती है, लेकिन फिर भी एक चेतावनी हो सकती है।
जब मैंने टेम्पलेट में 'mycOmponent' लिखा था तो इसे mycomponent पर पार्स किया जाएगा, लेकिन अपेक्षित my-component है तो Vue (डीबग मोड में) को $#$3$ के अलावा my-component mycomponent की तलाश करनी चाहिए my-component और मुझे गलत उपयोग के बारे में चेतावनी दें। गुम हुए मामले की जानकारी यहां कोई मायने नहीं रखती।
इसके बजाय चेतावनी को दबाने और सीधे मिलान करने का विकल्प हो सकता है (आपके सुझाए गए व्यवहार के बराबर)।

-1 कैमलकेस/पास्कलकेस में माइग्रेट करने के लिए। एचटीएमएल में जेएस-जैसे सिंटैक्स को देखना कुछ हद तक परेशान करने वाला होगा। यही कारण है कि मैं जेएसएक्स खड़ा नहीं कर सकता।
+1 से @paulpflug का सुझाव। यदि समस्या शुरुआती लोगों को शामिल करने की है, तो क्यों न केवल एक चेतावनी जारी की जाए जो उपयोगकर्ता को समस्या के बारे में सूचित करे?

@paulpflug जो एक वैध विचार की तरह लगता है!

मैं सहमत हूं, एक चेतावनी है जो कहती है कि 'mycomponent' is missing, did you mean 'my-component'? मूक प्रतिस्थापन से बेहतर लगता है।

@ yyx990803 क्या वैश्विक विकल्प एपीआई पर ऐसा करना संभव है?
जैसे
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()"> अजीब लग रहा है।

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

तो आईएमओ, हमें बेहतर की तलाश करने के बजाय सिर्फ मौजूदा सम्मेलनों का समर्थन करना चाहिए। और निश्चित रूप से, शुरुआती लोगों की मदद करने के लिए चेतावनी का उपयोग करें

@ प्रोग-राजकमल हाँ, अब मैं केवल चेतावनी को लागू करने के इच्छुक हूं।

मैं अब वोट देता हूं: +1: केवल चेतावनी जोड़ने पर भी।

स्कॉट

:+1: चेतावनी जोड़ने के लिए

:+1: चेतावनी के लिए भी

ccf9bede6bc39fb62e43e1efe98136c5f35dae6b और d7b55c4ee8491dbd853e28a1527050d2d1e7deab के माध्यम से बंद

एक चेतावनी बहुत अच्छी होगी। मैंने यह पता लगाने की कोशिश में सिर्फ एक घंटा बिताया कि मेरे कस्टम इवेंट का जवाब क्यों नहीं दिया गया (इसका जवाब ऊंट का नाम था)।

जब आपके पास एक संगत घटक या प्रॉप होता है तो एक चेतावनी होती है जो आपके PascalCase घटक या प्रोप के kebab-case संस्करण का जवाब देगी। यदि आप किसी ईवेंट में टाइपो बनाते हैं तो Vue उसके बारे में बहुत कुछ नहीं कर सकता है।

या क्या आपका मतलब डिफ़ॉल्ट मौजूदा ईवेंट प्रोप जैसे v-on:keyup या @keyup संक्षेप में है?

मेरी टेम्पलेट फ़ाइल में @guidobouman मेरे पास <my-component v-on:customEvent="myMethod"> था। एक बच्चे के घटक में मेरे पास this.$emit('customEvent'); था। माता-पिता द्वारा सुनी जा रही वास्तविक घटना customevent नहीं customEvent है, लेकिन मुझे यह पता लगाने में उम्र लग गई क्योंकि डीबग करना आसान नहीं है। मैं सोच रहा था कि यह चेतावनी देना अच्छा होता कि मेरे जैसे भुलक्कड़ लोगों के लिए ऊंट केस विशेषता को इस तरह से पार्स नहीं किया जाएगा। शायद इस पर पहले ही ऊपर चर्चा की जा चुकी है, और यदि ऐसा है तो मैं क्षमा चाहता हूँ।

@anthonygore दुर्भाग्य से यह असंभव है, क्योंकि Vue को इसे एक्सेस करने का मौका मिलने से पहले ब्राउज़र html को लोअरकेस में बदल देता है।

मेरा सवाल यह है कि Vue इसे हमारे लिए क्यों नहीं बदल सकता है? हमें कबाब-केस के बारे में क्यों याद रखना है

स्मृति को प्रतिबद्ध करने का एक नियम: HTML = kebab-case, JavaScript = camelCase

HTML से मेरा मतलब है विशेषताएँ और टैग। विशेषता मान जावास्क्रिप्ट अभिव्यक्ति हैं जब आप v-bind का उपयोग करते हैं, इसलिए दूसरा कथन लागू होता है।

मेरा सवाल यह है कि Vue इसे हमारे लिए क्यों नहीं बदल सकता है? हमें कबाब-केस के बारे में Vue फाइलों में क्यों याद रखना चाहिए? यह शुरुआती लोगों के लिए चीजों को और अधिक अजीब बनाता है ... मैंने उसके लिए पिछले 20 मिनट बर्बाद किए ...

पिछले 1.5 घंटे बर्बाद कर दिया क्योंकि मैंने इसे सिर्फ Google नहीं किया था ... dxmn