RAC production readiness

[aaronc]

I would like to integrate React Aria Components into our production code base, but I have a few questions about the roadmap:

• is there a timeline for bringing RAC out of beta and tagging v1.0?
• is there a plan to provide separate per component packages, i.e. @react-aria-components/Button, etc? or is this not needed because of tree shaking?

Knowing the timing of a v1.0 would be useful to know both for predicting API stability, as well as understanding the production readiness of the components (although I'm sort of assuming that RAC is production quality because of the react-aria foundation).

Regarding separate per component packages, even if this isn't needed to reduce the bundle size, I wonder whether separate packages would make it easier to tag stable versions. I acknowledge it could also make maintenance harder - just wanting to get a sense for the roadmap.

[reidbarber]

For information about each pre-release stage, check out this page: https://react-spectrum.adobe.com/Support.html#pre-releases

At this time it is in beta, so API changes are fairly unlikely at this point. Any changes would need a pretty significant reason.

As for the overall stability, the behavior of components are fairly stable due to being built on top of the hooks (which have been stable for a while).

is there a timeline for bringing RAC out of beta and tagging v1.0?

Not that I know of, but maybe someone else can chime in. I think we plan on moving the release on pretty quickly though.

is there a plan to provide separate per component packages, i.e. @react-aria-components/Button, etc? or is this not needed because of tree shaking?

There isn't a plan to do this, and you're correct, if youre bundler does tree shaking, you shouldn't get any components that you don't use included in your build. Even in our non-RAC packages, we encourage people to use the monopackages.

In addition to the extra maintenance required in order to maintain individual packages, I think there would be potential issues with mixing package versions and consuming contexts: https://react-spectrum.adobe.com/react-aria/advanced.html#consuming-contexts

[patricklafrance]

@reidbarber from my test, tree-shaking doesn't seems to work when using webpack as a bundler. Here's a reproduction: https://github.com/patricklafrance/rac-webpack-tree-shaking.

It kind of make sense that it doesn't work as according to webpack tree-shaking documentation, the tree-shaking is done at a file level.

Since RAC ship all the components in a single file, I don't see how that would work:

[patricklafrance]

Sorry tree-shaking does work, I forgot to add the TerserPlugin to my POC which is the one eliminating the dead code!

[devongovett]

Webpack doesn't do tree shaking on its own, half of it is done by the minifier as well. If you turn that on then it works. https://stackblitz.com/edit/github-vivarx-ejrghm?file=dist%2Fmain.js Inspecting the generated source map shows that it is only including the components that are used.

[patricklafrance]

@devongovett indeed! This is what I figured out an hour later that it requires the TerserPlugin 😓

Nice trick to look at the source map, I haven't thought about this one and it's way easier to test it that way. Thank you 🙏🏻

[tuananhlai]

If possible, I think a 'per-component' packages may make it easier for user to transition to. Some library using react-aria's hooks organizes their components into separate packages, and it wouldn't feel quite right to add a big library like react-aria-components into each of those packages. 💭

[patricklafrance]

Hey @devongovett, I noticed in the webpack tree shaking documentation that there are actually 2 layers of tree shaking:

• The first one is using sideEffects which is "native" to webpack and removes unused code at the "file level", meaning that it allows to skip a file/subtree when unused.

• The second one is usedExports which relies on terser to eliminates unused code, meaning that it allows to remove unused code within a file (which is currently how react-aria-components can be tree shaken with webpack)

I also noticed that react-aria code is shipped differently than react-aria-components by exporting independant packages from the dist/import.mjs file.

Therefore, to validate that webpack could tree shake without terser, I made a new POC using react-aria this time and indeed it does works. Because react-aria configures properly the sideEffect field, tree shaking happens without using terser.

Where Im I going with this?

Given that most applications which are being bundled by webpack will not use the TerserPlugin for development (and therefore not benefits from tree shaking for react-aria-components when in development), I was wondering if restructuring the way react-aria-components code is shipped to leverage webpack sideEffects tree shaking would help improve the performance when in development?

I am not sure if that would be significative enough to justify the time thought.

I don't think it would be mandatory to have multiple independent packages like react-aria does, I believe the following would work:

/dist
    /esm
        Breadcrumb.js
        Button.js
        Checkbox.js
        ....
    import.mjs

Let me know what you think!

Thank you

[patricklafrance]

My POC repository was private, sorry about that, it's been fixed.