Vue 개발자로서 이러한 실수를 저질렀습니까?

나는 최근에 인터넷 개발에 관한 아주 좋은 팟캐스트를 구독했다. 이름은 아담 왓슨이다.Vue에는 역모드에 대한 에피소드가 있습니다.Vue 핵심 팀인 Chris Fritz의 js는 Vue 구조에 대한 좋은 조언과 Vue 개발자가 자주 범하는 오류를 많이 제공했다.나는 아직 모든 토론 내용을 포함하지 않았기 때문에, 반드시 완전한 팟캐스트 세션을 듣고, 멋진 대화와 Vue Goods를 이해해야 한다.나는 본문 끝에 링크를 추가할 것이다.
이번 회에는 각양각색의 화제가 있다.다음은 제 노트입니다.

국가 관리 및 활동:
복잡한 상태에서는 Vuex가 가장 좋습니다.사람들은 일반적으로 이벤트 버스를 사용하여 상태를 관리하고 구성 요소가 이벤트를 구독하도록 한다.그러나 최종적으로 발생하는 것은 대량의 중복 상태의 생성이다. 이것은 모든 내용을 동기화하려고 할 때 일련의 문제를 일으킬 수 있다.디버깅을 하는 경우 변경 사항이 어디에서 왔는지 알 수 없습니다.
Vuex는 여러 가지 옵션을 제공하여 일을 추적할 수 있게 한다.Vue DevTools에는 디버깅 및 원형 제작에 유용한 별도의 Vuex 탭이 있습니다.우리는 서로 다른 상태의 변경을 추적하고 스타일을 바꾸며 HMR(열모듈 재로드)을 사용하여 변경이 즉시 발생하는 것을 볼 수 있다.소형 프로젝트에 대해 구성 요소 간에 한두 개의 사건을 통신해야 할 수도 있고 이벤트 버스는 정상적으로 작동할 수 있다.
이러한 작업 중 하나 이상을 발견하면 프로젝트의 복잡한 상태를 관리하기 위해 Vuex를 사용해야 한다는 좋은 지표입니다.

한 구성 요소에 대량의 아이템을 계속 전달할 때

상위 구성 요소가 하위 구성 요소의 상태를 추적하여 형제자매가 상위 구성 요소

를 통해 서로 상호작용할 수 있도록 한다.

구성 요소에 전달되는 도구는 이 구성 요소 자체가 아닌 다른 구성 요소에 끼워 넣는 데 필요한

또 다른 nono는 이벤트를 보내서 부급에 접근하고 조종하는 상태가 아니라 this.$parent 를 사용합니다.이것은 보잘것없는 것 같다. 왜냐하면 우리는 서브어셈블리가 부모 어셈블리에서 무엇을 바꾸었는지 잘 알고 있기 때문이다.그러나 만약에 이 프로젝트가 거대한 프로젝트, 특히 상당히 오랫동안 진행된 프로젝트라면 전체 프로젝트를 추적하고 왜 부모 구성 요소 내부에 변경 사항이 발생했는지 기억하기 어렵다.이것은 아주 좋은 해결 방안인 것 같고, 심지어는 중용할 수 있는 해결 방안인 것 같다.더 이상 사용하지 않아도 다른 개발자 (작업 중인 동료 개발자, 또는 OSS를 사용하고 있다면 다른 공헌자) 가 사용할 수 있습니다.언제든지 이런 상황이 발생하면 코드 이해를 어렵게 하고 디버깅을 어렵게 할 수 있다.

사용자 정의 이벤트와 리셋 도구입니다.어느 것이 더 좋아요?
사용자 지정 이벤트는 이벤트를 전송하여 값을 전달하는 이벤트입니다.

this.$emit('modal-closed', this.isClosed);

다른 한편, 리셋 도구는 부모 대상이 도구로 하위 대상에게 전달하여 집행하는 일반적인 방법이다.이렇게 하면 사용자 정의 이벤트에서 값을 부모에게 전달하는 것이 아니라

<button @click="onClose">Close Modal</button>

따라서 모두 같은 임무를 수행하는 데 사용된다.첫 번째 경우, 우리는 이벤트를 통해 하나의 값을 부모에게 전달한 다음에, 부모는 방법을 실행하거나, 이 값을 사용하여 필요한 작업을 수행한다.두 번째 상황에서 우리는 실행할 방법을 자급 자체에 전달하고 부급이 이 방법을 집행하는 것을 대표하기를 바란다.
그럼 뭐가 더 좋아요?
이것은 거의 차이가 없다.크리스의 말대로

It's stylistic

이것은 그것이 완전히 사용자에게 달려 있다는 것을 의미한다.만약 네가 줄곧 한 가지 방법을 사용하고 있다면, 그것을 바꿀 이유가 없다.단, 어떤 방법을 사용할지 진정으로 고려하지 않았다면, 사용자 정의 이벤트를 사용해야 할 수도 있습니다.사용자 정의 이벤트 시스템은 보안에 있어서 훨씬 좋다.그것은 부모로 하여금 불필요한 정보를 모르게 한다.우리는 단지 하나의 값만 전달하기 때문에 부급에게 필요한 세부 사항만 알려준다.
어셈블리 제어 항목을 처리할 때 타겟은 다른 어셈블리를 걱정하지 않고 어셈블리를 처리하는 것입니다.하위 세대가 부모 세대를 대표하여 하나의 방법을 집행하도록 함으로써, 우리는 반드시 하나의 구성 요소에 의존하여 다른 구성 요소를 위해 하나의 방법을 집행해야 할 뿐만 아니라, 이 방법을 집행하는 특정한 하위 세대도 모른다.
어셈블리가 너무 많거나 특정 상위 레벨에 하위 레벨이 여러 개 있는 경우 이 문제가 발생할 수 있습니다.몇 달 정도 지나면 혼란스러워질 수도 있고, 아버지 대상을 보기만 해도 이 방법이 어떻게 집행되었는지 기억하기 어려울 수도 있다.
이것은 리셋 도구를 사용하는 데 어떤 결점이 있다는 것을 의미하지 않는다.사용자 정의 이벤트를 사용하면 Vue처럼 느껴지며 official Vue documentation에서 시범을 보였다.

언제가 관찰자를 사용하기에 적당한 시간입니까?계산 속성이 더 좋아요?
계산 속성은 관찰자의 업무와 매우 비슷해서 대부분의 새로운 Vue 개발자들이 어느 것을 선택해야 할지 곤혹스러워한다.일반적으로, 모니터는 비동기식 작업에 가장 좋다.
다른 상태가 업데이트될 때 이 상태를 업데이트하려면 속성을 계산해야 합니다.간단한 예는 fullName와 firstName에서 도출lastName 속성이다.
watchers를 사용하면 단조롭고 무미건조해질 수 있습니다. 추적이 필요한 모든 속성을 위해watcher를 만들어야 하기 때문입니다.의존하는 모든 속성을 세심하게 감시함으로써 속성의 상태를 바꾸려는 것은 어려운 일이다.
이런 상황에서 속성을 계산하는 것은 복음이다.우리가 해야 할 일은 그것에 의존하는 속성을 부여하는 것이다.이 속성 중 하나가 변경되면 다시 평가하고 변경합니다.이 속성은 캐시되어 있기 때문에 매번 불필요한 재계산을 하지 않습니다.

This is the performance benefit of computed properties over regular methods and watchers.

이것은 결코 관찰자가 쓸모가 없다는 것을 의미하지 않는다.어떤 경우, 계산의 속성은 우리에게 도움이 되지 않으며, 우리는 방법이 제공할 수 없는 반응성을 필요로 한다.따라서 이런 상황에서 관찰자가 최선이다.
나는 개인 프로젝트에서 유사한 상황을 만났다.나는 모든 사용자가 하나의 대상인 사용자 그룹을 가지고 있다.선택한 버튼에 따라 특정 사용자를 표시해야 하는 3개의 라디오 버튼이 있습니다.표시할 사용자를 선택할 수 있는 방법이 있습니다.간단한 클릭 listener (내가 이렇게 한 것) 를 사용해서 이 방법들을 실행하는 것은 매우 쉽다.그러나 만약 우리가 계산과 관찰자 사이에서 선택을 해야 한다면 계산 속성은 이런 상황에서 작용하지 않을 것이다.

A computed property works by deriving results from the change in state of one or more properties and returns a value.

따라서 이 두 가지 방법 중 관찰자가 가장 적합하다.
사용 방법, 계산 속성, 관찰자에 대한 정보를 더 알고 싶다면, 사라 드래너의 이 심도 있는 문장article을 꼭 보십시오.

정확한 방식으로 코드를 다시 사용하다
Vue에서 코드를 재사용할 수 있는 여러 가지 방법이 있습니다.그러나 그 중 세 가지가 개발자들 사이에서 널리 알려지고 인기가 많다.

구성 요소 사용

사용 명령

믹서 사용

구성 요소를 이용한 코드 재사용은 Vue의 핵심 기반입니다.그러나 Chris는 많은 소스 플러그인들이 구성 요소일 때 명령과 혼합을 사용한다고 알려 준다.많은 개발자들이 믹스와 명령을 잘못된 방식으로 사용한다.

A good use case for mixins is when we want components to do something different than their usual specific behavior

명령은 여러 요소 간에 비헤이비어를 공유하는 데 사용됩니다.그것들은 이 행위를 단독 구성 요소의 일부분으로 하는 것이 아니라 원소에 더 의미가 있다.우리는 그것들이 하나의 단독 구성 요소를 가지고 있다는 것을 보장하기 위해 충분한 특정성이나 독특성이 없는 행위가 매우 보편적이라는 것을 자주 볼 수 있다.
Chris는 자동 초점 맞추기 기능의 좋은 예를 언급했다.DOM을 수동으로 조작해야 하지만, 사용량이 많지 않기 때문에 구성 요소가 필요합니다.이런 상황에서 지령은 최선의 선택이다.
사람들은 심지어 필요 없을 때도 믹스를 자주 사용하는 것 같다.역할 영역 슬롯은mixin과 같은 기능을 제공하기 때문에 대부분의 경우 더 좋은 선택입니다.우리는 혼혈이 절대적으로 필요하다. 상황은 매우 구체적이다.역할 영역 슬롯은 더욱 조합성을 갖추고 우리가 필요로 하는 모든 것을 패키지 구성 요소에 제공하며, 우리는 포함할 내용을 선택할 수 있다.
mixin의 좋은 사용 사례는 일부 구성 요소가 매우 구체적인 일을 할 수 있지만 상황에 따라 서로 다른 일을 하기를 바란다는 것이다.구성 요소 옵션을 되돌려 주는 함수인mixin을 만들 수 있습니다.그래서 우리는 동적으로 구성 요소 행위를 생성했다.이런 동태적인 행위에 대해 우리도 약간의 변수가 필요하다.우리는 그것들을 이 함수에 넣을 수 있지만, 필요로 하는 것과 함께 구성 요소에 놓을 수 없다.
이번 회에는 더 많은 재미있는 대화가 있고, 또 많은 것을 배워야 한다.나는 상황을 더 잘 이해하고 이 훌륭한 아나운서를 구독할 수 있도록 적어도 한 번은 이 회를 들을 것을 건의한다.
팟캐스트 에피소드here를 찾을 수 있습니다.트위터에서 위에서 언급한 모든 사람을 찾을 수 있다.언제든지 그들의 최신 업무를 이해할 수 있도록 그들을 주목해야 한다.만약 당신이 Vue에 관한 문제가 있다면, 나는 이 사람들이 매우 기꺼이 도와줄 것이라고 믿는다.만약 내가 본문에 추가해야 할 어떤 좋은 힌트를 놓쳤다면, 아래의 평론에서 나에게 알려주십시오.