Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

对于原生事件做白名单 #76

Merged
merged 3 commits into from
Mar 23, 2017
Merged

对于原生事件做白名单 #76

merged 3 commits into from
Mar 23, 2017

Conversation

dolymood
Copy link
Contributor

这样用户在自定义事件的时候可以直接写 @xxx 而不必须加上 .user 标识 @xxx.user

为了以防小程序升级 新增事件不在白名单内,在 wepy 没升级的前提下,开发者可以手工在 wepy.config.js 中加入 nativeEvents: ['newEventName'] 配置来解决不在白名单问题。

如果说自定义事件名是和原生事件冲突,例如 change 的话,用户依旧可以使用 1.4.8 版本方式 @change.user 来绑定自定义事件。

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.515% when pulling 58570ba on dolymood:native-events into 9e75736 on wepyjs:master.

@Gcaufy
Copy link
Collaborator

Gcaufy commented Mar 23, 2017

其实 .user是对于组件来说的,普通节点即便加上.user也是没有用的,组件上即便加@tap也是没有用的。
如果是需要自动识别的话,那为何不从这里考虑?

另外,这里是出于什么原因考虑觉得需要优化一下呢?反而我觉得保持@input@input.user的显式声明会不会在代码阅读时更清楚一些呢?这样阅读代码时我就不会用猜测这个事件是原生事件还是自定义事件。有些事件没有接触过我都不确定他是不是原生的。

@dolymood
Copy link
Contributor Author

对使用者而言,不管是原生事件还是自定义事件统一一种写法 @xx ,而不必去关心到达是不是自定义事件而采用不同的写法;或许区分自定义事件甚至可以使用其他简写方式,但是主流做法也就是wepy现在的做法,就是把自定义事件和原生bind事件都用 @ 这种方式简写,其实就是一种统一,而再进一步,把自定义事件和原生事件直接也统一写法。

这样剩下的还有一个问题就是事件名冲突的问题,一是一般情况下不会冲突,二是冲突了还有解决办法;但是这个其实是对开发者不够友好的,也是我欠考虑,不过我想这个可以更进一步来做,就是根据 tag 对应事件(最极端情况,也可以简略判断是不是已知tag,如果是且满足在事件白名单中则认为是bind,否则是自定义事件v-bind)。

这样做的好处就是把自定义事件和原生事件统一为事件,而在框架内部自己做了处理,开发者不需要关心是不是原生事件,都是一种写法,可以简要描述为:在自定义组件上的 @ 就是自定义事件,原生tag上的就是原生事件。

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.515% when pulling abf4362 on dolymood:native-events into 9e75736 on wepyjs:master.

@Gcaufy Gcaufy merged commit 352bd8e into Tencent:master Mar 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants