Vue: vuejs2.0은 $broadcast, $dispatch 이벤트 API를 유지해야 하나요? 2.0에서 지점간 부모-자식 통신을 처리하는 좋은 솔루션이 없습니다.

일반적인 제안 토론이기 때문에 아직 바이올린을 만들지 않았습니다. 필요한 경우 보여주기 위해 만들고 싶습니다.
감사합니다~!

이것은 이미 2.0 변경 사항 에서 정당화되었습니다.

사본은 다음과 같습니다.

$dispatch 및 $broadcast 사용 중단을 처리하는 방법

$dispatch 및 $broadcast 더 이상 사용하지 않는 이유는 구성 요소 트리 구조에 의존하는 이벤트 흐름이 구성 요소 트리가 커질 때 추론하기 어려울 수 있기 때문입니다. 큰 앱에서 잘 확장되며 나중에 고통을 겪을 수 있도록 설정하고 싶지 않습니다.) $dispatch 및 $broadcast 도 형제 구성 요소 간의 통신을 해결하지 않습니다. 대신 Node.js 의

var bus = new Vue()

// in component A's method
bus.$emit('id-selected', 1)

// in component B's created hook
bus.$on('id-selected', function (id) {
 // ...
})

이 패턴은 간단한 시나리오에서 $dispatch 및 $broadcast 를 대체할 수 있습니다. 그러나 더 복잡한 경우에는 Vuex를 사용하여 전용 상태 관리 계층을 도입하는 것이 좋습니다.

업그레이드 가이드에 표시된 예는 귀하가 말하는 것과 동일합니다.

재귀 통신 정보: 여러 구성 요소가 동일한 이벤트를 수신할 수 있습니다. 이 이벤트는 모든 어린이가 알 수 있도록 공통 부모가 인식합니다.

@posva , 정보 감사합니다. 버스 허브는 단순한 단일 구성 요소 지점 대 단일 구성 요소 지점 통신에서 잘 작동합니다. 동일한 구성 요소 유형을 가진 구성 요소가 여러 개 있으면 문제가 발생하지만 불행히도 이것은 정상적인 경우입니다. 대부분의 경우 이벤트를 사용하려는 것은 특정 구성 요소에 속하는 작은 데이터를 업데이트하는 것입니다. 현재 이벤트 버스 구현은 목적지 또는 발신 노드에 대한 정보를 제공하지 않습니다(모든 구성 요소의 _uid를 보았고 이벤트 배선에 이 고유한 _uid를 사용할 수 있습니까? ). 따라서 vuejs2.0은 실제로 지점 간 이벤트 통신을 지원할 수 없습니다. . 정확히 말하면 vuejs2.0 이벤트 버스는 컴포넌트 타입에서 컴포넌트 타입으로만 통신을 지원하나요? 해당 요구 사항을 해결할 수 있는 간단한 솔루션이 있습니까? 트리의 이벤트에 의해 트리거되고 ITS OWN DATA 업데이트
vuex는 응용 프로그램 수준의 전역 정적 상태 데이터 관리에 적합하지만 내가 이해하는 것처럼 특정 로컬 구성 요소 데이터 관리에는 좋지 않을 수 있습니까?
이 문제에 대한 더 많은 생각을 환영합니다.

@cnweibo 포럼의 예를 들어 귀하의 질문에 답변했습니다. 이 예가 귀하의 요구 사항을 충족시킬 것이라고 생각합니다.
http://forum.vuejs.org/topic/4832/vue2-0-event-bus-issue-how-to-deliver-event-to-parent-when-the-same-multiple-parent-children-in- 돔/6

해당 요구 사항을 해결할 수 있는 간단한 솔루션이 있습니까?
트리의 이벤트 및 자체 데이터 업데이트

이것은 복잡한 이벤트 시스템 없이 단순히 vuex로 해결됩니다.

vuex는 응용 프로그램 수준의 전역 정적 상태 데이터 관리에 적합합니다.
하지만 내가 이해하는 것처럼 특정 로컬 구성 요소 데이터에는 좋지 않을 수 있습니다.
관리

'로컬'은 단일 구성 요소만을 의미합니다. 사용 사례는 전체 상태를 관리하고 있습니다.
여러 구성 요소가 있으므로 전역적입니다.
그리고 vuex는 모듈(상태 하위 트리)을 가질 수 있으므로 '전역 변수'가 아닙니다.
일종의 '글로벌'이다. 자체 vuex로 구성 요소 그룹을 구동할 수 있습니다.
모듈.

이 전체 '이벤트 대 공유 상태' 토론은 몇 달 동안 해결되었습니다.
전이며 결론은 글로벌 이벤트 버스 또는 vuex를 사용하는 것입니다. 그래서 나는
vuex와 작동 방식에 대해 자세히 읽어볼 것을 권장합니다.

2016년 9월 1일 목요일 16:17 cnweibo [email protected]에서 다음과 같이 썼습니다.

@posva https://github.com/posva , 정보 감사합니다. 버스
허브는 단일 구성 요소를 가리키는 단순한 단일 구성 요소에서 정말 잘 작동합니다.
포인트 커뮤니케이션. 동일한 구성 요소를 가진 여러 구성 요소가 있는 경우
유형에 문제가 있습니다. 불행히도 이것은 정상적인 경우입니다. 많은
경우에, 내가 이벤트를 사용하고 싶은 것은 일부에 속하는 작은 데이터를 업데이트하는 것입니다
특정 구성 요소. 현재 이벤트 버스 구현은 다음을 제공하지 않습니다.
목적지 또는 출발지 노드에 대한 정보(나는 모든
이벤트 연결에 이 고유한 _uid를 사용할 수 있습니까? ), 그래서
vuejs2.0은 사실 point to point 이벤트 통신을 지원하지 않습니다. 되려고
정확한 vuejs2.0 이벤트 버스는 구성 요소 유형에 대한 구성 요소 유형만 지원합니다.
의사 소통? 해당 요구 사항을 해결할 수 있는 간단한 솔루션이 있습니까?
트리의 이벤트에 의해 트리거되고 _ITS OWN DATA_ 업데이트
vuex는 응용 프로그램 수준의 전역 정적 상태 데이터 관리에 적합합니다.
하지만 내가 이해하는 것처럼 특정 로컬 구성 요소 데이터에는 좋지 않을 수 있습니다.
관리?

이 문제에 대한 더 많은 생각을 환영합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/vuejs/vue/issues/3581#issuecomment -244008699 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFTLl1bjHqWTVDAkr8Fqbx0WiTuH16n2ks5qlooBgaJpZM4JyUfJ
.

이제 이 문제를 닫겠습니다.

1. 솔루션이 제공되었고
2. Github 문제는 어쨌든 지원을 요청하기에 적합한 장소가 아닙니다(지침 참조).

@ktsn , 데모 바이올린 주셔서 감사합니다. 그것이 바로 내가 간단한 솔루션을 원하는 것입니다!
@fnlctrl , 소위 모듈식 vuex 상태 관리에 더 많은 시간을 할애할 것입니다.

다시 한번 감사합니다~!

내 생각에 $broadcast는 필요하지 않고 떨어지는 소품 데이터 흐름만 필요합니다.
모든 $dispatch는 다음과 같이 단일 레벨 v-on 및 $emit으로 다시 구현할 수 있습니다(Vue 1에서).
관련된 각 구성 요소에 대한 <child-component @select="$emit('select', $arguments[0])" />
다른 상황에서는 사용자 지정 이벤트 버스를 사용해야 합니다.

실제로 구성 요소 자체의 사용자 정의 이벤트에 대한 구성 요소 태그의 v-on은 구성 요소 자체의 $emit에서도 작동합니다.

@cnweibo 기록의 경우 이벤트 데이터를 검색할 수 있습니다.

{
  template: `<foo @bar="dosomething">`,
  methods: {
    dosomething(params1, params2, ... and all the event data args) {}
  }
}

하지만 vuejs2.0에서는 이벤트 데이터를 가져올 수 없습니다.

물론 그럴 수 있습니다. 다른 생각을 하게 만드는 이유는 무엇입니까?

@fnlctrl
@LinusBorg
죄송합니다. 제가 오해를 해서 불명확하게 말씀드립니다. 제공된 @fnlctrl 패턴에서 이벤트 핸들러의 모든 데이터를 실제로 검색할 수 있습니다.

 <comp @some-event-emitted-by-comp-internal-template="someFuncInParentScope"></comp>

다른 문제에서 내 자신의 의견을 복사/붙여넣기: https://github.com/vuejs/vue/issues/2760#issuecomment -250883407

$dispatch를 제거하는 것은 끔찍한 생각이었습니다. 이것은 시각적 트리 위로 버블링 작업/이벤트의 개념을 구현한 최초의 UI 프레임워크/라이브러리가 아닙니다. 잘 확립된 아이디어입니다. "알 수 없는 상위 트리에서 부작용을 일으키는 이벤트를 전달할 수 있다는 것이 나에게 문제의 처방처럼 들린다"는 전제 하에 이 기능을 제거하는 이유는 무엇입니까? 이 책임은 사용자에게 맡겨야 합니다. 나는 대부분이 이 기능을 적절하게 사용하는 상식을 가지고 있다고 확신합니다. 새로운 개념이 아닙니다!

이 라이브러리가 DOM 및 DOM 이벤트와 같은 오랫동안 확립된 웹 기술/개념을 기반으로 구축되었을 때 실제로 시각적 트리를 버블링하고 아무도 없이 그렇게 해왔을 때 이 변경의 이점을 실제로 볼 수 없습니다. 불평. 웹 컴포넌트에 대한 W3C 제안 덕분에 컴포넌트에 대한 아이디어가 최근에 채택된 것이 아닌가요? 제 생각에는 Vue 구성 요소가 이벤트 처리가 수행되는 방식과 관련하여 일반 DOM 요소와 유사하게 동작한다는 것은 의미가 있습니다.

글로벌 이벤트 버스를 사용하기 위해 제안된 대안은 더 실용적이고 효과적이고 이해하기 쉬운(수년간 잘 확립된 개념이기 때문에) 이미 존재했을 때 나에게 비논리적으로 보입니다.

이 스레드의 다른 제안은 EmberJS가 원하는 방식을 생각나게 합니다. 계층 구조의 각 수준 아래에 있는 구성 요소에 속성으로 클로저 작업을 전달합니다. 너무 지루하고 불필요한! Vuejs는 내가 https://www.npmjs.com/package/ember-component-action-bubbling을 쓴 이유였습니다

이것 외에도 나는 당신의 도서관을 정말 좋아합니다. 그러나 진지하게, 나는 이것이 끔찍한 변화라고 생각합니다.

이벤트 버스 패러다임은 이벤트 기반 아키텍처가 종종 선언적 상태 기반 아키텍처보다 열등할 때 정확히 동일한 작업을 수행하는 솔루션으로 제안되었습니다.

사용자가 로그인할 수 있는 앱이 있다고 가정해 보겠습니다. 이벤트 기반 솔루션의 경우:

1. 로그인 이벤트 수신
2. 나중에 사용자 이름과 비밀번호로 이벤트를 시작하십시오.
3. 어떤 구성 요소가 수신 중이든 그에 따라 해당 이벤트에 응답합니다.

하지만 여기에는 몇 가지 문제가 있습니다. 가장 큰 문제는 이벤트가 발생할 때 DOM에서 렌더링되지 않는 구성 요소가 변경 사항을 수신하지 않을 뿐만 아니라 응용 프로그램의 어느 부분이 이벤트를 수신할지 알 수 없다는 것입니다. 또한 이벤트 수신자는 추가 정보가 제공되지 않으면 이벤트가 어디에서 오는지 알 수 없습니다. 내 언어를 실례하지만, 그것은 내가 처리하고 다시 사용하는 데 신경 쓰지 않는 대규모 클러스터입니다.

상태 저장 접근 방식을 사용해 보겠습니다.

1. 사용자 계정 정보를 나타내는 전역 상태 변수를 만듭니다. 로그아웃하면 null 이고 로그인하면 사용자의 로그인 정보가 있습니다.
2. 사용자가 로그인할 때 계정 정보를 설정합니다.

이 상태 변수에 의존하는 앱의 모든 항목은 그에 따라 업데이트됩니다. 이벤트가 없으며 항상 올바른 정보를 표시하므로 구성 요소가 생성되는 시기 또는 위치는 중요하지 않습니다. 이벤트를 사용하여 전역 상태를 업데이트할 수 있지만 업데이트만 할 수 있는데 왜 그렇게 합니까?

선언적 접근 방식을 사용하면 사용자가 애플리케이션에서 수행하는 작업에 관계없이 상황을 듣지 않고도 로컬/글로벌 상태에 따라 항상 동일한 방식으로 표시되는 방식으로 구성 요소를 작성할 수 있습니다. 나는 이것이 Vue가 줄곧 의도한 것이라고 생각하지만, 소프트웨어 개발의 대부분의 것들과 유사하게, 우리가 그것을 알아내는 데 시간이 걸렸습니다. 하지만 우리가 해서 정말 기쁩니다.

편집: 아, 그리고 매개변수를 감시하고 AJAX 요청을 보내거나 변경될 때 다른 작업을 수행할 수 있다는 것을 잊지 마십시오. 예를 들어, 사용자가 로그인한 후 'loggedIn' 변수를 관찰하고, 이것이 true이면 프로필 이미지를 로드하거나 이와 유사한 것입니다.

나는 당신이 말하는 것을 이해하지만, 일부 임의 구성 요소가 전역 상태를 수정하도록 하는 것은 그 임의 구성 요소가 이벤트를 발생시켜 신이 어디에 있는지 알 수 있도록 하는 것과 같은 것이라고 생각합니다. 응용 프로그램의 흐름이 실수로 "더러워"지는 것과 동일한 위험이 여전히 존재합니다.

두 패러다임을 깔끔한 방식으로 처리하는 방법이 있으며 이는 일반적으로 프레임워크 사용자의 책임이 됩니다.

한 메커니즘이 다른 메커니즘보다 더 이해가 되는 특정 상황이 있을 것입니다. 예를 들어, 로그인 상태는 전체 애플리케이션에 알려야 한다는 데 동의합니다. 전역 상태가 의미가 있습니다. 그러나 응용 프로그램 사용자가 클릭하는 버튼은 일반적으로 사용자가 실제로 로그인하는 논리를 처리하지 않습니다. 이는 상위 체인에서 처리되는 것입니다. 구성 요소일 수도 있고 경로일 수도 있습니다. 버튼은 가능성 만에 로그인 할 의도의 무언가를 통지해야합니다.이 버튼은, 그러므로, 직접 전역 상태를 수정할 필요가 없습니다.

이제 $dispatch를 제거하면 응용 프로그램의 사용자 세션을 관리하고 의도를 직접 알리는 일부 전역 개체에 대해 알기 위해 버튼 구성 요소가 필요합니다. 이렇게 하면 버튼이 전체 애플리케이션에 단단히 결합됩니다.

또는 버튼이 10단계 깊이로 중첩되어 있고 의도가 목적에 도달하도록 모든 수준에서 v-on:login 처리기를 선언해야 할 수 있습니다. 완전히 불필요합니다.

실제로 모든 수준에서 v-on 를 수행해야 하면 코드를 유지 관리하기가 더 어려워집니다.

분명히 상태를 직접 변경하는 것만으로도 문제가 될 수 있지만 Vuex는 돌연변이와 액션으로 그 문제를 해결합니다. 일부 솔루션이 다른 솔루션보다 더 잘 맞는 것도 사실이지만 선언적 논리가 더 나은 옵션이 아닌 상황은 본 적이 없습니다.

귀하의 특정 경우에는 로그인 전용 버튼을 만들지 않을 것입니다. 부록에서 로그인 관련 구성 요소가 어떤 이유로 그렇게 깊게 중첩되어 있으면 전역 상태를 변경하도록 하십시오.

로그인 버튼은 예시일 뿐입니다. 그리고 vuex store는 제가 "some global object"를 언급할 때 언급한 것입니다. vuex가 어떻게 작동하는지 조사해야 하지만 스토어에 대한 참조를 관리하기만 하면 앱 상태의 나머지 부분에 임의의 구성 요소를 밀접하게 결합할 것으로 예상합니다.

예를 들어 로그인 버튼이 타사 라이브러리의 일부인 경우에는 바람직하지 않습니다.

특히 이벤트 버블링이 널리 인식되어 프로젝트의 새로운 기여자가 이해하기 쉬운 경우 두 패러다임을 사용하기 위해 *_choice *_를 선택하지 않았으면 합니다.

예를 들어 라우터 보기 구성 요소에는 내 생각에 저장소에 액세스하고 커밋할 수 있는 모든 권한이 있기 때문에 "일부 임의 구성 요소"가 의미하는 바에 따라 다릅니다. 그러나 버튼, 양식 또는 기타 UI 요소와 같이 재사용을 위한 더 작은 구성 요소인 경우 10번 중 9번은 소품 및 이벤트를 사용하여 저장소에 액세스할 논리적 이유가 없어야 합니다.

Vue 애플리케이션의 데이터는 하향식이므로 로컬 상태를 가능한 한 최상위 수준으로 유지하려고 합니다. 깊은 내포 자체는 가능한 한 피해야 할 문제입니다. 이벤트를 두 단계 아래로 전파하는 것은 그다지 귀찮은 일이 아니지만, 그보다 더 깊이 들어가면 템플릿 구조를 재고해야 할 가능성이 있습니다.

그러나 그것은 대부분 접선입니다. 종종 이해하기 쉬운 패러다임은 결국 지옥 끝까지 남용되고 다루기 어려워지는 패러다임입니다. 상태 기반 접근 방식은 현재 2.0을 사용하고 있는 대부분의 사람들이 동의한 것처럼 훨씬 더 간단합니다. 1.0을 계속 사용하거나 이 접근 방식이 선호하지 않는 경우 다른 프레임워크로 이동할 수 있습니다.

10번 중 9번은 props와 이벤트를 사용하여 스토어에 접근할 논리적 이유가 없어야 합니다.

정확히 내 요점.

딥 네스팅 자체가 최대한 피해야 할 문제

때로는 이것이 옵션이 아닙니다.

이벤트를 두 단계 아래로 전파하는 것은 그다지 귀찮은 일이 아닙니다.

이러한 수준이 더 깊어지면 사실이 아닙니다.

이해하기 쉬운 패러다임은 결국 지옥 끝까지 학대당하고 다루기 힘든 패러다임이다.

이것은 사용자의 규율에 달려 있습니다.

1.0을 계속 사용하거나 이 접근 방식이 선호하지 않는 경우 다른 프레임워크로 이동할 수 있습니다.

음.

단순함과 편리함이 내가 Ember에서 Vue로 전환을 고려한 이유입니다. $dispatch 는 내가 Vue에서 즐겼던 것 중 하나이며 그것을 제거하는 것은 나에게 너무 임의적으로 보입니다.

팀은 2.0 릴리스에서 많은 기능을 제거했습니다. 나는 솔직히 그들 모두에 동의합니다. 이것만은 아닙니다.

답변해주셔서 감사합니다.

@ktsn $broadcast 및 $dispatch에

@rhyek 당신이 제기 한 몇 가지 포인트에 대해 내

1. 암시적 결합.

이벤트를 전달하는 부모와 깊이 중첩된 자식이 있는 경우 코드에서 이 관계를 유추할 수 있는 방법이 없습니다(물론 $broadcast 경우에도 마찬가지입니다).

Vue 2.0에서 도입한 다른 변경 사항과 사용 중단을 살펴보면 명시적 대안을 위해 암시적 동작을 제거하는 것이 일반적인 주제이며 $dispatch 사용을 중단하는 것이 바로 거기에 맞습니다.

예시:

// parent
events: {
  'some-event': function () { ... }
}

// deeply nested child:
$dispatch('some-event')

부모에 직계 자식이 하나만 있는 경우에는 괜찮습니다. 하지만 이 경우 템플릿에 리스너가 있는 $emit() 도 실제 추가 작업이 아닙니다.

중첩된 자식(특히 깊이 중첩된) 또는 둘 이상의 직계 자식이 있는 즉시 (특히 팀에서) 따라가기가 어려워집니다. 모든 자식을 살펴보거나 코드 주석에 의존하여 이벤트가 무엇인지 문서화해야 합니다. 추가 상용구이기도 한 자식 구성 요소에서 트리거됩니다.

다른 구성 요소를 통해 전달할 필요가 없기 때문에 $dispatch 및 $broadcast를 좋아한다고 말합니다. 그리고 나는 그것이 더 쉽다는 데 동의할 수 있습니다. 그러나 이것이 실제로 필수적인 상황을 많이 경험하지 못했습니다. 추가됨/ 이 여행 동안 중간 구성 요소에 의해.

2. 이벤트명

깊게 중첩된 구성 요소와 함께 $dispatch 를 사용할 때 이벤트의 네임스페이스를 매우 명시적으로 지정해야 합니다. 그렇지 않으면 충돌할 수 있기 때문입니다.

// parent
events: {
  'close': function () { ... }
}

// deeply nested child 1:
$dispatch('close')
// deeply nested child 2:
$dispatch('close')

..그리고 만약 그 아이들이 제3자 라이브러리라면, 당신은 이제 망했습니다. 또는 부모에게 $dispatch() 더 가기 전에 이름을 변경하기 위해 중간에 있는 일부 구성 요소에서 이벤트를 잡아야 합니다. 그리고 이 코드를 보고 있는 누군가가 이벤트에 이름을 바꾸는 것 외에는 아무 것도 하지 않는 이유를 생각할 수 있으므로 주석을 추가하는 것을 잊지 마십시오.

$emit 및 템플릿 리스너를 사용하면 이 문제가 발생하지 않습니다. 모든 곳에서 간단하고 짧은 이벤트 이름을 사용할 수 있습니다. 각 이벤트에는 @close="callback "템플릿에 연결된 고유한 콜백이 있으므로 충돌하지 않습니다.

나는 정말로 당신이 두 패러다임을 사용하기 위해 *선택*을 박탈하지 않았으면 합니다.

두 패러다임이 똑같이 잘 작동할 수 있다고 생각한다면 우리는 그것들을 동등하게 취급할 것입니다. 그러나 우리는 위의 이유 등으로 그렇게 생각하지 않습니다.

따라서 우리는 "글로벌 버스" 방법을 사용하여 이를 우회할 수 있는 방법을 남겨두고 가장 잘 작동하는 것으로 사용자를 안내하려고 합니다.

또한 글로벌 상황에 대한 우려에 대해서도 말씀드리고 싶지만 아직 귀하의 입장을 충분히 이해하고 있지는 않습니다.

$dispatch 및 $broadcast가 가장 적합하다고 생각하는 예를 제공할 수 있으며 "우리" 접근 방식이 상황을 개선할 수 있는 방법을 보여주려고 합니다.

$dispatch/$broadcast 와 이벤트 버스는 다른 문제를 처리한다고 생각합니다. 코드를 쉽게 유지 관리하고 다양한 시나리오에서 분리할 수 있습니다. 우리가 둘 다 유지 할 수 있다면 그것은 좋을 것입니다.
모든 경우에 하나가 다른 것보다 낫다고 말하기는 매우 어렵습니다.

@cnweibo 양측에 상당히 철저한 논쟁이 있다고 생각합니다. 솔직히 "서로 다른 문제 해결"에 대한 귀하의 요점은 이해하지 못합니다. 자유롭게 더 많은 주장을 펼칠 수 있지만 이런 일은 일어나지 않을 것이라는 점을 분명히 말씀드릴 수 있습니다.

정말 원한다면 플러그인으로 직접 구현하는 것은 그리 어렵지 않습니다.

@LinusBorg 답변을 작성하는 데 시간을 할애해 주셔서 진심으로 감사드리며 귀하의 주장을 이해합니다.

$dispatch와 $broadcast를 좋아한다고

나는 솔직히 $dispatch 좋아합니다. $broadcast 확실히 이상해 보였습니다. 내가 말했듯이 $dispatch 는 현재 많은 플랫폼에서 보편적인 이벤트 버블링입니다. $broadcast ... 별로. 내가 만난 것과 유사한 유일한 것은 일반 이벤트와 쌍을 이루는 WPF의 "미리보기" 이벤트입니다. 그들은 최상위 요소에서 원래 이벤트의 소스로 시각적 트리를 "통과"하지만 관련 요소의 체인 아래로 직접 전송될 뿐 모든 것으로 _확산되지는 않습니다.

이벤트의 이름을 지정할 때 매우 명시적이어야 합니다.

나는 그것에 동의하고, 어쨌든 그것은 보통 내가 하는 일이다. 또한 사람들이 jQuery에서 하는 데 익숙합니다. 또한 일부 플랫폼은 "소스" 개체를 핸들러에 대한 인수로 보내고 이를 기반으로 컨텍스트를 필터링할 수 있습니다(힌트: instanceof ). 예를 들어 DOM 이벤트에는 event.target 사용할 수 있습니다. 다른 플랫폼은 정적 유형으로 작업하는 이점이 있으므로 이 "충돌"이 발생하기가 매우 어렵습니다(이벤트는 클래스의 인스턴스임).

어쨌든 이것이 VueJS 팀에 왜 그렇게 우려되는지 솔직히 이해가 되지 않습니다. 사람들이 $dispatch 사용에 대해 충분히 주의할 수 없다면 라이브러리를 사용하여 그들이 잘못하고 있는 다른 많은 것들을 찾을 수 있을 것이라고 확신합니다. 사용자가 부주의하지 않도록 "보호"하기 위해 어디까지 갈 것입니까?

부모에게 직계 자식이 하나만 있는 경우에는 괜찮습니다. 하지만 이 경우 템플릿에 리스너가 있는 $emit()도 실제 추가 작업이 아닙니다.

정직한 질문(저는 Vue를 처음 접했기 때문에) 모든 수준에서 리스너를 선언하는 것 외에도 체인의 모든 구성 요소에 대해 이벤트를 $emit 해야 하지 않습니까? 너무 짜증나네요.

결론적으로, 새로운 프로젝트를 위한 "공식 템플릿" 도입에 대해 vue-cli 의 문제에 대해 누군가가 말한 것을 인용하겠습니다(https://github.com/vuejs/vue-cli/issues/123#issuecomment-233071630).

공식 템플릿에 얽매이지 않는다는 것을 알고 계실 것입니다. 이것은 당신에게 자유를 주지만 동시에 더 많은 결정을 스스로 해야 하는 원인이 됩니다.

나는 결국 모든 것이 균형의 미터라고 생각합니다. 이러한 결정 중 우리는 모든(대부분) 사용자를 위해 얼마나 많은 결정을 내릴 수 있으며 사용자가 스스로 하기를 원하는 결정의 수 또는 결정을 내릴 수 있습니다.

나는 그 철학에 동의하지만, 이상하게도 _이_ 문제에 대해 내가 접했던 것과 같은 태도가 아닙니다. 그 댓글과 여기 댓글 사이의 대조는 자유로 귀결됩니다. 당신은 비록 좋긴 하지만 궁극적으로 결함이 있는 의도에 따라 선택을 취소하고 있습니다.

정말 원한다면 플러그인으로 직접 구현하는 것은 그리 어렵지 않습니다.

@yyx990803 그게 아마 _내가 하게 될_ 일... 아마도.

@LinusBorg 또한:

따라서 우리는 "글로벌 버스" 방법을 사용하여 이를 우회할 수 있는 방법을 남겨두고 가장 잘 작동하는 것으로 사용자를 안내하려고 합니다.

당신은 "조종하려고"하는 것이 아니라 강제하는 것입니다. :)

dispatch 및 EventBus 메소드를 사용하여 동일한 기능을 구현해 보셨습니까?
도움이 될 수 있습니다

@posva 할 계획이지만 기본적으로 일부 모듈에서 이벤트 버스 개체를 선언하고 $emit 원하는 다른 곳으로 가져옵니다. 아니요? 난 그게 싫어, tbh. 나는 분명히 그것을 어떤 일에 사용할 것이지만, 매번 하고 싶은 것은 아니라고 굳게 믿습니다.

어쨌든 이것이 VueJS 팀에 왜 그렇게 우려되는지 솔직히 이해가 되지 않습니다. 사람들이 $dispatch 사용에 대해 충분히 주의할 수 없다면,

음, 요점은 팀에서 아무도의 실제 쓰임새를 지적 할 수 없다고입니다 $dispatch() 가 (뿐만 아니라 다른 솔루션에 바람직이었다에 $emit() 뿐만 아니라, 버스, 또는 global state), 그리고 우리가 답변한 수많은 포럼 게시물에서도 이에 대해 볼 수 없었습니다.

이것은 주관적인 견해일 수 있지만 전체 팀이 "이것은 우리 경험상 항상 열등한 솔루션"이라고 생각하면 핵심에서 삭제한다는 것을 이해할 수 있습니다.

이 시점에서 실제 사례를 논의하기 위해 제안을 갱신하고 싶습니다.

나는 그들이 당신의 라이브러리를 사용하여 잘못하고 있는 다른 많은 것들을 찾을 수 있을 것이라고 확신합니다. 사용자가 부주의하지 않도록 "보호"하기 위해 어디까지 갈 것입니까?

이것은 물론 미묘한 질문이며 찾기 어려운 균형입니다. 우리는 경우에 따라 판단해야 할 것입니다.

부모에게 직계 자식이 하나만 있는 경우에는 괜찮습니다. 하지만 이 경우 템플릿에 리스너가 있는 $emit()도 실제 추가 작업이 아닙니다.

정직한 질문(저는 Vue를 처음 접했기 때문에), 모든 수준에서 리스너를 선언하는 것 외에도 체인의 모든 구성 요소에서 이벤트를 $emit해야 하지 않습니까? 너무 짜증나네요.

직접적인 부모-자식 관계에 대해 이야기하기 때문에 $emit() 한 번만 수행하면 됩니다.

깊이 중첩된 자식이 있는 경우 물론 모든 수준에서 다시 내보내야 하지만 반복합니다. 많은 중첩된 자식에 걸쳐 파견되는 상황이 실제로 필요하거나 다른 솔루션보다 선호되는 상황을 발견하거나 제시하지 못했습니다.

따라서 우리는 "글로벌 버스" 방법을 사용하여 이를 우회할 수 있는 방법을 남겨두고 가장 잘 작동하는 것으로 사용자를 안내하려고 합니다.

당신은 "조종하려고"하는 것이 아니라 강제하는 것입니다. :)

나는 우리가 당신의 삶을 조금 더 어렵게 만든다고 말하고 싶습니다 - 당신은 할 수 있습니다

• 동일한 것은 아니지만 대부분의 경우 유사한 동작을 달성할 수 있는 버스를 사용합니다.
• 이것을 플러그인으로 아주 쉽게 다시 구현하십시오.

우리는 당신에게 $emit() 를 사용하도록 강요하지 않습니다. 우리는 단지 당신의 길을 조금 더 어렵게 만들고 있습니다.

모든 Vue 인스턴스에 추가할 수도 있습니다. Vue.prototype.$bus = new Vue()
뭔가를 좋아하지 않는 것은 그다지 건설적이지 않습니다 ...
😄 여러분의 사례를 기다리겠습니다.

@posva

모든 Vue 인스턴스에 추가할 수도 있다고 생각합니다. Vue.prototype.$bus = new Vue()

나는 그것을 좋아한다. 꽤 똑똑하다.

무언가를 좋아하지 않는 것은 그다지 건설적이지 않다

나는 그것이 적어도 나를 위해 무언가를 사용하거나 사용하지 않을 것을 선택하는 꽤 유효한 기준이라고 생각합니다. 어쨌든 나는 이벤트 버블링이 그 자리에 있다고 생각하는 이유를 여러 번 말했습니다.

😄 여러분의 사례를 기다리겠습니다.

내 말은, 내가 정말로 필요합니까? 이벤트 버스를 사용하거나 모든 수준에서 리스너를 선언하는 아이디어가 마음에 들지 않는 상황에 대한 예를 들었습니다. 코드를 보고 싶습니까? 내 요점을 좀 더 명확하게 하기 위해 뭔가를 생각해낼 수는 있지만 이벤트 버블링은 대부분의 사람들이 유용한 것으로 평가할 수 있는 꽤 표준적인 것이며 이벤트 버스 또는 상태 관리자는 적어도 나에게 일종의 일종의 아무리 봐도 이해하기 어렵지만 힙스터의 영역처럼 보이는 패러다임 전환. 😄

물론 나는 그 마지막 댓글에 대해 농담을 하고 있다. 내가 전에 말했듯이, 나는 그들의 용도를 보고 확실히 그들과 함께 해결할 문제를 찾을 것입니다. 실제로 Ember를 사용하여 작업한 일부 프로젝트에서는 글로벌 상태 관리자와 정확히 같은 역할을 하는 "서비스"를 작성하는 경향이 있습니다. 나는 이것을 고의로 고집하지 않습니다.

저는 뷰를 정말 좋아합니다. 난 그냥 _사랑_하고 싶어, 알지?

또한 모든 구성 요소에서 이벤트를 $emit해야 하지 않습니까?

이벤트 버블링의 관점에서 생각하면 그렇게 합니다. 구성 요소 구성을 사용하는 경우에는 그렇지 않습니다.

예:

<div>
  <a-button @click="modalShown = true">Open modal</a-button>
  <a-modal v-if="modalShown">
    <a-button @click="modalShown = false">Close modal</a-button>
  </a-modal>
</div>

a-modal a-modal 및 두 개의 a-button 인스턴스가 단일 인스턴스의 "직접 논리적 자식"이기 때문에 a-modal 구성 요소는 a-button 구성 요소의 이벤트에 대해 신경 쓸 필요가 없습니다 a-modal , 중첩이 있는 복잡한 뷰 계층 구조를 가지고 있음에도 불구하고.

나는 지금 이 시점에서 나 자신을 반복하고 있다고 생각한다. 어떻게든 이 문제를 해결하도록 하겠습니다. 이 논의가 어떤 이유로든 더 이상 존재하지 않는 꽤 표준적이고 실용적인 것에 대한 몇 가지 해결 방법 을 언급하는 데 초점을 맞추었다는 것이 제게는 이상하게 보입니다.

@LinusBorg :

음, 요점은 팀의 누구도 $dispatch()의 실제 사용 사례를 지적할 수 없다는 것입니다.

이것은 고속도로 출구를 닫지 말아야 할 이유를 묻는 토목 기사처럼 들립니다.

그는 이렇게 말합니다. "이 경사로는 교차로로 이어져 사람들이 좌회전할지 우회전할지 혼란스러워합니다. 대부분의 사람들은 몇 년 동안 이곳에서 살아왔기 때문에 길을 알지만 새로운 시민은 종종 몇 년 동안 길을 잃습니다. 분이고 우리는 그것을 피하고 싶습니다."

"좋아요. 닫을 수 있습니다. 멋집니다. 다음 진입로까지 10km만 더 이동하면 됩니다. 제가 처리하겠습니다."

:) 답변해주셔서 감사합니다. 적어도 토론의 여지가 있다는 사실이 기쁩니다. 좋은 팀인 것 같습니다.

이것은 고속도로 출구를 닫지 말아야 할 이유를 묻는 토목 기사처럼 들립니다.

그는 이렇게 말합니다. "이 경사로는 교차로로 이어져 사람들이 좌회전할지 우회전할지 혼란스러워합니다. 대부분의 사람들은 몇 년 동안 이곳에서 살아왔기 때문에 길을 알지만 새로운 시민은 종종 몇 년 동안 길을 잃습니다. 분이고 우리는 그것을 피하고 싶습니다."

내 나쁜 비유도 추가하겠습니다. :) 내 견해로는 다음과 같습니다.

• "이 도로는 사람들이 생각보다 빨리 경주하도록 부추깁니다. 속도 제한은 거의 신경 쓰지 않습니다. 사람들이 속도를 줄이도록 범퍼를 추가해야 합니다."
• "하지만 과속으로 목적지에 빨리 도착하는 게 좋아요!"
• "물론, 몇 번은 도움이 될 수 있지만 우리는 1.5년 이상 동안 도로의 이 부분을 지속적으로 관찰했으며 사고의 양과 다음 오프 램프를 놓치는 사람들은 단순히 가치가 없습니다. 그 문제 중 하나가 입증되었습니다."
• "하지만 난 그 범퍼가 마음에 들지 않아!"
• 음, 목적지의 99%에 대해 이 다른 도로는 범퍼 이전의 도로만큼 빠릅니다. 이 도로를 이용하세요.
• "하지만 나는 이 다른 길을 _좋아하지__ 않아요! 전망이 좋지 않아요!"
• ...

무언가를 좋아하지 않는 것은 그다지 건설적이지 않다

나는 그것이 적어도 나를 위해 무언가를 사용하거나 사용하지 않을 것을 선택하는 꽤 유효한 기준이라고 생각합니다. 어쨌든 나는 이벤트 버블링이 그 자리에 있다고 생각하는 이유를 여러 번 말했습니다.

내 생각에 @posva 는 다음을 의미했습니다. "나는 이것을 좋아한다"는 것을 유지하거나 광범위한 사용자와 함께 라이브러리에 무언가를 추가하는 것에 대해 논의할 때 건설적인 주장이 아닙니다. 그렇기 때문에 개인적 취향 대신 논의할 타당하고 실제적인 사용 사례를 계속 요청합니다.

네, 당신이 완벽하게 좋은 고속도로를 폭파하고 고무 아스팔트로 다른 고속도로를 건설했다는 것을 제외하고는 당신이 어디선가 꽤 깔끔하다는 것을 읽었기 때문입니다. 또한 10km가 추가됩니다. :)

예제 정보: 재귀 구성 요소에 대한 원래 질문에 게시된 것이 괜찮은 것 같습니다. 이벤트가 포착되고 완벽하게 좋은 예가 있을 때 모든 수준에서 순서대로 무언가를 하고 싶다고 상상해 보십시오. $dispatch로 이를 수행하는 것은 매우 간단합니다.

코드를 보고 싶습니까?

예, 부탁합니다

@posva 이전 댓글에서 예를

예제 정보: 재귀 구성 요소에 대한 원래 질문에 게시된 것이 괜찮은 것 같습니다. 이벤트가 포착되고 완벽하게 좋은 예가 있을 때 모든 수준에서 순서대로 무언가를 하고 싶다고 상상해 보십시오. $dispatch로 이를 수행하는 것은 매우 간단합니다.

$dispatch() 와 함께

// recursive-child
<template>
  <recursive-child></recursive-child>
  <button @click="dispatch">Do something</button>
<template>

<script>
  export default{
    methods: {
      dispatch() { this.$dispatch('do-something') }
    },
    events: {
      'do-something': function () { 
         // do something, or don't
         return true // nessessary to make the event bubble up further. Don't like the un-expressivness of this
       }
    }
  }
</script>

$emit() 와 함께

// recursive-child
<template>
  <recursive-child @do-something="doSomething"></recursive-child>
  <button @click="doSometing">Do something</button>
<template>

<script>
  export default{
    methods: {
      doSomething() {
        // do someting, or don't
        this.$emit('do-something')
      }
    }
  }
</script>

그게 정말 더 나쁜가요?

하나 더 있어요? :)

알겠습니다. 재귀적이지 않고 여전히 그렇게 중첩되어 있다면 어떻게 될까요?

괜찮은. 여기가 새벽 5시인데 너 덕분에 힘든 하루를 보낼 거야. 나중에 더 좋은 내용이 생각나면 올리도록 하겠습니다. 그럼 당첨이 되셨거나 제가 관심을 잃으셨을 겁니다. :)

재귀적이지 않고 여전히 그렇게 중첩되어 있다면 어떻게 될까요?

당신은 추가해야합니다 @event= 각 템플릿에 리스너를 $emit() , 그리고 그렇게에 대한 $dispatch() 그것에 대해 그의.

이것은 장황함과 표현력을 강조하느냐에 따라 좋거나 나쁘게 보일 수 있습니다.

그리고 btw. 상황에서 부모까지 이벤트를 연결해야 하는 경우 다음과 같이 할 수 있습니다.

<child-comp @event="$emit('event', $arguments)>

• 당신은 이것이 구성 요소 사이에 수행하는 "결합"을 애도하게 될 것입니다.
• 표현력에 찬사를 보냅니다
• 그 외에는 입력하는 것이 조금 더 많지만 큰 문제는 아닙니다.
• 그리고 저는 여전히 실제 사용 사례를 통해 글로벌 스토어와 같이 다른 최적화를 사용할 수 있다고 주장합니다. 그러나 이는 개별 시나리오에 따라 다르며 예제 코드와 논쟁하기 어렵습니다.

어쨌든, 좋은 토론, 당신의 가치있는 잠을 즐기십시오.

@rhyek 처음부터 $dispatch 를 사용하기로 결정했기 때문에 해결 방법처럼 보이지만 그것이 목표는 아닙니다. 목표는 구성 요소가 적절한 유지 관리로 서로 통신할 수 있도록 하는 것입니다. 그 목표를 달성할 때 선호도를 제외한 모든 실용적인 장단점을 나열할 때 $dispatch 는 열등한 솔루션이므로 삭제했습니다.

또한 DOM 이벤트 버블링은 컴포넌트 간 통신과 근본적으로 다릅니다. "이벤트 버블링이 널리 알려져 있다"는 주장이 그것이 우리가 해결하려는 문제에 대한 좋은 해결책이어야 한다는 것을 의미하지는 않습니다.

나는 "나는 단지 그것을 좋아하지 않는다"와 논쟁하는 것이 어렵다는 것을 알기 때문에 이 스레드에서 논평을 마쳤습니다.