Comprehensive Review of shadcn/ui - Is This React Toolkit Right for Your Project?

[@NedalKouissi]

I think the script for this video might be AI-generated because it contains a lot of incorrect information. 1. Instead of modifying the source of shadcn components, you should wrap them to create higher-level components. Use shadcn components as a base and only use them directly if you have nothing to add. This makes updating shadcn easier. 2. shadcn uses Radix UI primitives, not Radix UI components. These primitives come unstyled(no stitches, css ...), Later styles are added using Tailwind, not styled-components. 3. Managing Radix deps separately? No not true, that would be a nightmare.

[@techgirlinstyle]

Hi Nedal! thanks for your comment. Let's unpack this! First, of course I am using GPT to help me structure and wordsmith my scripts, however the facts are coming from my personal experience. 1. There are pros and cons in both cases. If you would like, say have an ability to occasionally update your components (aka. pull the latest version from shadcn/ui and overwrite the one you have locally: `npx shadcn-ui@latest add -a -y -o`) you should wrap them in a HOC. Hoverer some components are known to have issues even after the initial download. e.g. the select component actually have a functional bug that i had to fix in the source code before being able to use it. Overwriting my fix would mean revering to the broken version. This is a lot to keep in mind 3. Since Shadcn/ui is not an npm dependency, it is not added to your project.json upon installation. But the peer dependencies do! This means Radix-ui packages get added directly to your project.json file. Now it is entirely up to you how to manage them (fix the version, always get the latest, stick to a major or a minor version, etc) Here is my codesandbox that shows a clean project with only shadcn/ui initialized - you will find Radix UI dependencies populated in the package.json: codesandbox.io/p/live/f95df568-4d7f-46d7-8679-a205523e2fbe 2. You are actually right. I had experience using Radix UI design system github.com/radix-ui/design-system that was using Stitches for the styling of all components and theming. Looks like it was deprecated earlier this year and I missed the mark on this fact, I will publish a follow up to clear this out, thank you for this catch!

[@NedalKouissi]

@@techgirlinstyle 1. The example with the select component is quite insightful. From my experience, when dealing with buggy components, rather than editing the source code directly, I usually clone the component, apply the necessary fixes, and once the issue is resolved, I simply point my higher-level components back to the original version. This keeps things clean and manageable. (it's the same philosophy of shad, you build your own composable components) 2. You're absolutely right! Also, it's important to note that the shadcn CLI handles the setup and updates of its dependencies, many of which are tied to specific versions. For instance, "clsx: 2.1.1" is defined as a fixed release. So if clsx 3.0 is released and I manually force it, I must blame myself and not shad. To me, shadcn feels like a wrapper around an excellent set of low-level primitives and solutions (react-hook-form, radix, recharts, etc.). Approaching it with the mindset of learning what's underneath provides valuable insights and skills-something I can't say for other component libraries. Thanks again for the clarity, and I look forward to your upcoming content. Wishing you all the best!