Vue: HTML 대소문자 구분 해결 방법

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

+
나는 종종 컴포넌트와 태그의 차이점을 보기 위해 그렇게 쓰고 싶습니다.

+1

모든 이벤트 이름을 소문자로 정규화하는 것이 합리적입니까?

네! 코드를 더 읽기 쉽게 만들기 때문에 의미가 있습니다. 저는 항상 이벤트 이름을 소문자로 유지하고 카멜케이스 대신 대시로 구분합니다. Camelcase 이벤트 이름에 대한 경고를 추가하는 것도 좋을 것이라고 생각합니다.

이것은 Vuejs가 Angular와 같은 유사한 접근 방식 을 추구하는 HTML 사양에서 멀어질 것임을 의미합니까?

성능 문제가 있습니까?

잠재적인 문제에 대한 몇 가지 생각:

1. 이전 버전과의 호환성이 존재하는 한 궁극적으로 어떤 것이 결정되든 상관없지만 아마도 케밥 케이스 방법을 계속 사용할 것입니다.
2. camel-case와 lower camel-case의 구분이 부족하여 일부 사람들에게는 혼란스러울 수 있습니다. 일반적으로 var CamelCase 는 클래스를 참조하고 var camelCase 는 클래스가 아닌 변수 var camelCase = new CamelCase(); 를 참조합니다. 그러나 구성 요소의 이름을 따서 명명된 클래스를 만들고 싶지 않기 때문에 이것이 문제가 될 것이라고 생각하지 않습니다.
3. 나는 케이스에 의해서만 구별되는 두 개의 독특한 이벤트를 만드는 것이 매우 형편없는 프로그래밍이라는 데 동의할 것입니다.

가장 큰 우려는 사람들이 코딩하는 방식에 이상한 불일치를 도입하는 것입니다. 예를 들어 :myprop="" :myProp="" :mYpRoP="" :my-prop="" 는 모두 유효하고 동일합니다.

👎 마크업에 케밥 케이스를, 코드에 카멜 케이스를 유지하세요. 이것은 HTML 사양의 일부이며 대소문자를 무시하는 것은 다른 프레임워크에서 온 사람들이나 이미 표준을 배운 사람들에게 더 큰 학습 곡선이 될 것입니다.

@Teevio 에 동의합니다. 일관성이 손실됩니다.

HTML은 kebab-case를 사용하며 ECMAScript가 camelCase 언어라는 허용된 커뮤니티 표준입니다. _hiding_ 대신 분리된 상태로 유지해야 합니다(반응에서 사용자 정의 속성을 렌더링하는 데 반응을 얻을 수 있는 유일한 방법은 일관성을 적용하는 data-* 및 aria-*를 사용하는 것입니다).

_beginner_에 camelCase <-> kebab-case를 설명하는 이유(MDN 링크를 통해 또는 여기까지)는 초보자의 HTML 이해에 큰 도움이 될 것입니다.

Evan의 말에 동의합니다. 가독성과 코드 일관성이 더 중요합니다!
+1

나에게 HTML 내부에 camelCase가 있다는 것은 정말 이상하게 보일 것입니다.

HTML은 HTML, JS는 JS

현재 버전은 괜찮습니다

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에서 camelCase 태그/속성을 작성하는 것은 완전히 유효합니다. 태그/속성 이름 일치는 대소문자를 구분하지 않고 수행됩니다. . 사양은 다음과 같습니다.

HTML 구문의 문서에서:

HTML 요소의 태그 이름은 이 문서의 HTML 요소 섹션에 제공된 요소 이름과 대소문자를 구분하지 않는 대소문자를 혼합하여 작성할 수 있습니다. 즉, 태그 이름은 대소문자를 구분하지 않습니다.
HTML 요소의 속성 이름은 이 문서의 HTML 요소 섹션에 제공된 속성 이름과 대소문자를 구분하지 않는 대소문자를 혼합하여 작성할 수 있습니다. 즉, 속성 이름은 대소문자를 구분하지 않습니다.

따라서 PascalCase/camelCase를 사용하여 코드 일관성/가독성이 향상되면 완전히 사양을 준수하는 것입니다. 모든 사람에게 해당되는 것은 아니지만 케밥 케이스를 선호한다면 계속 사용할 수 있습니다.

그리고 특히 re @jamesxv7 : 이것은 Angular 2가 하는 것과 다릅니다. Angular 2는 맞춤형 HTML 파서를 도입하여 템플릿을 대소문자를 구분하도록 만들고 있습니다. 반대로 Vue는 실제로 JS 대응 항목을 대소문자를 구분하지 않도록 하여 사양을 따릅니다.

나는 케밥을 html로 유지하는 것을 선호합니다. 나는 일관성이라는 아이디어를 좋아하지만 사양 준수라는 아이디어를 더 좋아합니다.

camelCase 태그를 찾았습니다.. HTML은 대소문자를 구분하지 않습니다. 사용대신에. Vue는 JavaScript에서 camelCase ID로 정의된 구성 요소와 자동으로 일치시킵니다.

이 경고는 구성 요소 등록이 작동하는 방식에 대해 이미 매우 간결합니다. 그렇긴 하지만 다른 사람들이 언급했듯이 케밥을 계속 작성할 수 있는 옵션이 있는 한 HTML에서 camelCase를 허용하는 것은 훌륭하다고 생각합니다.

@yyx990803 네 , 동의합니다. 반대할 수 있는 최대한 많은 주장을 생각해 보려고 노력하고 있지만 솔직히 나는 고집할 만한 주장이 없습니다. 당신이 언급했듯이, 우리는 결국 스타일 선택에 대해 논쟁하고 있습니다. 나는 개인적으로 우리가 새로운 것을 사용할 수 있는 옵션이 있는 동안 이미 가지고 있는 것을 고수할 수 있는 한(그러나 강제는 아니지만) 언급된 변경 사항에 대해 괜찮다고 생각합니다.

kebab-case가 여전히 작동하고 camelCase/PascalCase를 사용하는 것이 BC를 손상시키지 않는 옵션이라면 사용할 때 추가에 반대할 수 없습니다. 내가 다른 일을 하도록 강요하는 것은 변화가 아닙니다. 새로운 옵션일 뿐입니다.

내가 말하거나 제안할 수 있는 유일한 것은 이 옵션이 잘 문서화되어 있는지 확인하는 것입니다. 항상 Evan처럼 잘했습니다!

스콧

경고 또는 무시와 같은 옵션을 만들 수 있습니다.
구성 요소가 있다고 가정합니다. myComponent
html에서 mycompOnent 로 언급하고 개인적으로 다음과 같은 경고를 선호합니다.
we found something that would match "myComponent": "mycompOnent" (line 152), use "my-component" instead
물론 소품도 마찬가지.
첫 번째 시도에서 작업하는 것보다 나중에 가독성이 더 중요하다고 생각합니다.

나는 또한 kebab-case/camelCase 문제를 우연히 발견했습니다. 그러나 진짜 문제는 무엇이 잘못되었는지 경고를 받지 못했다는 것입니다 ;)

기본값은 경고가 없고 작동만 하는 것일 수 있으며 이는 나와 관련이 없습니다.
또한 경고는 디버그 모드에서만 볼 수 있어야 한다고 생각합니다.

atone vs a-tone vs at-one 는 어떻습니까? 나는 그들이 아주 드문 경우라고 생각합니다.

@simplesmiler 케밥 케이스 소품은 여전히 ​​이전 규칙을 사용하여 대소문자 구분과 일치합니다.

이것은 웹 표준에 대한 투명성을 촉진하지 않습니다. 사용자 정의 요소 사양 에는 이름에 하이픈이 포함되어야 한다고 명시되어 있습니다. <my-component/>

@simplesmiler 가 말한 것은 어떻습니까: addOne 및 adDone 는 동일한 코드를 실행합니다. 이것은 이벤트 구현에 특히 불쾌할 것입니다.

그리고 html은 대소문자를 구분하지 않기 때문에 라이브러리에서 대소문자 구분에 대한 아이디어를 도입하지 맙시다. 이 구현은 html에서 대소문자를 구분하는 것만을 촉진할 것입니다. 제 생각에는 이는 나쁜 생각입니다.

또한 파일 이름에 하이픈 구분을 사용합니다. 거기에서도 그것들을 제거하고 케이싱을 추가해야 합니까?

마지막으로 하이픈과 대소문자 구분 시스템을 함께 사용하면 팀의 새로운 개발자를 위한 다양한 코딩 스타일을 촉진할 수 있습니다.

나는 @paulpflug 의 접근 방식을 선호합니다. 이 영역에 대한 적절한 경고는 많은 도움이 될 것입니다.

나는 HTML Pascal/Camel 케이스를 만드는 것을 좋아하지 않습니다. 웹 표준을 깨고 일관성을 유지하는 것이 좋습니다.

가장 작은 부분을 일관성 있게 만들려고 하면 복잡성의 또 다른 계층이 추가됩니다. 또한 나쁜 습관을 유발할 수도 있습니다. 언젠가는 Vue를 사용하지 않는 곳에서 작업해야 하므로 HTML이 다르게 구문 분석되는 이유를 이해하지 못할 수 있으므로 라이브러리는 표준을 유지하고 개발자를 오도하지 않도록 해야 합니다.

@paulpflug 에 전적으로 동의합니다. 경고를 추가하면 프로덕션 코드에 대한 작업이 줄어들고 개발자가 다시 올바른 코드를 작성할 수 있습니다.

이것이 구현되어서는 안 되는 이유에 대한 좋은 주장 사례: http://eisenbergeffect.bluespire.com/on-angular-2-and-html/

이것은 일반적으로 사람들이 Angular 2를 싫어하는 주요 이유입니다. 라이브러리가 표준을 준수하도록 유지하는 데 전적으로 동의합니다. 한때 HTML이 대소문자를 구분하도록 초안을 작성했으며 너무 많은 문제와 너무 많은 유연성을 제공하는 상황 때문에 폐기되었습니다.

@blake-newman: 이와 관련하여 @yyx990803 은 이미 이전 댓글 에서 이에 대해 이야기한 것 같습니다.

@jamesxv7 그 의견은 그것을 꽤 잘 요약합니다. Evan은 HTML 사양 변경을 제안하지 않고 Vue가 구성 요소 이름을 찾는 방법을 변경할 것을 제안합니다. 케밥을 낙타로 변환하고 일치하는 구성 요소를 찾는 대신 (케밥을 수용하기 위해) 대시를 제거한 다음 대소문자를 구분하지 않고 구성 요소를 검색합니다. HTML 자체는 계속 사양을 준수합니다. 또한 우리가 원하는 모든 경우를 사용할 수 있습니다. 이것은 나에게 사악하거나 나쁜 선택이 아닌 것 같습니다 :)

@yyx990803 <MyComponent> 스타일을 승격된 스타일로 계획하시겠습니까(예: 문서 및 예제는 이렇게 작성될 예정입니다), 아니면 그냥 옵션이 될 것이며 케밥 케이스 스타일이 기본 스타일로 남을 것입니까?

@blake-newman 이 주석 을 읽으십시오 - 표준을 준수합니다 :)

@paulpflug @guidobouman : vue-loader 또는 vueify 의 최신 버전을 사용하는 경우 camelCase 태그 및 속성에 대한 경고가 이미 있습니다. 그러나 런타임 시 HTML 파서 동작으로 인해 케이스 정보가 이미 손실되었을 수 있으므로 camelCase 검사는 컴파일 시 수행해야 합니다. 따라서 vue-loader 또는 vueify 없이 Vue를 사용하는 경우 경고가 표시되지 않습니다.

@yyx990803 - 그러나 웹 구성 요소에 대해 링크된 @blake-newman 사양에는 다음과 같이 명시되어 있습니다.

사용자 정의 요소 유형은 사용자 정의 요소 인터페이스를 식별하고 NCName 생성과 일치해야 하는 일련의 문자이며 _U+002D HYPHEN-MINUS 문자를 포함해야 하고 _대문자 ASCII 문자를 포함해서는 안 됩니다_.

그것이 Vue 구성 요소와 어떻게 관련되는지 잘 모르겠습니다. 문서에서는 웹 구성 요소 표준을 느슨하게 따르려고 합니다.

Vue.js 구성 요소는 웹 구성 요소 사양의 일부인 사용자 지정 요소와 매우 유사하다는 것을 눈치채셨을 것입니다. 실제로 Vue.js의 구성 요소 구문은 사양에 따라 느슨하게 모델링됩니다.

그래서 나는 camelCase와 PascalCase를 허용하기 위해 먼저 사양을 변경해야 한다고 말하고 싶습니다.

스콧

@smolinari the Vue 문서에 따르면 '엄격하게'가 아니라 '느슨하게 모델링'되었으며 내 생각에는 이 변경의 여지가 남아 있습니다.

@yyx990803 사례 정보가 손실될 수 있지만 여전히 경고가 있을 수 있습니다.
템플릿에 'mycOmponent'를 작성하면 mycomponent 로 구문 분석되지만 예상되는 값은 my-component 이면 Vue(디버그 모드에서)는 my-component mycomponent 를 찾아야 합니다. my-component 및 잘못된 사용법에 대해 경고합니다. 분실 사례 정보는 여기서 중요하지 않습니다.
경고를 표시하지 않고 대신 직접 일치시키는 옵션이 있을 수 있습니다(제안된 동작과 동일).

-1 camelCase/PascalCase로 마이그레이션합니다. HTML에서 JS와 같은 구문을 보는 것은 다소 어색할 것입니다. 내가 jsx를 참을 수 없는 것과 같은 이유입니다.
@paulpflug 의 제안에 +1. 문제가 온보딩 초보자인 경우 사용자에게 문제를 알리는 경고를 발행하지 않는 이유는 무엇입니까?

@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이 다른 기술이고 다른 이름 지정 시스템을 사용하기 때문에 존재합니다. 그리고 두 기술 모두에서 동일한 경우(케밥 또는 낙타)를 사용하면 이상한 점이 한 곳에서 다른 곳으로 이동하지만 근본적인 문제는 계속될 것입니다 .
그래서 저는 우리가 할 수 있는 최선을 다해 선을 긋는다고 믿습니다. 현재 라인 i,e. html 컨텍스트의 케밥 케이스와 js 컨텍스트의 camleCase(및 PascalCase)는 매우 좋습니다 .

그래서 IMO, 우리는 더 나은 것을 찾는 대신 현재의 규약을 지원해야 합니다. 물론 초보자를 돕기 위해 경고를 사용하십시오.

@prog-rajkamal 예, 이제 경고를 구현하는 경향이 있습니다.

나는 이제 경고를 추가하는 것에 투표합니다:+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 를 사용할 때 속성 값은 JavaScript 표현식이므로 두 번째 문이 적용됩니다.

내 질문은 Vue가 우리를 위해 변환할 수 없는 이유는 무엇입니까? vue 파일에서 케밥 케이스를 기억해야 하는 이유는 무엇입니까? 초심자 입장에서는 더 어색해 집니다.. 그걸 위해 지난 20분을 허비했습니다...

내가 방금 구글링하지 않았기 때문에 지난 1.5시간을 낭비했습니다... dxmn