Would you be interested in a RedwoodJS UI Library?

@colbywhite you’re definitely picking up on a primary idea being expressed in this thread - we want a quicker, more straightforward way to get set up with UI libraries in Redwood.

@Benjamin-Lee’s idea of creating bindings on top of existing libraries sounds super interesting, and I would LOVE to see a PoC of that.

Here’s a bit of context: The Shadcn library, initially designed for NextJS, as y’all know, works with any React app. I’m envisioning something similar for a Redwood component library. While it would leverage RedwoodJS’s unique features, especially around forms, the core components would be versatile enough for use with any framework.

But here’s the catch: integrating most UI libraries with RedwoodJS isn’t straightforward yet, and honestly, I haven’t been thrilled with the existing options. Through my experience in both large-scale and greenfield React projects, I’ve come to see some patterns as less than ideal. For instance, the compound components pattern used by Shadcn and TailwindCSS’s Catalyst – while great for building – tends to be verbose and counterintuitive in practice.

What I’d additionally love to see is a theming system that’s super quick to modify, something I’ve been experimenting with recently (check out my proof of concept here: https://youtu.be/r6f7GSTwVBw).

I’ve often found myself settling for components that are “good enough” because I’d rather focus on building the app than on crafting perfect components. That’s why I’m working on a new library – one that I’d be happy to use as-is, without any tweaks, a goal I haven’t seen met by current libraries.

I’m not here to ask anyone to build a component library for me. I’m doing it because it’s something I need and believe in. But I want this to be valuable for the community too. So, I’m eager to hear from you all. What code patterns have you found effective? What API designs make complex components easier for you? @ditorodev, @Benjamin-Lee, @dennemark, I’m especially curious about your experiences.

The same thing happened with OAuth support in dbAuth - @pi0neerpat created a great PoC, Rob wrote up a nice guide, and there were some great discussions around it, but nobody had the bandwidth to build something you could just drop into your own project - so while I was implementing OAuth for myself, I approached it with the intention to build something reusable by everyone.

My aim with this library is to provide simple, yet powerful APIs for components with minimal styling – easy to use right out of the box and infinitely customizable. I’m talking about moving from complex, multi-step implementations to straightforward, clean solutions. Take a look at these two screenshots, for example:

Imagine if every time you wanted to use a Combobox, you had to do the former (not to mention that the primitive used by the former, cmdk, doesn’t allow for multiselect :roll_eyes:).

I’m determined to make this library not just a tool, but a community-driven resource. Let’s build something amazing!

1 Like