There is an issue with UI components in V0 where only certain props are cloned for the V0 fallbacks. Basically, if a V0 project uses Radix or ShadCN components, certain properties (in particular “asChild”) will not bubble up (technically bubble down) when V0 clones the components. The easiest way to explain this is with a useful example I built in V0 - and here is a summary : “v0 is intercepting our imports and providing its own implementations. The “shadcn” components we think we’re importing are actually v0’s fallbacks, but they’re not properly configured or wired up for some reason.” Here’s a link to the full example I put together to illustrate the issue - https://v0.dev/chat/v0-as-child-bug-RvfdAoGFPgx.
There is an issue with gitSync when working in a V0 project with components/ui files. Basically, there are a lot of reasons that users may want to modify the base UI components. However, gitSync in V0 will only work with modified components/ui files one way - V0 > GitHub. If you init a V0 project and gitSync a Github repo, it’ll initially save your custom components/ui files. But, if you make any changes to your Github repo that originated from Github or local, then it’ll delete your V0 components/ui files when the V0 sync action executes. This means that for any V0 projects that use custom components/ui files they can’t also use gitSync. This is a significant downside to using gitSync in its current form. Here is a repro of the issue using the basic newsletter prompt - https://v0.dev/chat/minimalist-newsletter-form-AEvJVRYXOFJ.
Since your reports are related, I merged them into one thread for better tracking.
Looks like what you’re describing is that v0’s fallback implementations for previews don’t properly forward all props to the underlying components. Something for the team to look into. Thanks for sharing the examples.
To get you unstuck for now, here are a few workarounds you can try:
- Export and install locally: Export your v0 project and install the actual shadcn/ui components in your local environment where the full implementations will work correctly.
- Manual prop forwarding: In some cases, you might be able to work around this by restructuring your component usage to avoid relying on
asChild. - Use alternative patterns: Instead of
asChild, you might need to use composition patterns that don’t rely on this specific prop.
1 Like
If anyone else comes across this while facing the same issue, please let us know and share any example chats or screenshots you can. That helps with investigations 
1 Like
Thanks for the response. My current workaround is to include a V0 knowledge rule to not use the asChild prop when generating new components.