feat: add defineStandardCustomElement api to make emit match standard customEvent #7787
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
close #7652 , close #7605
By comparing with standard
customEvent
api: https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent#syntax:this.emit
orsetup emit
indefineCustomElement
is missing some features of stantardcustomEvent
as following:detail
property:detail
can be any type in standardcustomEvent
but indefineCustomElement
additional event arguments (payload) can be only exposed as an array on the CustomEvent object as its detail property.customEvent
supports passbubbles
,cancelable
andcomposed
properties, but it isn't supported indefineCustomElement
.The above problem may be due to the
defineCustomElement
to make the component completely consistent with the vue component or it may be due to the inadequate consideration in the design, but now I think we need a api which completely matches standardcustomEvent
.In order not to affect users who now use
defineCustomElement
, I add an new api nameddefineStandardCustomElement
. It will exposed the second argument ofemit
to be the second parameter ofCustomEvent
. (The way can be adjusted, but I think the current way is more conducive to keeping consistent with the customer in the suitcase when it changes in future.) Now the behavior of this new api is as following:I hope you can consider it and make reasonable suggestions. Thanks!