[mergeProps] Fix multi-argument event handler forwarding#4598
[mergeProps] Fix multi-argument event handler forwarding#4598atomiks merged 2 commits intomui:masterfrom
Conversation
commit: |
Bundle size
PerformanceTotal duration: 1,416.08 ms 🔺+59.39 ms(+4.4%) | Renders: 53 (+0) | Paint: 2,172.02 ms +45.22 ms(+2.1%)
...and 7 more. View full report Check out the code infra dashboard for more information about this PR. |
✅ Deploy Preview for base-ui ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@atomiks verified locally 🚀 . Thank you! |
|
@cgatian surprisingly, it was already broken before (in a different way), as I'm not sure what the blast radius of the regression is like in terms of how commonly this was used, or if your case was somewhat unique |
|
@atomiks Hmm we were using it with what would seem like a pretty common use case export const ConfirmDialogRoot: React.FC<ConfirmDialogRoot.Props> = (rest) => {
const handleOnOpenChange: AlertDialog.Root.Props['onOpenChange'] = (_open, eventDetails) => {
// code omitted for brevity
};
return (
<AlertDialog.Root {...mergeProps(rest, { onOpenChange: handleOnOpenChange })} />
);
}; |
Fixes #4597
mergePropsonly forwarded the first argument when merged handlers were called, so cases likemergeProps({ onOpenChange }, { onOpenChange })were already dropping secondary arguments. PR #4330 addedpreventBaseUIHandler()runtime wrapping for lone and first-position handlers, which widened the same behavior to cases that had previously worked, such asmergeProps({}, { onOpenChange }).This change forwards all handler arguments in both the merged-handler path and the runtime wrapper path, while still only treating the first argument as the synthetic event for
preventBaseUIHandler().Changes
mergeEventHandlers().wrapEventHandler().preventBaseUIHandler()behavior tied to the first argument.