If you want this, but don’t have any specific thoughts, feel free to just smack that like button
I believe this is something that could take the “batteries included” nature of RedwoodJS to the next level.
This started as a thread in the Discord, and let me know if this discussion would be a better fit for an RFC on GitHub.
There are a lot of great starting points, such as:
- A CSS in JS library, such as https://stitches.dev/ (recommended by RadixUI) or https://griffel.js.org/ (used by Microsoft with FluentUI, built on FAST)
My vote here is for TailwindCSS, for a variety of reasons.
I believe we should probably support dark/light, but additional theming can come later. We would use the theming capabilities provided by whichever CSS library we use.
- Primitives – Radix UI - used by shadcn’s lib
- https://www.fast.design/ - Microsoft’s web UI system
- https://headlessui.com/ - library built by the TailwindCSS folks, it’s very nice but a bit limited
- React Aria - Adobe’s web UI system
Note that regardless of which we use, none are perfect, and certain components will need to use additional libraries.
- Simple MDX site - this is what shadcn did for his UI lib
- Storybook site - this is what FluentUI uses - https://react.fluentui.dev/
While the MDX site can be a little prettier, I find the functionality afforded by using Storybook to be worth doing. It makes it super easy to understand how to use a component, as it’s not a static site.
Additionally, I’m envisioning this project being built as a web-only RedwoodJS project. We could easily use the existing Storybook integration to create the documentation.
- On a CDN, where devs would use a CLI to install component(s) to, for example,
web/components/ui. Devs would then take full ownership over the components, adjusting them as needed. Components would need to be manually updated.
- As a library, which would make customization difficult but would make getting updated components easier.
I believe we should go with the former - this is what shadcn did, and why it was so popular. I feel this is more in-line with what devs are doing today, myself included - building up an ad-hoc library of components that get dragged from project to project. This library would take that to the next level.
Once we figure out the answers to the above, our tentative next steps are as follows:
- Build the infra for supporting this project - either setting up the library or the CLI, as well as the documentation site.
- Start creating components, and get the kinks in that workflow sorted out.
- Update the scaffolds to use this component library. I find that as is, scaffolds are more work than they’re worth, as you often need to go in and replace much of the generated code anyway.
Let me know what you think!