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: true
in the property descriptor forXElement#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 theerror
attribute based on a caught error'smessage
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:
Thank you!
Small edit to the second example: set
content
descriptor withattribute: false
, It can only be set with a property now