Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Sly should allow the user to select different variants #35

Open
jacobparis opened this issue Jan 14, 2024 · 0 comments
Open

RFC: Sly should allow the user to select different variants #35

jacobparis opened this issue Jan 14, 2024 · 0 comments

Comments

@jacobparis
Copy link
Contributor

Context

There are many cases where a library will have multiple variants of its components and a user should be able to choose

  • icons frequently come in both solid and outlined sizes. This is currently handled in the registry for heroicons by combining them into heart-solid and heart-outlined suffixes for every icon, which works but is less than ideal
  • utility function libraries like Just have variants for ESM and CJS module formats
  • shadcn/ui has "default" and "new york" styles for its components, and Draft UI and Jolly UI could benefit from similar capacities to choose

Proposal

Add a --variant flag to the CLI that will allow the user to choose. This will be reflected as a field in the sly.json config for that library to allow users to omit the flag from their commands.

Interactively, when a user first adds a library they should be prompted to choose which variants they want to add. When there is only one variant, we could force them to choose every time (an extra enter press) or skip the selection screen. This would be similar to when you run sly add and you are prompted to choose one of your configured libraries, with an option to add/config new ones.

Risks

This model works as long as users are always choosing between variants, but fails if users need to combine variants. Adding the ability to choose fine-grained variant combinations, such as an "esm, non-rsc, dark mode only" button component would be neat, but that sounds very challenging to maintain and there's no real precedent for it. I think the single-variant approach plus allowing users to provide their own transformers for other changes solves most practical use-cases here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant