Vue: Solusi sensitivitas huruf besar-kecil HTML

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

+
Saya sering ingin menulis seperti itu untuk melihat perbedaan antara komponen dan tag

+1

Apakah masuk akal untuk menormalkan semua nama acara menjadi huruf kecil?

Ya! Masuk akal, karena membuat kode lebih mudah dibaca. Saya selalu menyimpan nama acara dengan huruf kecil, memisahkannya dengan tanda hubung, bukan camelcase. Saya pikir menambahkan peringatan untuk nama acara camelcase juga bagus.

Apakah ini berarti bahwa Vuejs akan menjauh dari spesifikasi HTML dengan pendekatan serupa seperti Angular ?

Apakah ada masalah kinerja?

Beberapa pemikiran tentang potensi masalah:

1. Selama kompatibilitas mundur ada, saya akan tenang dengan apa pun yang akhirnya diputuskan, tetapi mungkin akan terus menggunakan metode kasus kebab
2. Kurangnya perbedaan antara kotak unta dan kotak unta yang lebih rendah dapat membingungkan bagi sebagian orang. Secara umum var CamelCase akan merujuk ke kelas dan var camelCase akan merujuk ke variabel non-kelas, var camelCase = new CamelCase(); . Tapi, saya tidak berpikir ini akan menjadi masalah, karena Anda tidak ingin membuat kelas yang dinamai sesuai komponen Anda.
3. Saya setuju bahwa membuat dua acara unik yang hanya dibedakan oleh kasingnya akan menjadi pemrograman yang sangat buruk.

Kekhawatiran terbesar saya adalah memperkenalkan inkonsistensi aneh dengan cara orang membuat kode. Misalnya, semua ini valid dan identik: :myprop="" :myProp="" :mYpRoP="" :my-prop="" .

Simpan kotak kebab di markup dan kotak unta di kode. Ini adalah bagian dari spesifikasi HTML dan mengabaikan kasus akan menjadi kurva pembelajaran yang lebih besar bagi mereka yang berasal dari kerangka kerja lain atau yang telah mempelajari standar.

Saya setuju dengan @Teevio , konsistensi akan hilang

HTML menggunakan kebab-case & merupakan standar komunitas yang diterima bahwa ECMAScript adalah bahasa camelCase. Kita harus memisahkan mereka daripada _hiding_ (Dalam reaksi satu-satunya cara Anda bisa mendapatkan reaksi untuk membuat atribut khusus adalah melalui data-* & aria-*, yang menegakkan konsistensi).

Menjelaskan mengapa (katakanlah melalui tautan MDN atau bahkan di sini) camelCase <-> kebab-case ke _beginner_ akan sangat membantu pemahaman HTML pemula.

Setuju dengan Evan, keterbacaan dan konsistensi kode lebih penting!
+1

Bagi saya akan terlihat sangat aneh memiliki camelCase di dalam HTML.

HTML adalah HTML, JS adalah JS

versi saat ini baik-baik saja

Setelah menggunakan Vue selama 6 bulan, itu - masih membuat saya setiap saat :( bukan masalah besar karena peringatan untuk Vue sangat bagus, saya tahu apa yang saya lakukan, tetapi saya dapat sepenuhnya memahami idenya di sini, dan mendukungnya +1

+1 Kompatibilitas mundur juga.

+1
Saya setuju. kita perlu menjaga kompatibilitas ke belakang.

Apakah masuk akal untuk menormalkan semua nama acara menjadi huruf kecil?

Saya setuju dengan @azamat-sharapov

@Teevio Vue komponen kira-kira kelas: ketika Anda melakukan var MyComp = Vue.extend({ .. }) Anda kemudian dapat melakukan var myComp = new MyComp() . Adapun beberapa masalah sintaks yang valid, sudah ada: :my-prop , :MY-PROP dan :mY-pRop semuanya berfungsi sama seperti sekarang, karena HTML hanya membuang semua informasi kasus. Tidak jauh berbeda dengan fitur yang ditawarkan. Seperti semua argumen gaya, ini semua tentang memilih gaya dan mematuhinya.

Re @jamesxv7 @moe-szyslak @jonagoldman dan lainnya yang memiliki kekhawatiran tentang pindah dari standar HTML: benar-benar valid untuk menulis tag/atribut camelCase dalam HTML, hanya saja pencocokan nama tag/atribut akan dilakukan dengan cara yang tidak peka huruf besar/kecil . Inilah yang dikatakan spek :

Dalam dokumen dalam sintaks HTML:

Nama tag untuk elemen HTML dapat ditulis dengan campuran huruf kecil dan huruf besar apa pun yang tidak peka huruf besar/kecil untuk nama elemen yang diberikan di bagian elemen HTML dokumen ini; yaitu, nama tag tidak peka huruf besar/kecil.
Nama atribut untuk elemen HTML dapat ditulis dengan campuran huruf kecil dan huruf besar apa pun yang tidak peka huruf besar/kecil untuk nama atribut yang diberikan di bagian elemen HTML dokumen ini; yaitu, nama atribut tidak peka huruf besar/kecil.

Jadi, jika menggunakan PascalCase/camelCase meningkatkan konsistensi/keterbacaan kode, itu benar-benar sesuai spesifikasi untuk melakukannya. Ini mungkin tidak untuk semua orang, tetapi jika Anda lebih suka kotak kebab, Anda dapat terus menggunakannya.

Dan khususnya, re @jamesxv7 : ini berbeda dari apa yang dilakukan Angular 2 . Angular 2 membuat template mereka peka huruf besar/kecil dengan memperkenalkan parser HTML yang disesuaikan. Sebaliknya, Vue sebenarnya mengikuti spesifikasi dengan membuat rekan-rekan JS tidak peka huruf besar-kecil.

Saya lebih suka menyimpan kebab dalam html. Saya menyukai ide konsistensi tetapi saya lebih menyukai ide kepatuhan spesifikasi.

Ditemukan tag camelCase:. HTML tidak peka huruf besar/kecil. Menggunakansebagai gantinya. Vue akan secara otomatis mencocokkannya dengan komponen yang ditentukan dengan id camelCase di JavaScript.

Peringatan ini sudah cukup ringkas tentang cara kerja registrasi komponen. Yang mengatakan, seperti yang telah disebutkan orang lain, saya pikir mengizinkan camelCase dalam HTML itu bagus, selama masih ada opsi untuk melanjutkan menulis kebab.

@yyx990803 yah, setuju. Hanya mencoba untuk memikirkan sebanyak mungkin argumen yang menentangnya, tapi sejujurnya saya tidak punya argumen yang bisa bertahan. Seperti yang Anda sebutkan, pada akhirnya kami memperdebatkan pilihan gaya. Saya pribadi berpikir bahwa selama kita dapat bertahan dengan apa yang sudah kita miliki sambil memiliki pilihan untuk menggunakan barang-barang baru (tetapi tidak dipaksa), saya tidak masalah dengan perubahan yang disebutkan.

Jika kebab-case masih berfungsi dan menggunakan camelCase/ PascalCase adalah opsi yang tidak merusak SM, ketika saya menggunakannya, maka saya tidak dapat menentang penambahan tersebut. Bukan perubahan yang memaksa saya untuk melakukan sesuatu yang berbeda. Itu hanya opsi baru.

Satu-satunya hal yang bisa saya katakan atau sarankan adalah memastikan opsi ini didokumentasikan dengan baik dan - Kerja bagus, seperti biasa Evan!

skot

Mungkin kita bisa membuat opsi untuk itu: memperingatkan atau mengabaikan.
Katakanlah saya memiliki komponen: myComponent
dan saya menyebutnya di html sebagai mycompOnent Saya pribadi lebih suka peringatan, seperti:
we found something that would match "myComponent": "mycompOnent" (line 152), use "my-component" instead
Hal yang sama untuk alat peraga tentu saja.
Saya pikir kemampuan membaca nanti lebih penting daripada hal yang bekerja pada percobaan pertama.

Saya juga menemukan masalah kebab-case/camelCase. Tetapi masalah sebenarnya adalah saya tidak mendapat peringatan apa yang salah;)

Defaultnya bisa jadi tidak ada peringatan dan itu hanya berfungsi, itu tidak relevan bagi saya.
Juga peringatan seharusnya hanya terlihat dalam mode debug, saya pikir

Bagaimana dengan hal-hal seperti atone vs a-tone vs at-one ? Saya membayangkan mereka adalah kejadian yang cukup langka.

@simplesmiler kebab case props masih akan dicocokkan dengan case-sensitivity menggunakan aturan lama.

Ini tidak mempromosikan transparansi ke standar web. Spesifikasi elemen kustom menyatakan bahwa nama harus berisi tanda hubung: <my-component/>

Bagaimana dengan apa yang @simplesmiler katakan: addOne dan adDone akan mengeksekusi kode yang sama. Ini akan sangat buruk untuk implementasi untuk acara,

Dan karena html tidak peka huruf besar/kecil, mari kita tidak memperkenalkan ide casing dari perpustakaan. Implementasi ini hanya akan mempromosikan casing dalam html, yang menurut saya adalah ide yang buruk.

Juga, kami menggunakan pemisahan tanda hubung dalam nama file. Haruskah kita menghapusnya di sana juga, dan mulai menambahkan casing?

Terakhir: memiliki sistem hypen & casing yang berdampingan mempromosikan gaya pengkodean yang berbeda untuk pengembang baru dalam sebuah tim.

Saya lebih suka pendekatan @paulpflug ; Peringatan yang tepat di area ini akan banyak membantu.

Saya bukan penggemar membuat kasus HTML Pascal/Camel. Itu melanggar standar web, saya tahu menjaga konsistensi itu bagus.

Dengan mencoba membuat hal-hal menjadi sedikit konsisten, Anda menambahkan lapisan kerumitan lainnya. Ini mungkin juga menarik praktik buruk. Sebuah perpustakaan harus mempromosikan tetap pada standar dan tidak menyesatkan pengembang, karena suatu hari mereka mungkin harus bekerja di tempat yang tidak menggunakan Vue, sehingga tidak memahami mengapa HTML diuraikan secara berbeda.

Saya sepenuhnya setuju dengan @paulpflug : Menambahkan peringatan berarti lebih sedikit pekerjaan untuk kode produksi dan membuat pengembang kembali ke jalur untuk menulis kode yang valid.

Kasus argumen yang bagus tentang mengapa ini tidak boleh diterapkan: http://eisenbergeffect.bluespire.com/on-angular-2-and-html/

Ini biasanya merupakan alasan utama mengapa orang tidak menyukai Angular 2. Saya setuju sepenuhnya dengan menjaga perpustakaan agar sesuai dengan standar. Itu pernah dirancang agar HTML peka terhadap huruf besar-kecil, dan dibuang karena terlalu banyak masalah dan membuka situasi dengan terlalu banyak fleksibilitas.

@blake-newman: Mengenai ini , saya pikir @yyx990803 sudah membicarakannya di komentar sebelumnya.

@jamesxv7 Komentar itu merangkumnya dengan cukup baik; Evan tidak mengusulkan perubahan spesifikasi HTML, dia mengusulkan mengubah cara Vue menempatkan nama komponen. Daripada mengonversi kebab menjadi unta dan menemukan komponen yang cocok, itu mungkin akan menghapus tanda hubung (untuk mengakomodasi kebab) dan kemudian mencari komponen tanpa sensitivitas huruf besar/kecil. HTML itu sendiri akan terus sesuai spesifikasi. Itu juga akan memungkinkan kita untuk menggunakan kasing apa pun yang kita inginkan. Ini sepertinya bukan pilihan yang jahat atau buruk bagi saya :)

@yyx990803 apakah Anda merencanakan gaya <MyComponent> menjadi gaya yang dipromosikan (yaitu dokumen dan contoh akan ditulis seperti ini), atau itu hanya pilihan, dan gaya kotak kebab akan tetap menjadi yang utama?

@blake-newman baca komentar ini - itu sesuai dengan standar :)

@paulpflug @guidobouman : sudah ada peringatan untuk tag dan atribut camelCase jika Anda menggunakan versi terbaru vue-loader atau vueify . Namun, pemeriksaan camelCase harus dilakukan pada waktu kompilasi karena pada saat runtime informasi kasus sudah hilang karena perilaku parser HTML. Jadi jika Anda menggunakan Vue tanpa vue-loader atau vueify , tidak akan (dan tidak bisa) ada peringatan.

@yyx990803 - Tapi, spesifikasi @blake-newman yang ditautkan untuk komponen web menyatakan ini:

Jenis elemen kustom mengidentifikasi antarmuka elemen kustom dan merupakan urutan karakter yang harus cocok dengan produksi NCName, harus berisi _U+002D karakter HYPHEN- MINUS_, dan _tidak boleh mengandung huruf besar ASCII_ .

Saya hanya tidak terlalu yakin bagaimana hubungannya dengan komponen Vue. Dalam dokumen, Anda mengatakan, Anda mencoba untuk secara longgar mengikuti standar komponen web.

Anda mungkin telah memperhatikan bahwa komponen Vue.js sangat mirip dengan Elemen Kustom, yang merupakan bagian dari Spesifikasi Komponen Web. Faktanya, sintaks komponen Vue.js secara longgar dimodelkan setelah spesifikasi.

Jadi, menurut saya spesifikasinya perlu diubah terlebih dahulu, untuk mengizinkan camelCase dan PascalCase.

skot

@smolinari , dokumen Vue mengatakan bahwa itu 'dimodelkan secara longgar' bukan 'ketat' dan dalam pikiran saya itu menyisakan ruang untuk perubahan ini.

@yyx990803 informasi kasus mungkin hilang, tapi mungkin masih ada peringatan.
Ketika saya menulis 'mycOmponent' di template, itu akan diuraikan menjadi mycomponent tetapi yang diharapkan adalah my-component maka Vue (dalam mode debug) harus mencari mycomponent selain my-component dan peringatkan saya tentang penggunaan yang salah. Informasi kasus yang hilang tidak penting di sini.
Mungkin ada opsi untuk menekan peringatan dan mencocokkan secara langsung (sama dengan perilaku yang Anda sarankan).

-1 untuk bermigrasi ke camelCase/PascalCase. Akan agak menggelegar untuk melihat sintaks seperti JS dalam HTML. Alasan yang sama mengapa saya tidak tahan jsx.
+1 untuk saran @paulpflug . Jika masalahnya adalah orientasi pemula, mengapa tidak mengeluarkan peringatan yang memberi tahu pengguna tentang masalah tersebut?

@paulpflug kedengarannya seperti ide yang valid!

Saya setuju, memiliki peringatan yang mengatakan 'mycomponent' is missing, did you mean 'my-component'? terasa lebih baik daripada substitusi diam.

@yyx990803 Apakah mungkin melakukan ini pada api opsi global?
misalnya
Vue.config.kebab = true (secara default) -> <my-component :my-prop="msg"></my-component>
Vue.config.kebab = false -> <MyComponent :myProp="msg"></MyComponent>

@yyx990803
hanya bertanya-tanya, apa ideal yang kita perjuangkan?
seperti yang dikatakan @rpkilby , <MyComponent myCustomProp="myProp" data-name="prop" aria-label="Close" onclick="myDialog.close()"> terlihat aneh.

Pada dasarnya, masalahnya ada karena js dan html adalah teknologi yang berbeda dan menggunakan sistem penamaan yang berbeda. Dan menggunakan kasus yang sama (kebab atau unta) di kedua teknologi akan menggeser keanehan dari satu tempat ke tempat lain tetapi masalah mendasar akan tetap ada
Jadi saya percaya, yang terbaik yang bisa kita lakukan adalah menarik garis. dan baris saat ini i,e. kasus kebab dalam konteks html dan camleCase (dan PascalCase) dalam konteks js sangat baik .

jadi IMO, kita hanya harus mendukung konvensi saat ini daripada mencari yang lebih baik. Dan tentu saja, gunakan peringatan untuk membantu pemula

@prog-rajkamal ya, saya sekarang cenderung hanya menerapkan peringatan.

Saya sekarang memilih :+1: hanya menambahkan peringatan juga.

skot

:+1: untuk menambahkan peringatan

:+1: untuk peringatan juga

Ditutup melalui ccf9bede6bc39fb62e43e1efe98136c5f35dae6b & d7b55c4ee8491dbd853e28a1527050d2d1e7deab

Sebuah peringatan akan sangat bagus. Saya baru saja menghabiskan satu jam mencoba mencari tahu mengapa acara khusus saya tidak ditanggapi (jawabannya adalah itu memiliki nama berbungkus unta).

Ada peringatan ketika Anda memiliki komponen atau prop terkait yang akan merespons versi kebab-case dari komponen atau prop PascalCase Anda. Jika Anda salah ketik dalam suatu acara, Vue tidak dapat berbuat banyak tentang hal itu.

Atau maksud Anda untuk alat peraga acara default yang ada seperti v-on:keyup atau @keyup singkatnya?

@guidobouman di file template saya, saya punya <my-component v-on:customEvent="myMethod"> . Dalam komponen anak saya memiliki this.$emit('customEvent'); . Acara sebenarnya yang didengarkan oleh orang tua adalah customevent bukan customEvent , tentu saja, tetapi saya butuh waktu lama untuk mengetahuinya karena tidak mudah untuk di-debug. Saya berpikir akan lebih baik untuk memperingatkan bahwa atribut kotak unta tidak akan diuraikan seperti itu, untuk orang-orang yang pelupa seperti saya. Mungkin ini sudah pernah dibahas di atas, dan jika demikian saya mohon maaf.

@anthonygore sayangnya itu tidak mungkin, karena browser mengubah html menjadi huruf kecil sebelum Vue memiliki kesempatan untuk mengaksesnya.

Pertanyaan saya adalah, mengapa Vue tidak dapat mengonversinya untuk kami? Mengapa kita harus ingat tentang kebab-case di

Satu aturan untuk dikomit ke memori: HTML = kebab-case, JavaScript = camelCase

Dengan HTML yang saya maksud adalah atribut dan tag. Nilai atribut adalah ekspresi JavaScript saat Anda menggunakan v-bind , jadi pernyataan kedua berlaku.

Pertanyaan saya adalah, mengapa Vue tidak dapat mengonversinya untuk kami? Mengapa kita harus mengingat tentang kebab-case di dalam file vue? Itu membuat segalanya lebih canggung untuk pemula... Saya hanya menyia-nyiakan 20 menit terakhir untuk itu...

terbuang 1,5 jam terakhir karena saya tidak hanya google saja ... dxmn