-
Notifications
You must be signed in to change notification settings - Fork 319
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
Style modules API #429
Comments
The reason that I think it's reasonable to flatten the array of styles and we'd accept a PR for that. |
Why do we need to support this when we have array spread syntax? It's prefer to not add code for things the language already does for us. |
One thing that would make flattening worth it to me is if we changed the |
I agree with @justinfagnani last comment. That provides a good relief solution for those who really want/need a single stylesheet method. |
Yes definitely make sense to support single |
Now that there is a new style system, I think it's good to consider how to create shared style modules. In Polymer we used to do this:
This way you could use
style-module-b
without knowing that it also composesstyle-module-a
.With the new
LitElement
style system, it would translate to this:This is a bit awkward, as the consumer of
style-module-b
now has to know that it is an array of styles and has to spread it:But this also means that
styleModuleB
could never change back to not being an array, andstyleModuleC
can never change to being an array of styles.We could solve this by making style modules always an array, even if there is only one entry. Another solution would be if
LitElement
flattened the styles array so that you don't need to worry about this.The text was updated successfully, but these errors were encountered: