runem / web-component-analyzer

CLI that analyzes web components and emits documentation
https://runem.github.io/web-component-analyzer
MIT License
501 stars 61 forks source link

Using LitElement `styles` is considered as a property #213

Open NeilujD opened 3 years ago

NeilujD commented 3 years ago

I am working on a POC on my own and it seems like web-component-analyzer is considering static styles as a component property.

Example:

my-element.ts

...
@customElement('my-element')
export class MyElement extends LitElement {
    static styles = css`
        :host {
            display: block;
        }
    `
...

custom-elements.json

...
"properties": [
    {
        "name": "styles",
        "type": "CSSResultGroup",
        "default": "\"css`\\n        :host {\\n            display: block;\\n}\\n    `\""
    },
...

I am using web-component-analyzer 1.1.6 .

NeilujD commented 3 years ago

I've found out that declaring the styles property thought a getter solve my issue. Still I think this should be cover by default.

Example:

my-element.ts

...
@customElement('my-element')
export class MyElement extends LitElement {
    static get styles() {
        return css`
            :host {
                display: block;
            }
        `;
    }
...
blikblum commented 2 years ago

The same for defining properties static property as a class field

I had to change from

class PatientList extends LitElement {
  static properties = {
     patients: { type: Array, attribute: false },
  }
}

to

class PatientList extends LitElement {
  static get properties() {
    return {
      patients: { type: Array, attribute: false },
    }
  }
}
davidmaxwaterman commented 2 years ago

Is using a getter() a work-around, or is it there a way to exclude specific properties that are known to not be in the API?

muratcorlu commented 2 years ago

I'm also staggering with this. Do we really need to convert styles to a getter just for hiding it from web components definition?

oliveryasuna commented 1 year ago

Persists on 2.0.0-next.4.

A workaround would be to implement a new feature flag for @prop. Then, we could enable that and not member.