Would you be interested in a RedwoodJS UI Library?

Get Involved Contributing
1

Is there community interest in a UI library specifically for Redwood?

If you want this, but don’t have any specific thoughts, feel free to just smack that like button :slight_smile:

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:

Questions we need to answer:

How do we want to style these components?

My vote here is for TailwindCSS, for a variety of reasons.

Do we want to support theming?

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.

What component primitives library do we want to use? Some options:

Note that regardless of which we use, none are perfect, and certain components will need to use additional libraries.

How do we want to document our components?

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.

How do we want to distribute these components?

  • 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.

Next Steps

Once we figure out the answers to the above, our tentative next steps are as follows:

  1. Build the infra for supporting this project - either setting up the library or the CLI, as well as the documentation site.
  2. Start creating components, and get the kinks in that workflow sorted out.
  3. 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.
  4. ???
  5. Profit :money_with_wings:

Let me know what you think!

11 Likes
2

Thanks @arimendelow for creating the post!

I love the idea of having this as an scaffold, but would also love to have as a set of customizable components this is why @shadcn/ui is such an appealing library for this idea, I would like us to follow a less traditional approach and provide a set of components that can easily be configurable in various ways, radix-ui recently did this with their release of Themes you can do quite a bit of configuration to colors(accent + greys, this impressed me a lot), shapes and sizes. I would say taking from their ideas we could go a bit further with something like TailwindCSS + @shadcn/ui

The way im imagining the setup is the following:

  • npx run redwood-ui add <component> — same as @shadcn/ui but compatible with the new theming suggestions (as talked on the thread it would be based on the tailwind.config similar to how daisy-ui has its own tailwind.config field

  • npx run redwood-ui install scaffold — this is where the juice is, this command does:

    1. Create a components/ui/ folder same way @shadcn/ui does, this will add all the components required for scaffolding (would love to find an intelligent way of doing this so it only adds the components that are necessary)
    2. Rewrite all the necessary templates for scaffolding (here)
      - The templates will use the components from components/ui (leaving it to the user to edit and customize to their liking)
      - In terms of Atomic Design, each template would be… well just that, a Template (:sweat_smile:) see
    • This will allow developers to get pretty components by default + the chance to customize them to their liking by being able to go into each component/ui file and style or even delete a pretty good primitive, installing. This will effectively save them the hurdle of having to write the layout and connecting dots, making the scaffold command even more useful than it is today.

Based on the above to answer the questions made here:

  • Do we want to support theming? Absolutely should support dark/light theming and leave it to the developer to decide wether they want it
  • What component primitives library do we want to use? I’m all in for Radix-UI, it is super well tested and pretty much a standard in the industry right now. I also really like React Aria and they recently launched their components library(in Beta) I also blindly trust Devon on anything he works on. So TLDR; n1 is radix-ui and n2 would be React Aria
  • How do we want to document our components? I love how @shadcn/ui does it, a storybook site for me is very confusing, I once worked with the fluentui lib and it was awful everytime I had to go there. With shadcn/ui it is all a search away + it is really well documented, so I would copy their formula
  • How do we want to distribute these components? A CLI thru npx + copy/pasteable components in the documentation (not only how to use them but also copy/paste into your project) like @shadcn/ui does
2 Likes
3

Agree on everything! Surprised that you found Storybook to be confusing, though - what specifically did you struggle with there?

One clarification - I agree on it being a set of customizable components, what I meant with the scaffolds is exactly what you said - update the existing scaffolds to use these components. This would mainly be a way to supercharge new RedwoodJS projects, existing projects would more likely just install the components that they need as they need them.

On distribution, do you have insight on a good way to do this? I was thinking of factoring out shadcn’s work to create a reusable version of the system that they built, as I think that’s the primary thing that they got right with their lib and at a cursory read I don’t think there’s many changes I would make.

4

Agree on everything! Surprised that you found Storybook to be confusing, though - what specifically did you struggle with there?

It was just very hard to understand how their systems worked and how things played together, could also be a thing of how the design system is laid out (it has like 100 colors and names lol). One thing I really appreciate on shadcn is the fact of just entering on the component I want to use and be able to see a write up of what it is, how to integrate it into my codebase, how to use it in different scenarios.

I think storybook could be done like that too right? Guess is more of a information structure thing than anything else

On distribution, do you have insight on a good way to do this? I was thinking of factoring out shadcn’s work to create a reusable version of the system that they built, as I think that’s the primary thing that they got right with their lib and at a cursory read I don’t think there’s many changes I would make.

I dont understand what you mean with distribution here. If it is what I think then it is just making an npm package and hooking it up to npx runners so to use it is just a thing of having the webpage open and running the commands from the CLI?

When you say factor out shadcn/ui you mean reuse their work? I like that idea and we just make some small changes like adding new components, adding our theming system and doing the scaffold command!

5

Yeah, fluent/griffel are just super confusing. I believe we can do better :wink: We can even do Storybook in MDX, if we like.

It’s not quite as simple as distributing via NPM - whenever you do, for example, npx run redwood-ui add <component>, it needs to retrieve it from some kind of registry. For example, here’s shadcn’s: https://ui.shadcn.com/registry

So then, when you install a specific component, it pulls it from a URL like this: https://ui.shadcn.com/registry/styles/default/accordion.json

The question, then, is how we build the tooling to deploy a registry like that. That’s what I was referring to - we can totally just do what shadcn did for this. This also feels like functionality that should exist on its own, so I recommend we first tackle that sort of tooling as a standalone library.

2 Likes
6

Ah! This makes a lot of sense, I was thinking just packaging it with the CLI, but makes sense to make it go over the network. I can get a quick script that does this and publishes with github actions, im not sure if github pages has any support for CDNs but if thats not case and we later need an Edge Network I think we can just deploy a cloudflare page or worker and populate on their KV store

Love the way shad works tbh!

1 Like
7

I’m thinking we start by forking their repo and removing everything not related to publishing. Then, we can figure out what we want to keep/change with their process and turn it into an NPM package, which we can then use in the Redwood project that will host the components themselves.

I want someone from the core team to weigh in before we start really working on this, as maybe we’re missing something - if we don’t get any traction on here, I’ll attempt to get the conversation started at the conference next week :wink:

1 Like
8

Love the idea of bumping this up at the conference! That would help a lot!

In the meantime I made a small PoC of the registry using bun it even published to github pages (but is not really working for some reason lol), feel free to play with it, you can see the generated files over the gh-pages branch

To run the generation step just do bun run generator.ts

It is capable of detecting dependencies coming from node_modules and also is capable of knowing local dependencies too

The PoC is very rough and I think we should come up with a robust schema to solve problems like (as i discover more issue ill just add them):

  • Dependency resolving (caching them vs doing roundtrips for every dependency)
1 Like
9

I did not read the full post, just the title. My answer to that is no.

Having the framework tightly coupled to React is more than enough. From there I like to curate my own component or ui lib to fit whatever experience I’m trying to craft for the user.

4 Likes
10

Thanks for your thoughts @LeeGeorge!

What does your workflow tend to be? I’m guessing that you also don’t use scaffolding?

Do you use any component primitives to build your components, or do you just do vanilla react and handle all a11y issues etc. yourself?

I’m confident that we can build this in a way that would be useful to you! The idea with these components, as is the idea with scaffolds, etc (and Redwood itself, in many ways), is to make it effortless to handle the stuff that’s generally identical across projects. Of course, every project is different, which is why you retain full ownership over any generated code, whether it be a starting point for some common UI components or anything else.

Of course, it’s also possible that you enjoy going full-send into the unknown with every new project, in which case godspeed!! But if there’s any processes you find yourself repeating when starting a new project, I’m confident that we can build something useful to you. If you’ve every copy-pasted a component from one project into another, this solution is for you :slight_smile:

1 Like
11

I mean I hope so! Any improvement to the speed at which I work is certainly interesting to me (although there are often trade-offs).

So about my workflow:

  • I use generators for CRUD type pages that tend to be the “admin” section of my apps.
  • I use MantineJS as my go-to component library.

The way I view it is that MantineJS and similar libraries have a high enough level of abstraction to bang out a beautiful cohesive user experience, without having to fiddle around to much. I prefer it over things like tailwind which have a lower level of abstraction and e.g. have to be a bit more specific on how your element looks like. And it does not address behaviour for more complex components like input.

Drawback for me is that the Redwood has a “set-class” approach in e.g. forms to indicate an error state. While the Mantine input would expect a certain value for a prop.

So now that I have read your post I do think I might be interested in a batteries included dev experience with a redwood component library. I just feel I already have one by adopting MantineJS :slight_smile:

2 Likes
12

We’re using shadcn/ui in our Redwood app, and it feels like a good fit for the Redwood philosophy in that it comes with opinionated boilerplate but you can customize the code how you want. Redwood allows similar customization in scaffold code and I appreciate the ability to “eject” from the managed defaults and customize everything.

Similarly, shadcn/ui builds on Radix and Tailwind but allows you to change the markup and behavior of each UI element.

Regardless of what UI Redwood comes with, I think it’s important that people be able to choose something else. I started out using the built-in Redwood form helpers with uncontrolled HTML form elements before adding shadcn/ui components. Similarly, if Redwood shipped with e.g. shadcn/ui as the default, some users would likely want to choose something totally different, like MUI or Mantine.

Maybe the UI code could come from an optional scaffold that you run to quick-start a given UI toolkit in a Redwood project. For shadcn/ui, that would mean installing Tailwind and the relevant Radix component dependencies, then running the shadcn CLI with the correct config to install desired components in the right places.

4 Likes
13

I agree with you on your first point @LeeGeorge, one of the reasons shadcn/ui is proposed is due to its flexibility, it allows to use unstyled or themed components based on what the dev needs.

Now I reckon that shadcn and tailwind are a bit low level in comparison to other libraries like mantine or MUI maybe (this is out of the initial scope but)theres also a chance to introduce a better way to eject out of the Redwood UI scaffolding and make something similar to what shadcn has but instead of flexible styles it could do flexible components. Thinking if theres a well defined schema then it should be easier to make a powerful generator thats easy to configure for generating forms, this is also more in depth into the mechanism that generates and supports scaffolds.

Either way the entire idea of this proposal is to have a more flexible option to the current scaffolding so it is less of a pain to do redwood frontend with a custom flavor and style.

Maybe another proposal could be written on providing a generator thats less verbose and allows developers to set generators that can output their own custom flavor of a form without having to define it for each CRUD, just say something like “this is how a form should be generated, dependencies, hook and where to find each input component” basically just providing a specific well thought schema for how forms and other components can be generated from the scaffolding without having developers writing obscure template string based generators.

From adding such flexibility i can see an ecosystem being built out of component libraries where community members are able to maintain their own generators for their favorite flavor of ui library

2 Likes
14

I strongly upvote for the NO also. Please stay focus and don’t dilute maintenance in something who others are much better and specialized at.

1 Like
15

Are you saying I wouldn’t be good at maintaining a component library? :wink:

Tell me more about your workflow when you start a new project - what’s your process when it comes to all the basic components?

16

No, just saying that if a UI library is highly tightened within the framework that will bring a lot more maintenance needed for the community and as you know UI is just a wonderful jungle where we will never satisfy everyone, e.g. we love to use Chakra UI.

  • Of course, this is just a strategic point of view, take my message with all the kindness you can :wink:
2 Likes
17

I agree that a RedwoodJS library would not be beneficial, since the react ecosystem already provides great solutions and it should be in user land to decide, which one to choose.

More interesting would be templates for some of the ui libraries. I recently wrote some in Chakra UI.

Still like Chakra very much, since its close to simple HTML. Some components are missing, but its often rather easy to set up, like a comobobox. But I am a bit worried about the shift of development resources of the team to zag.js, panda and ark ui. Ark ui seems to be better suited for RSC. Really would have loved to see an integration of those three in chakra, as it was mainly planned. It might still even happen. But communtiy support for chakra is really low even none existent atm. Lets see what Chakra 3 will bring though…

Anyways thinking about RSC support, panda seems to be nice fit concerning styling. Having some recommendations in this direction would be great for new users. But could be too early for this. Since RSC is still early in development.

3 Likes
18

I too feel that a UI library would be a distraction at this point for the core team. Additionally, given the variety of existing UI libraries, what is more useful would be to come up with mechanisms that allow easy incorporation of setup instructions, page templates, icon sets, and app shells.

This could be a “contrib” style project that is guided by the team without necessarily detracting too much from the team’s core effort. At this point, I’m not entirely sure if this would involve actual changes to redwood itself, or would it just be a bunch of us community members picking our favorite UI libraries and work toward a common (and updated) set of reusables for those particular libraries.

To expand more on reusables, these are things like page templates, compatible icon sets, app shell/navbar/sidebar, avatar with account menu, account management pages, etc., stuff that are needed for most startup websites but takes away precious time from the actual business focus of a startup.

1 Like
19

I agree that this is out of scope for the core team. One thing that might be helpful is to have community libraries that add Redwood bindings on top of existing UI libraries.

I’m using shadcn/ui and I’ve had to do some modifications to make it play nicely with Redwood forms and toasts. I’m happy to share these changes in a blog post or forum post but perhaps it could be more useful to have a community-maintained implementation.

3 Likes
20

Ok, I think it is clear that this project is out-of-scope for the core team, I still think the ecosystem would highly benefit from a tool that allows the setup of different UI libraries for redwood. A community maintained UI package that generates custom templates for specific components libraries and is easy to use under a CLI.

The idea is simple:

  • Make a repository to hold all of the custom generation overwrites that currently work with Redwood, for more infomation check this for more info on how Discord
  • Make a CLI to install from the repository something like rw-components install <component-library-of-choice>, this will install all of the generator dependencies + install the overwrites so everytime a user does an scaffold it outputs the correct UI
  • For the repository a set of tests to ensure the quality of the package being submitted would be great, also leveraging code generations there could be a page showcasing how each and every one of those components look like so users can preview their implementations (if it is ever necessary)

I would love to see what you guys have implemented @Benjamin-Lee @dennemark @/ottobonn to draw inspiration or make the first releases if you guys are ok with it ofc

2 Likes