Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
So, properties exist on the DOM, which is the browser's JavaScript object representation of the Document, but they don't exist at all in the document's HTML markup.
One big difference between the two is that (for the most part), CSS can't see the DOM, it can only see the markup.
@customElement('x-l')classXElementextendsLitElement{@property({type:Boolean,reflect:true})schwifty=false;render(){returnhtml`
<button @click="${this.onClick}">
Get ${this.schwifty?'un':''}schwifty
</button>
`;}onClick(){this.schwifty=!this.schwifty;}}
Here, we use reflect: true in the property descriptor for XElement#schwifty to indicate that setting the property should reflect to the attribute.
That could be useful for a document author, for example with this css:
Another use case along these lines could be setting a disabled attribute, or setting ARIA attributes based on an element's DOM state. I set the error attribute based on a caught error's message property in <stripe-elements>, as a convenience while debugging.
You can similarly think of cases where a component author would specifically not want to leak internal state outwards to the document, like when some intermediate value is observed so that it causes re-render, while remaining a private 'implementation detail' of the element:
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Hey, sure
So, properties exist on the DOM, which is the browser's JavaScript object representation of the Document, but they don't exist at all in the document's HTML markup.
One big difference between the two is that (for the most part), CSS can't see the DOM, it can only see the markup.
Here, we use
reflect: truein the property descriptor forXElement#schwiftyto indicate that setting the property should reflect to the attribute.That could be useful for a document author, for example with this css:
Another use case along these lines could be setting a
disabledattribute, or setting ARIA attributes based on an element's DOM state. I set theerrorattribute based on a caught error'smessageproperty in<stripe-elements>, as a convenience while debugging.You can similarly think of cases where a component author would specifically not want to leak internal state outwards to the document, like when some intermediate value is observed so that it causes re-render, while remaining a private 'implementation detail' of the element:
Thank you!
Small edit to the second example: set
contentdescriptor withattribute: false, It can only be set with a property now