Which is the best approach to build on top of shadcn/ui?

[AndreaBarghigiani]

Hi all, I've been using this fantastic library for a while now, but I have always used it in side projects and little tools with a short lifespan.

Today, I would like to leverage it to build a new product for the company I am working in. I want to make the right decision that will keep the maintainability and the ease of use, and since I have not found discussions on this topic, I would like to discuss it with you.

On every "introductory video/article" you find around the web, it's obvious that having the component living in the ui/ folder of your codebase is appreciated. To be honest, this is what I like about it too, but the thing is that many developers talk about the fact that you can customize the component yourself to let it match the design you are working on.

The fact is that while this is a fine approach, you have to change the component that comes from the library, and it will break the diff command that you get from the CLI.

I know this is experimental, but I am trying to figure out the best approach to make it work. Right now, I see those different paths in front of me:

1. customize the component itself - by removing/adding the classes I need even if this will not keep the compatibility with diff
2. build my components on top of the shadcn/ui - this will let me customize them and keep the compatibility with the diff command, even though I believe I'll not be able to keep untouched all of them
3. don't use shadcn/ui at all - this will force me to use the Radix UI out of the box and "take inspiration" from the amazing work that shadcn has done here

From your experience, which approach would you take and why?

Thanks to anyone who will participate in this discussion.

[TJdhyani]

Need some love on this post.

[kresimir-coko]

I'm very curious about this myself. Not being able to style the button with an icon inside without overriding [&_svg]:size-4 is causing headaches.

I'd love to be able to customize some of the most commonly used components to match our styleguide so that they are as we want them by default.

Any thoughts, recommendations @shadcn ?

[AndreaBarghigiani]

Thank you guys for the interest, I'm back at this because I just saw a video where we are encouraged to override the styles of the component itself.

The thing is, and I tested right now with progress.tsx to be sure, that every time we use pnpm dlx shadcn@latest add [component], if such component is in our codebase the only option we have is to override it completely 🤔

I understand that we have a repository, and we can check the difference once we override that, but it's time-consuming.

Besides that, I've also noticed that we probably do not have the diff command anymore, and another issue that arise when we override the component we've customized is that we lose all the formatting preferences that we had in place.

That's why I was looking to find a proper way to extend the component we install/download from shadcn/ui.

Doing so will allow us to customize the components for our needs while updating them via CLI.

Any thought? I have to see if there are some open issues that will improve the situation.

[dkang23]

I made a custom cli that helps preserve custom component modifications when updating shadcn components.

It first determines the component's location by checking configuration files, then either installs it fresh using the shadcn-ui CLI if it doesn't exist, or if it does exist, creates a backup, gets the latest version, uses GPT-4o to merge your custom modifications with the new version, and saves the merged result back to the original component file.

Still testing

[nahoc]

sounds like a nightmare

[AndreaBarghigiani]

More than a nightmare I think that it should be something handled right from the CLI. We had a diff command back then, but it didn't work if you changed the code.

I totally understand that implementing a diff is a pain in the 🍑, but since looks like the project reached a kind of stable version where there are not plenty of new components implemented each day, maybe this could be something to work on now.

Unfortunately I lack experience in CLI tools as well as time for now, but I would love to at least be a beta user of such feature.

[dvzrd]

@AndreaBarghigiani I think the idea is to modify the ui components to fit your needs so I'd recommend doing so. If you want to keep a clean version of the ui library in your repo, you can always have a ui-mirror branch you can use to keep in sync with changes to the latest shadcn/ui registry.

You would need to merge your changes in ui-mirror branch to a feature branch or dev branch, keeping main and ui-mirror unconcerned of any conflicting changes they may have.

The workflow I would have for this is to use ui-mirror to add or diff components or changes to the ui library, committing them to git so they're tracked and then checking out a feature branch based off main/master branch, and merging ui-mirror changes into the feature branch and fixing any merge conflicts with your custom ui component modifications.

You should be able to sync ui-mirror and main while ignoring the ui directory using git rm - not really important though since the ui directory is what you want to maintain in the ui-mirror branch.

[AndreaBarghigiani]

This could be an approach, a different one will be to maintain a "wrapped" version of all components you install.

Both solution require plenty of work though.

Off course it all depends on how much you customize the component, but what I was after opening this discussion wasn't a "tool that does the job for me". Moreover I was after an official or advised approach on how to solve the update issue...

It's easy to say "the component lives in your codebase and you can customize it", and that's why I love shadcn/ui. But would be appreciated to have a suggested way about which steps to take in case of an update to a component that you use.

[leonardofaria]

Approach 2 is what I am doing here. In the past I have seen a design system built on top of Chakra. The app would use the components of the DS and a ESLint rule would restrict importing directing from Chakra. I think this is probably the best way to keep shadcn components isolated and upgradable.

[AndreaBarghigiani]

I'm starting to think that too, just wrap each component you use from shadcn/ui and customize it instead of the original one.

That way you'll still be able to update the library without losing the customizations.

A bit of a pain, but something that's even easier now that we don't need to track forwardRef anymore 😅