Optimizations: Colors, CSS Exports, Types

[JeromeFitz]

Understanding this is from the peanut gallery 🥜

Was seeing the optimizations that @vladmoroz was making and wanted to see if I could be of any help.

Seems like the idea is to continually see how different ways of exporting could mean potential ala-carte ways for apps to import @radix-ui/themes and only use what they need (i.e., “advanced use-cases” from the changelog).

Let me know if you would rather these to come individually for discussion – or of course not at all too. 😂

It's been wonderful seeing the rapid progress and continued evolution of @radix-ui/themes!

Keep up the great work!

Colors

One idea was to further organize and breakdown colors:

• (refactor) Tokens > Color Organization JeromeFitz/radix-themes#1

This could further assist how styles could be imported:

• Tokens
• Utilities
• Colors
  • This PR is out of date, but would benefit from the recent wildcard CSS entry point.
  • This could be re-worked if an app would only want a subset of the colors
  • Edit: We are talking about tokens here. 😅
    • So I hesitate to optimize much further at the moment in regards to colors
    • Having all tokens available leads to greater flexibility with the purpose of @radix-ui/themes in my opinion.
    • This would help with organization but for advanced use-case imports, may be better suited to focus on components (next section)
• etc.

I have a PR made into a fork at the moment, as I wanted to see how it looked before spinning up a PR directly here.

Other Potentials

CSS Files

Moving away from yarn scripts to a singular postcss script.

• yarn build:css would call something like ./css-build.cjs

This could cycle through each .css file recursively also creating individual files for ./components:

.
└── dist/
    └── styles/
        └── components/
            ├── alert-dialog.css
            ├── animations.css
            ├── avatar.css
            └── ...

For those Advanced Use cases people would build off the Layout work being done:

• Import that initial Layout
  • Reset
  • Animations
  • Layout
• Then they could only import the Components that their application uses if they so choose individually

Recognizing "Complexity should be introduced when it’s inevitable"

• This would involve some complexity, but ideally no more than the existing esbuild scripts and would follow a similar path

This would be ideal for advanced use-case where applications know which Components they are using to not take the hit of those that they are not in their .css file(s).

Types

Exporting types with each Component.

Currently one needs to:

• import type { GridProps } from '@radix-ui/themes/dist/esm/components/grid.js'

Instead of:

• import type { GridProps } from '@radix-ui/themes'

Verify Tree Shaking

Similarly with next there is a difference in importing:

• import { Grid } from '@radix-ui/themes'

Versus:

• import { Grid } from '@radix-ui/themes/dist/esm/components/grid.js'

The former actually exports everything in the build (so any Component not imported`), the latter does not.

---

I hesitate (strongly) to put any of these down as "issues" as I think they may be hyper-specific to my use-case and I realize I am working with a rc. This may all be on your roadmap already.

If so I can happily wait and cheer from the sidelines. 🎉

Thanks again

[vladmoroz]

Hey @JeromeFitz, thanks for the suggestions. Good to see interest in something we are already working on.

One idea was to further organize and breakdown colors:

• (refactor) Tokens > Color Organization JeromeFitz/radix-themes#1

This is pretty much what I have in progress on another branch, allowing you to import just the colors you want:
https://github.com/radix-ui/themes/compare/vlad/refactor-colors?w=1

---

As for exporting individual component CSS, we've just looked into that, but realized that many components have dependencies on each other. For example, Button might compose Spinner when it is in its loading state, or Checkbox Card Group on top of its own styles has a dependency on grid, base card, and base checkbox styles. We probably won't do this, as there’s no clean way to solve it without significant compromises.

The real solution to the CSS file size issue is to wait until native CSS mixins are a thing, so that we don't duplicate the responsive styles across breakpoints. There are some promising proposals being circulated already. I'm less worried about CSS file sizes to be honest given that minified + gzipped all CSS is under 100 KB, which pales in comparison to a JS bundle of a typical React app that also is much costlier for the browser to parse per KB.

---

Types

Exporting types with each Component.

Currently one needs to:

• import type { GridProps } from '@radix-ui/themes/dist/esm/components/grid.js'

Instead of:

• import type { GridProps } from '@radix-ui/themes'

Instead of importing component types, we recommend to use React’s type utils, e.g. React.ComponentPropsWithoutRef<typeof Grid>

---

Verify Tree Shaking

Similarly with next there is a difference in importing:

• import { Grid } from '@radix-ui/themes'

Versus:

• import { Grid } from '@radix-ui/themes/dist/esm/components/grid.js'

The former actually exports everything in the build (so any Component not imported`), the latter does not.

We’ve debugged this quite extensively at WorkOS as all our front-end apps use Next.js and suffer from the same tree-shaking problem. In short, we concluded it was simply a Next.js problem as Radix Themes tree shakes fine with most other common dev tools.

We were going to look into restructuring the exports to support Next.js’s tree-shaking workaround introduced in 13.1, but that will probably come later. We also tried the optimizePackageImports option, but that didn't work out of the box for us.

[JeromeFitz]

Tight. Thanks for taking the time breaking down each one. 💯

• ✅ colors: Cool to see the colors branch! Excited for that PR (good call on not moving every comment over too 😆 )
• ✅ css-files: Aye, yea, makes sense. Thanks for sharing more details.
• ✅ types: Thanks for the tip on ComponentPropsWithoutRef will dive into that!
• ✅ tree-shaking: Ah, thanks for the info here too. Makes sense to me.

Closing the thread.

Thanks again for info, and continued best of luck on the road to 3.0!