最近在重新看vue3的rfcs，发现一个细节，原话如下：
props that start with on are handled as v-on bindings, with everything after on being converted to all-lowercase as the event name (more on this below)

props that start with on are handled as v-on bindings, with everything after on being converted to all-lowercase as the event name (more on this below)
也就是说，以后如果你在传递props的时候，以 on 开头的props，如果在组件上没有做props的声明，那么会被当作事件绑定到组件的根节点上。究其原因，我大致概括了两点：

兼容vue2中的v-on.native

vue3的vnode声明把props拍平了，为了区分事件和其他props，就统一把所有的on开通的props默认作为事件绑定
兼容vue2中的v-on.nativevue3的vnode声明把props拍平了，为了区分事件和其他props，就统一把所有的on开通的props默认作为事件绑定为此，我开了一个issue来讨论这个问题，issue地址 。我关心的主要有两点：issue地址

这是对functional component的严重限制

是否会导致一些令人括困惑的误解


这是对functional component的严重限制是否会导致一些令人括困惑的误解

先讲第一点
先讲第一点先讲第一点vue3中可以直接通过 function() {} 来声明函数组件了，这是一个便利性的非常大的提升。在以前，你要声明组件，你必须要：
{

functinal: true,

props: {},

render() {}
}


{

functinal: true,

props: {},

render() {}
}

这最大的提升来自不需要声明props，为什么说这是提升，因为这让我们开发HOC变得更方便了。现在我们可以通过 ...rest 的方式把HOC不关心的props直接向下传递了。但是现在因为这个默认限制，我们不得不在HOC中声明所有可能的他要扩展的组件以 on 开头的props。举个例子，我们有如下组件：
{

props: {

name: String,

onChange: Function

}
}


{

props: {

name: String,

onChange: Function

}
}

而我们的HOC的功能是在 name 前面加上 prefix ，对于这个HOC我们需要关心的只是 name 和他自己的props: prefix 。所以他的声明应该如下：
{

props: {

name: String,

prefix: String

}
}


{

props: {

name: String,

prefix: String

}
}

然后在render中他可以这么做：
{

render() {

const {name, prefix, ...rest} = props

return

}
}


{

render() {

const {name, prefix, ...rest} = props

return

}
}

也就是对于HOC来说，他是不需要关心他扩展的组件其他的props的，但是在这种情况下，如果我们不在HOC中声明，那么在使用的时候传入的 onChange 会自动绑定到root节点，而不是作为props传递下去。第二点：令人困惑的使用
第二点：令人困惑的使用第二点：令人困惑的使用举个例子，如果我有一个组件：
{

props: {

onChange: Function

},

methods: {

handleInput() {

// do someting

// 并且根据情况触发`onChange`

}

},

render() {

return

}
}


{

props: {

onChange: Function

},

methods: {

handleInput() {

// do someting

// 并且根据情况触发`onChange`

}

},

render() {

return

}
}

很显然我是想要封装 input 的变化，在满足某些条件的时候才对外抛出新的value。但是如果这个时候有人就是不看文档，直接传递了 onInput ，那么这时候 input 事件会直接绑定到节点上，那么这也是可以触发的。如果我们的测试用例太少或者不仔细，很可能反应不过来他们的区别。这显然是作为组件开发者的我们不希望出现的，但我们又无法限制这种行为。总结
总结总结不得不说，我在考虑这两个问题的时候是有一定的 React思维 在里面的。因为个人来说我是比较喜欢React的API设计的，非常的简洁，其对于组件的使用也更趋于极致，就是一切皆组件（连 redirect 这样的行为都定义成了组件）。而vue是一直在跟随react的，相信这点大家也不会否认。vue3更新的hooks（Composition）API，Suspense等明显是借鉴的React的概念。但同时我又是很看好vue3的，我一直觉得vue2这样的API设计以及 .vue 文件的开发模式都是为了吸引中低级用户而准备的，甚至舍弃了一些高级API特性（比如HOC在vue中就很难实现，并且普及率相当低）。而vue3的hooks API以及其对JSX的更好支持，还有更纯粹的 functional component ，让我一度看到了vue在工程方面更激进的变化。但是 v-on 的默认行为，却又是一次那么明显的 替用户做决定 的行为。其实要解决这个问题很简单，可以完全不考虑 v-on ，把所有传递的参数作为props，如果组件开发者真的要在根节点上绑定事件，他可以实现的时候绑定，我们不应该在使用组件的场景下需要考虑在组件内部的节点上做一些事情，这样做的副作用实在太大了。虽然目前看来尤老师会听取我的意见的可能性是非常小的，但我还是抱有一点简单的期望吧。