Updating to RAC 1.11.0 Introduced Issues, A Summary

[BMCwebdev]

I’m writing this post to share our findings and the paths we are pursuing to solve a set of issues that appeared after updating our project’s react-aria-components dependency to version 1.11.0+. While we are not certain of the exact commit, all of our issues began when we updated from version 1.10.1 to 1.11.0. We’ve found the root cause to be the intersection of our component patterns and the changes introduced in React Aria Components, which we suspect is related to PR #8327 “Pass through more DOM events and attributes”.

We’ve observed the following critical issues:

1. Severe Performance Degradation in Storybook: Our components were experiencing unusable lag in Storybook. This lag was especially noticeable with the Storybook “Docs” control panel. It only affected the specific story on the page that was controlled by that panel. The same components perform flawlessly when tested on our Vite dev server, leading us to conclude that the problem is a compatibility issue between RAC 1.11.0+‘s new event system and Storybook’s rendering environment.
2. TypeScript Interface Conflicts: Updating RAC introduced a series of TypeScript compilation errors. We found that interface intersections in our polymorphic components (like our Button component that can render as a button or an a tag) and other components (like Dialog) resulted in type conflicts due to new properties added by RAC 1.11.0+. For example, with our Dialog component, our users only need to use <Dialog>, as it automatically wraps itself in a Modal. As a result, our Dialog component needs access to both modal and dialog props.
3. Event Handling Conflicts: The addition of onClick as an alias for onPress in RAC 1.11.0+ caused conflicts with our existing Storybook utility functions that used onClick handlers, which contributed to the performance issues we observed.

Paths We Are Pursuing

Based on our investigation, we are pursuing a few different paths to solve these issues. We have had some success with these so far.

For Storybook Performance

We found that directly passing args from Storybook’s controls to the component was the cause of the performance issue. We discovered a pattern that avoids this problem:

• Never spread {...args} onto RAC components.
• Destructure specific props from args explicitly.
• Manage stateful props (like value, selection) with React state.
• Pass props individually to the RAC component.

This is exactly what our TileGroup component story was doing, which is why it worked without issue while others did not. The performance regression in RAC 1.11.0+ appears to be triggered specifically by the args spreading pattern, likely due to PR #8327’s DOM event passthrough changes.

For TypeScript Conflicts:

• Polymorphic Components: We resolved the TypeScript issues in our Button component by refactoring it to use a discriminated union pattern with an explicit as prop to properly distinguish between button and link types.
• nterface Conflicts: For our Dialog component, which was experiencing conflicts with properties like onAnimationEnd, onTransitionCancel, and others, we had to use a specific Omit<...> pattern to get it to build:

export interface DialogProps
  extends Omit<
      RACModalOverlayProps,
      | 'children'
      | 'className'
      | 'style'
      | 'isEntering'
      | 'isExiting'
      | 'onTransitionCancel'
      | 'onTransitionCancelCapture'
      | 'onTransitionRun'
      | 'onTransitionRunCapture'
      | 'onTransitionStart'
      | 'onTransitionStartCapture'
      | 'onTransitionEnd'
      | 'onTransitionEndCapture'
      | 'onAnimationEnd'
      | 'onAnimationEndCapture'
      | 'onAnimationStart'
      | 'onAnimationStartCapture'
      | 'onAnimationIteration'
      | 'onAnimationIterationCapture'
      | 'onAnimationCancel'
      | 'onAnimationCancelCapture'
      | keyof DOMAttributes<Element>
    >,
    Omit<RACDialogProps, keyof DOMAttributes<Element>> {
  children?: ReactNode | ((opts: { close: () => void }) => ReactNode);
  footer?: ReactNode | ((opts: DialogRenderProps) => ReactNode);
  headingText: string;
  isDismissable?: boolean;
}

Final Outcome (so far)

With these changes, our build now completes without TypeScript errors, and our components that we have worked on so far are performant and smooth in Storybook. The issues we encountered were not with the components themselves but with how they interacted with the Storybook environment and our existing code patterns in the new version of React Aria Components.

We hope this information is helpful to others who may encounter similar issues when migrating to react-aria-components 1.11.0+.

[snowystinger]

Thanks for the write up. What version of Storybook are you using? Also, are you using auto action generation based on the types?

[BMCwebdev]

Storybook Version: 8.6.12

Auto Action Generation, I did not think of this at all. Yes - We are using auto action generation based on types:

• In .storybook/preview.ts actions: { argTypesRegex: '^on[A-Z].*' }
• In .storybook/main.ts: Using react-docgen-typescript with TypeScript reactDocgen

Additional Context:

• TypeScript docgen: react-docgen-typescript with custom prop filtering
• Prop filtering: Excludes aria props and specific excluded props (onCopy, onCut, onPaste, etc.)
• Action matching: Any prop starting with "on" followed by a capital letter gets auto actions

This auto action generation combined with the args spreading pattern ({...args}), are you thinking that that could be what's triggering the performance issue? The auto-generated actions for event handlers might be conflicting with RAC's DOM event passthrough system?

Thank you 😄

[snowystinger]

We also ran into issues with the auto action generation. We're opting to remove it and only include specific events #8844

And yeah, actions can really slow things down, depends on what the action is and how frequently it's triggered. Each one has to be serialized to be passed out of the iframe. This is expensive and blocks the main thread. You can make it more performant by changing the depth of serialization, but even with that, it can still slow things down.

Hopefully being choosey about the actions you include allows you to use the spread pattern again.

[BMCwebdev]

Thanks very much @snowystinger ! I think I am going to try just removing the auto actions entirely for now (we don't really use the feature anyways). See if that allows me to keep my current pattern of using {...args} spreading pattern, Docs Control Panel, and paired stories.tsx and .mdx files. As much as I want to rip apart my current Storybook and start over, I'd be very happy to not have to do that right now 😃

I'll follow up here after trying it in case the info is useful for anyone.