Some components not 1-to-1 with shadcn/ui

[brandonmcconnell]

Some components are not 1-to-1 with shadcn/ui.

In the case of the combobox (shadcn | jolly), for example, one is a field you can click and type into while the other acts more like a button.

I think it would be most helpful if both the components and examples led a 1:1 relationship to shadcn/ui, especially if the goal is to be a direct and more accessible alternative until shadcn/ui switches to using React Aria or similar.

[jolbol1]

I see the point. In the case of the combobox, it was actually the first reason the library started, as the shadcn implementation relies on cmdk and seemed bulky for the simpler stuff.

I'll see if I can modify it to have a variant closer to shadcn and add some examples. If there's any other components let me know.

Another possible option is adding a callout where parity isn't possible.

[brandonmcconnell]

Also, for the existing variant, often when I click into the field the suggestions do not appear unless I specifically click on the arrows. It would be great if—at least by default—it revealed those suggestions when focused and filtered them as you type.

[jolbol1]

@brandonmcconnell for that you can change the prop menuTrigger to be "input". See Adobe docs

I will considering making this the default behavior and if not at least ensuring there is an example or its well documented.

Thanks for the input!

[brandonmcconnell]

@jolbol1 Thanks! I think it could really help to keep the baseline with consistent parity to shadcn/ui, as even slight differences could complicate a migration to jolly-ui in the future, unless the goal is actually to keep this package standalone and not merge into shadcn/ui at some point.

[jolbol1]

Hey @brandonmcconnell, I think it comes down to this:

To summarize and clarify the key points:

• All jolly-ui components will be built using React Aria, in contrast with shadcn/ui's use of Radix. This architectural difference makes it infeasible to have 100% parity in component composition and behaviour. But the styling system will remain the same, ensuring visual and CSS compatibility.
• At the same time, jolly-ui is its own independent library that aims to extend and complement shadcn/ui, especially by providing additional components built with React Aria that are missing from shadcn/ui currently. So it will have its own identity and life beyond just mirroring shadcn/ui.
• If shadcn/ui does switch from Radix to React Aria components in the future, jolly-ui would likely become obsolete. But in the meantime, it provides a valuable alternative for developers who prefer the React Aria component model.
• Any components added to shadcn, that utilise React Aria, I will make the version on JollyUI obsolete
• Any components that Jolly-UI has that shadcn does not, but later adds (without React Aria), I will rewrite to ensure the styling is the same.

Does this clear things up? Any more thoughts let me know!

[brandonmcconnell]

That makes a ton of sense! Thanks for clearing that up 🙂