useMenuTrigger adds a lot to bundle size

[susickypavel]

Hello everyone,

I was implementing a simple dropdown menu using useMenu and useMenuTrigger hooks.
I've noticed that when I add useMenuTrigger to the code, the bundle size increases by ~30kb. I thought this was a massive addition for a "simple" trigger state. I searched the source code and bundle to find out what makes it so large and found out that the useMenuTrigger has i18n support (great!), which is probably the cause of the massive addition.

Still, I think it's quite an overkill for my use case, so I stopped using useMenuTrigger and implemented my own useMenuTriggerState (based on react-aria) without i18n support and long press.

And I was thinking: do I violate something by doing that, or is it okay if I know that the majority of my audience will be English and I'm not planning in the near future to go international?

Thank you for this fantastic set of libraries 💖

[susickypavel]

I've got a new follow-up for the discussion here.

I managed to code-split my Menu component so that it can be loaded after the user interacts with the trigger button.

However, the code-splitted chunk is still massive (30kb gzipped), and I found out that a large portion of that size are i18n related modules that I'm not sure if I need at all. For example: @internationalized/date is included here for some reason I don't understand.

Tree shaking should work properly in the project. I also tested it on an empty Next.js project with the example Menu from docs, and the result is the same.

Below is a treemap of source maps of the code-splitted chunk, containing only Menu with Section and Items.

My question is whether the i18n is really for some usage here (from developer tools coverage, it seems that more than half of this code is not executed at all)? If so, what are they for? Otherwise, is there a way to remove them from the bundle/chunk?

[devongovett]

A few things we can improve here:

• i18n support for useMenuTrigger includes translations for a string used as an accessibility description. I think it would be nice if (a) you could choose which languages you wish to support rather than always including all 30+, and (b) you could opt out of this string completely if you don't use long press support. I'm not sure exactly how to solve this without overcomplicating the API though. If you have ideas, please let us know!
• It would be good to switch to a smaller i18n library. formatjs is quite feature rich, but large, and unnecessary in many cases. For example, in this case, the i18n messages don't do any fancy formatting (e.g. pluralization), so they are really just a map and such a formatting library is unnecessary. While this does amortize if you use many components, we can opt-into fancier formatting per component, so if you only use one you don't pay that cost.
• The dom-helpers library can probably be removed at some point since we no longer support IE11. We can replace it with simple native DOM calls.
• I'm not sure why @internationalized/date et. al are included in your bundle. They should be tree-shaken. useMenuTrigger only includes useMessageFormatter from @react-aria/i18n, but that package does have other exports for date/number formatting etc. But since those are unused, they should be removed by your bundler. You said this was Next.js? Any special configurations?

If you'd be interested in helping out with improving any of these, that would be awesome. Happy to help guide you. Otherwise, we'll get to them at some point in the future.

[chungwu]

@devongovett This -- bundle size bloat due to baked-in localized strings, and using a large i18n library like @formatjs -- is also a big problem for us. We're motivated to pitch in -- could you point us in the right direction to look?

[devongovett]

@chungwu Thanks for your comment, it would be awesome if you're willing to help out here!

I think we can break up the internationalization work into a few pieces, in order of difficulty:

Replace intl-messageformat with a smaller library.

This one should be doable fairly easily. A few sub-tasks:

• Many components have strings that don't have any fancy interpolations, so don't require MessageFormat at all. We already have MessageDictionary which will handle selecting the right strings based on a locale. I think we should add a new hook, useMessageDictionary, which is similar to useMessageFormatter (i.e. providing the same API), but without the formatting. This will allow many components to drop the dependency in intl-messageformat entirely (or at least, it'll get tree-shaken).
• For components that do have some interpolation, we still might not need a full MessageFormat implementation. For example, if there is no pluralization needed, we can just use a very simple interpolation. Not sure if there is a simple library for that out there.
• Look at alternatives for a full message format implementation. I am not sure what else is out there, but if you have suggestions, we'd love to hear them!

Allow users of React Aria to select which languages to include.

This will be harder, and may require breaking API changes. It may also make React Aria a little harder to use, but we can try to minimize this. We are open to ideas here if you have them!

One idea is to require translations be passed in using a messages option:

import {useMenuTrigger} from '@react-aria/menu';
import en_US from '@react-aria/menu/intl/en-US';
import fr_FR from '@react-aria/menu/intl/fr-FR';

useMenuTrigger({
   ...props,
  messages: {
    'en-US': en_US,
    'fr-FR': fr_FR
  }
});

This is somewhat tedious but would allow you to choose exactly which languages you want to support. In order to make it a little easier to get started, or if you do want all languages, we could offer an index file containing all languages.

import {useMenuTrigger, messages} from '@react-aria/menu';

useMenuTrigger({
  ...props,
  messages
});

This is a similar pattern to what we're doing for non-Gregorian calendar support in our new DatePicker hooks. You can either pass in the default createCalendar function which contains all of them or create your own with a subset.

One downside here is that this is a breaking API change. We'd prefer not to have to do a major version yet if we can help it. But if messages were not passed in, and we didn't have the defaults as we do today, then things would not work. One possibility would be to introduce an environment variable so that people could opt into this at build time.

function useMenuTrigger(props) {
  let messages = props.messages || (process.env.REACT_ARIA_DEFAULT_MESSAGES === 'false' ? null : DEFAULT_MESSAGES);
}

Then, if REACT_ARIA_DEFAULT_MESSAGES is set to false, bundlers should not include the default messages. A downside to this is that it would be one environment variable for all of React Aria, and not per-components, but not sure having many of them would be worth it.

Selective loading of translations

The above solution would allow applications to choose which languages they support, but ideally, we'd only load the translations actually needed for a particular user rather than loading all languages for all users. There are a few ways of accomplishing that:

• Asynchronously loading translations per component, i.e. import('@react-aria/menu/intl/${language}'). This may end up with many requests however, because there would be one bundle per component. And many of these only contain one or two strings.
• Manually batching translations for a page together at the application level.
• Something with server rendering, where the language would be detected server side and translations for all rendered components would be sent as part of the payload.
• Some kind of fancy bundling at the edge.

All of these are kind of application level concerns, but our APIs should hopefully be flexible enough to handle them. If you have any other ideas, please let us know!

Thanks again for your interest in contributing here. Let us know which of these are interesting for you to work on, or if you have any other ideas. If you want, we can chat over Slack or a video call if you need help or want to discuss this further about how to get started.

[devongovett]

FYI, #3294 will get rid of the intl-messageformat dependency entirely. The strings are precompiled to normal template literals, so we don't need a parser at runtime. That should reduce bundle size by ~40kb. Still planning on doing the other improvements eventually, but this is a start.

[chungwu]

Wow that's fancy 😍