Description
Cloudscape brings in intl-messageformat, which adds ~40KB to the minified JS bundle. But the built-in internationalization functionality doesn't use it. The dependency is only needed if users provide raw ICU strings to the messages property in I18n.Provider, as in the "Supporting additional locales" example here: https://cloudscape.design/get-started/for-developers/internationalization/#supporting-additional-locales
Using that dependency at runtime is an anti-pattern: Even for folks who need to add messages for additional locales, they should be compiling those messages at build time (like Cloudscape does for its own built-in locales) rather than making the browser do it.
I've drafted a branch that shows how the intl-messageformat dependency could be replaced: https://github.com/TrevorBurnham/cloudscape-components/tree/streamline-i18n-parser On that branch I've changed the TypeScript type of I18n.provider's messages prop so that it no longer accepts raw strings. That means that folks using that functionality would get a build-time error instead of a run-time failure. Combine that with a straightforward migration path away from those raw strings, and you'd have a nice easy performance win.
Code of Conduct
Description
Cloudscape brings in intl-messageformat, which adds ~40KB to the minified JS bundle. But the built-in internationalization functionality doesn't use it. The dependency is only needed if users provide raw ICU strings to the
messagesproperty inI18n.Provider, as in the "Supporting additional locales" example here: https://cloudscape.design/get-started/for-developers/internationalization/#supporting-additional-localesUsing that dependency at runtime is an anti-pattern: Even for folks who need to add messages for additional locales, they should be compiling those messages at build time (like Cloudscape does for its own built-in locales) rather than making the browser do it.
I've drafted a branch that shows how the intl-messageformat dependency could be replaced: https://github.com/TrevorBurnham/cloudscape-components/tree/streamline-i18n-parser On that branch I've changed the TypeScript type of
I18n.provider'smessagesprop so that it no longer accepts raw strings. That means that folks using that functionality would get a build-time error instead of a run-time failure. Combine that with a straightforward migration path away from those raw strings, and you'd have a nice easy performance win.Code of Conduct