I wouldn´t mind to contribute my templates!
2 Likes
@arimendelow , curious your opinion on @ditorodev’s proposal?
i read the proposal as shifting the focus from making a redwood ui lib to a focus of making well-paved paths to integrate existing react ui libs into redwood.
i’d personally vote for the second, but curious your thoughts ari
1 Like
@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 
).
I’m determined to make this library not just a tool, but a community-driven resource. Let’s build something amazing!
1 Like
I appreciate the thorough explanation. Love the passion here.
for the sake of clarity, the framing i’m seeing is that there’s two related paths here: 1) a better react comp lib and 2) better integration of existing react comp libs into RW.
I’m curious what you see in the better-react-comp-lib path as RW-specific? one thing i could see from your vid is around forms. i could see @redwoodjs/forms being leveled up. however, i think even that package isn’t as RW-specific as it appears on the surface. it mostly contains thin (but useful) wrapper comps around react-hook-form. there are a few places with RW-specific logic, but i think the last time i discussed that package with someone from the RW team (maybe it was @Tobbe?) they mentioned that some of the RW-specific things in there might not be as useful as they once were and maybe should be deprecated.
and thus your vision of building better comps around forms could be reworded as building better comps around react-hook-form. which would still be really freaking useful, but perhaps not RW-specific.
so i’m curious where you see RW-specific benefits in path 1 coming into play?
and just for the record, if the better-comp-lib path isn’t very RW-specific, it’s still a useful effort. b/c i share a lot of your gripes around comp libs and the few comps i’ve seen from this effort already are in the i’d def use that bucket for me personally. on the surface so far tho, i’d use them in any react project, not just RW.
1 Like
oh, and on the better-integration-of-libs-in-RW path, what are people’s thoughts around how that would look like? it sounds like it’s more than just adding options to that rw setup ui <lib> command. the output of rw g cell, rw g layout, rw g page, and rw g scaffold would need to be specific to the comp lib right? anything else that would benefit from knowing the comp lib you’re using?
1 Like
Thanks, Colby! 
I see how the lines can blur in this context. When we talk about a component library for Redwood, it encompasses a few key aspects:
- Designed with Redwood conventions in mind. This means:
- Including a Storybook story for each component
- Adhering to Redwood’s code formatting conventions
- Ensuring seamless integration with Redwood right out of the box
- A collaborative space where the Redwood community can actively contribute and share components.
Similarly, Shadcn’s library, though intended as part of a NextJS starter kit, is versatile enough to fit into most React projects, typically without much adjustment.
This really highlights the essence of React metaframeworks. While components from RedwoodJS or NextJS are technically compatible with any React setup, their real value lies in their thoughtful combination that significantly enhances developer experience (DX).
Instead of using Redwood, you could opt for Create React App and integrating Prisma, React Hook Form, GraphQL Yoga, etc. However, that approach would mirror Redwood already offers, and you’d lose a ton of time writing logic that isn’t specific to your app. The whole point of Redwood is the thoughtful binding all of these libraries and frameworks together, saving you the hassle of manual setup and dependency management.
Take form components, for example - as you pointed out, Redwood essentially automates the registration of form elements with React Hook Form (RHF), sparing developers the need to do it manually. It’s mostly the useRegister hook that’s a wrapper around RHF’s register.
Sure, we could use RedwoodJS form components in any project utilizing RHF, and there are countless other ways to implement forms with RHF.
But that’s the essence of Redwood: it’s a collection of these nuanced details. Individually, they might seem framework-agnostic, but when combined, they form a thoughtfully crafted metaframework.
So, yes - this component library, while broadly usable in any React project, is being developed with Redwood-specific usage in mind
We’re still in the earlier stages of the project life-cycle, but I’m already considering its market positioning. Your insights align perfectly with my thoughts. Instead of marketing it as “for Redwood”, it’s more about being “by the Redwood community, for any React project, but with Redwood in mind.”
One example of this is the Combobox component. Were this intentioned to be more framework-agnostic (less opinionated), usage would look something like this:
import { useController } from 'react-hook-form'
const {
field,
fieldState: { error: fieldError },
} = useController({
name,
defaultValue: selectedValue,
rules: { required: !props.nullable },
})
<Combobox
{...field}
{...otherProps}
/>
And useController would be just one way to do it, and you’d need to manually handle a lot of the form logic.
By declaring that this library is for Redwood, we’re able to include all that logic directly in the component, because Redwood has already made the opinionated decision on how forms should be built.
Anyway, I’m thrilled that you’re excited about this project! I’ll definitely keep you in the loop when it’s ready to start testing out 
Agreed, it seems as though there would be a crazy amount of logistics needed to make that work. +1 on wanting thoughts from others on this.
If and when this becomes a thing, I would love to work on this as well. I have a lot of experience building component libraries across the companies I have worked for.
2 Likes
Ooh okay!! Do you have any general advice?
We’re still working on my first pass of the library - we’re at ~20 components so far, and the main thing we’re learning is exactly what Adam said in this tweet about Tailwind Catalyst - that every new component affects at least one other.
So that’s why we haven’t shared anything here yet. And once we’re done with that first pass, we’ll definitely want feedback
Hey guys! 
just chipping in.
Love to see the discussion. Some thoughts from me:
radix-ui + shadcn: big fan (although not using it for 1 project because it involves react-native)
scaffolding: was nice at the beginning but I’m not using it for real projects. (but the main reason is the coupling of schema, sdl and services not the UI)
current ui options: Fully agree that it’d be nice to have an option that integrates better into redwood. (with scaffold integration?? 
)
1 Like