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

Rule proposal: no dynamic style references #14

Open
lencioni opened this issue Feb 17, 2017 · 7 comments
Open

Rule proposal: no dynamic style references #14

lencioni opened this issue Feb 17, 2017 · 7 comments

Comments

@lencioni
Copy link
Collaborator

Dynamic style references make code more difficult to understand and interfere with static analycis. This weakens rules such as no-unused-styles. It would be good to have a rule that prevents this kind of coding.

Bad:

styles[foo]
styles['foo' + bar]
styles[`foo${bar}`]

I think it would also be okay to disallow the following:

styles['foo']

Good:

styles.foo
@ljharb
Copy link
Collaborator

ljharb commented Feb 17, 2017

What about things that aren't valid identifiers?

I'd think that a string literal, or a template literal with no interpolations, should be permitted in bracket notation.

@lencioni
Copy link
Collaborator Author

What about things that aren't valid identifiers?

Can you give me an example?

I'd think that a string literal, or a template literal with no interpolations, should be permitted in bracket notation.

Sure, I don't really care much either way about this.

@ljharb
Copy link
Collaborator

ljharb commented Feb 17, 2017

':first-child'

@lencioni
Copy link
Collaborator Author

Why is that not a valid identifier?

@ljharb
Copy link
Collaborator

ljharb commented Feb 17, 2017

Because it starts with a colon and contains a hyphen

@lencioni
Copy link
Collaborator Author

The hyphen should be fine, and the colon is potentially fine--that all depends on the underlying implementation. In our case with Aphrodite, this isn't handled very well and results in a className that contains a colon.

But, it seems like these cases should be better handled by separate rules that dictate the shape of styles properties and not a rule that dictates the type of styles properties.

@ljharb
Copy link
Collaborator

ljharb commented Feb 18, 2017

I'm not sure I'm being clear - you can't do styles.foo-bar, you have to do styles['foo-bar'] - it seems like an eslint plugin shouldn't try to be too opinionated about dot vs bracket access, nor about the casing of the property names of the styles object.

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

No branches or pull requests

2 participants