Unable to specify shadow options easily without conventions

[brandonseydel]

🐛 Bug Report

Without using conventions there is no easy way to pass stylesheets as they need a raw loader passed through our shadow function

🤔 Expected Behavior

Pass stylesheets down into deps with a function wrapper or add a stylesheets array to the shadow options

😯 Current Behavior

n/a

💁 Possible Solution

@useShadowDom({ mode: 'open', css: [scss] })
@useShadowDom({ mode: 'open', stylesheets: [scss] })
dependencies: [shadowCSS(scss)]

🔦 Context

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Aurelia
Language
Browser
Bundler
Operating System
NPM/Node/Yarn

[bigopon]

if we are to go with

@useShadowDom({ mode: 'open', stylesheets: [scss] })

Do we need an equivalent of this in convention based template? cc @3cp @Sayan751

[3cp]

The shadow-dom is in options of @customElement. Why we need another decorator?

When not using explicit @customElement, you can use <use-shadow-dom mode="closed"> in html template.

I understand there is some difficult for user to manually control shadow-dom because the special setup in webpack config. We probably can recommend some naming conventions for css file name, so that webpack config can easily separate css that needs string-loader from style-loader.

[brandonseydel]

The shadow-dom is in options of @customElement. Why we need another decorator?

The deco already exists just no way to specify stylessheets or dependencies unless you fully deco with CE.

[brandonseydel]

When not using explicit @customElement, you can use <use-shadow-dom mode="closed"> in html template.

We have a deco for this but no way for stylesheets to be used conventionally without HTML involved

[brandonseydel]

I understand there is some difficult for user to manually control shadow-dom because the special setup in webpack config. We probably can recommend some naming conventions for css file name, so that webpack config can easily separate css that needs string-loader from style-loader.

I feel like the files should be able to exist anywhere and be used easily. I don't think a convention based approach will solve every case.

[3cp]

Agreed. We need to document it clearly so users will understand those css import cannot be processed by style-loader.

@useShadowDom({ mode: 'open', stylesheets: [scss] })

The other thought is do we need to expose other options in customElement in dedicated decorators?

@useShadowDom
@useCssModule
@dependencies
@tagName
@containerless
...

They also could be just static properties on the view module class?

[bigopon]

We have shadowCSS to register as a dependencies, I don't think we need more in the plain usage side. In convention side, importing css with <use-shadow-dom> will automatically be converted into a shadowCSS usage, I think we are also covered there. What is not there is convention without <use-shadow-dom>, css will not be considered as shared stylesheet, I think we can do something like

<import from="some-file.css" type="shadowcss">

if we need to.

Enhancing the useShadowDOM decorator with the ability to specify CSS stylesheet is good, but I think it's a bit uncertain whether we need that many options to declare shared shadow style.

While investigating this, I just realized elements automatically use global styles without an ability to say no. So if an element is using shadow dom, it may be forced to use some unwanted global styles from the application it is used in. We probably need an option to stop that.