exportdefault{ data() {return{ id:1} }, ready() { setTimeout(() => {this.$broadcast('child-set-data', { id:2}); },1000); } }exportdefault{ props: { id: { type:Number,default:0} }, data() {return{} }, methods: { handler() { } }, events: { id() {this.handler(); } } }
这次是通过events来接收事件，效果是一样的。既然两者都可以，那如何优雅的选择呢，笔者觉得可以在数据功能上进行区分。比如上面的场景，是由子组件child在知道id改变后，在它自己的作用域里去执行handler()方法，handler可能是一个需要ajax获取数据并渲染到child组件上的函数，这时候就推荐用watch来监听id的改变了。如果handler所对应的ajax任务是在父组件完成的，父组件需要将拿到的一堆json数据传给child时，这时可以通过事件来传递。不过说到底，还是看使用者的习惯了，这两者都是可以的，只不过事件更多的是来触发外部环境的action。
管好组件的一亩三分地
用好prop的sync
上篇文章介绍过，组件间可以通过prop传递数据，而且使用sync还可以双向绑定：
这样id就是一个双向的了，子组件修改后，父组件也会修改，但这样做有时候会分不清到底是谁改的，也很可能会不小心就修改了父组件的值，所以在使用时要特别注意。
验证prop
子组件不该干涉父组件的状态
子组件可以通过$parent访问到父组件，也就是说它有权利去修改父组件的状态，但不建议这样做，虽然有时候是省事了，但是这让父子组件之间紧耦合，很难知道到底是谁来维护数据，而且你开发给别人用的组件，随意修改了父级的状态，这会让使用者不知所措。所以子组件应该只关心自己的数据，要修改父级状态时，通过$dispatch()方法派发事件来通知父级，由父级自己修改。
总结