Suggestion: lit-css support in styles / lit-html renderer

[web-padawan]

I have been following the progress in this repo for a while, so first of all must admit the great work (especially now when I'm looking through the docs). So let me submit an issue.

Looks like the @style is now accepting either CSS file or raw styles. This is handful, but there is an idea on my mind and I'm not sure where to implement it better.

I would like to add support for lit-css, which is a good way of sharing styles in a way compatible with LitElement. It basically can be already used with raw styles.

Here is the example how it is done in styled-lit-element by the same author: https://github.com/lit-styles/lit-styles/blob/6bea874af7f7b0dc5f8f5e5e5095a68c724792b9/packages/styled-lit-element/src/StyledLitElementMixin.js#L18

Questions:

1. Can we implement memorization similar to what styled-lit-element does via decorators?
2. Can we have same decorator applied to the class with different values? Use case is to split components styles into multiple layers, e.g. basic styles and "theme"
3. How do the inherited classes work with decorators? From what I understand, they should be able to help with organising code better than class mixins (used in Polymer)

[Lodin]

Hi @web-padawan! Thanks a lot for rating my work!

Regarding lit-css, I'm not sure I can see the profit it brings. I explored project from the top to bottom and still cannot get it. Maybe I'm missing something?

About your questions:

1. I believe it's already done. If you define something in the body of the decorator function before return keyword, it will be shared to the class definition and instance methods.
2. Well, for now you can apply multiple styles in the same decorator, not multiple decorators:

// this is currently allowed
@styles('/styles/theme.css', '.test {color: red}')
class MyComponent extends HTMLElement  {}

// this is currently disallowed
@styles('/styles/theme.css')
@styles('.test {color: red}')
class MyComponent extends HTMLElement {}

However, I think it could be easily added.
3) Well, inheritance with decorators has some tricks, but works fine. Actually, Corpuscule allows inheritance for elements marked with @element decorator, and it works fine. I just forgot to mention it in the documentation.

Comparing decorators with mixins I would say that decorators definitely have some advantages over mixins. The most important one: decorators don't pollute prototype chain. They changes current definition and don't create another one in between. It solves some issues I faced during development of this framework (it was based on mixins at the start). Well, decorators also:

• simplify definition of properties;
• allow to create almost external system like React does: users can use connectedCallback without thinking of calling super.connectedCallback;
• allow to get into constructor to fix it in accordance with Corpuscule needs.

You can do these things only with stage 2 decorators. Mixins and legacy decorators cannot do all points at once.

[web-padawan]

@Lodin the benefit of using lit-css is basically to share styles as ES modules, separate them from markup in a better way than e.g. Material Web Components are doing, and be able to use existing tooling, like stylelint-plugin-styled-components for linting CSS.

Thanks for the answer. I wasn't aware that @styles decorator can handle multiple values. Will try it out. Basically, what I would like to achieve is the ability to extend custom element, which is using @styles decorator, and provide another portion of CSS via adding @styles to the extension.

[web-padawan]

Closing this for now, as it is rather a question and not an issue per se. I hope to be able to experiment with the corpuscule till the end of the year, and will report my findings, or maybe ask more questions.

[Lodin]

@web-padawan, BTW I think you can use lit-css with @styles in a following way:

const module = css`.test {color: red;}` 

@styles(module.toString())
class MyComponent extends HTMLElement {}