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

Decide on correct variants convention #50

Open
gg-phntms opened this issue Apr 30, 2024 · 1 comment
Open

Decide on correct variants convention #50

gg-phntms opened this issue Apr 30, 2024 · 1 comment

Comments

@gg-phntms
Copy link
Contributor

gg-phntms commented Apr 30, 2024

Docs recommend selector.Component_variantName, but we've been using .Component_VariantName in most projects. Is there a reason for one over the other? Is there another alternative that we could be using?

@gg-phntms
Copy link
Contributor Author

gg-phntms commented Apr 30, 2024

Summary of conversations up until now:

SELECTORS

  • ❌ Selectors (e.g. div.Component, a.Component, etc) unnecessarily increase specificity
  • ❌ Adding selectors means you need to update them in both styles.ts and styles.module.css whenever you need to change them - it's easier to leave it as .Component and only update in styles.ts.
  • ✅ Selectors are required to be able to use the CLI command that autogenerates styles.ts. There is however an ongoing discussion as to whether to keep the CLI command; if we get rid of it we should 100% stop recommending that selectors be used by default.

VARIANT CASE

  • 🔶 We have used PascalCase for pretty much every project so far
  • 🐪 Using camelCase means that any props generated by the CLI tool will also be camelCase, as per convention - <Panel wide> vs <Panel Wide />. Again, this is irrelevant if we get rid of the CLI tool.

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