4 ms·
People do this and it's fine! Lit's just there to help once you handle more features and corner cases, and do this for 10's to 100's of components. We're hear
by spankalee 3y ago
People do this and it's fine!
Lit's just there to help once you handle more features and corner cases, and do this for 10's to 100's of components.
We're hear numerous times from developers who start with raw web components that the started to put common functionality into a base class, expanded their base class, then realized they were building a clone of LitElement, so switched to Lit.
That's fine too! Leaning on common, well-testing implementation is great, and being able to switch to it seamlessly is one of the benefits of web components.
- spankalee 3y agoI think a lot of people would still prefer to write and read the Lit version of that <like-button> too: https://lit.dev/playground/#gist=25ef7a5ea9b73406b4418ba59cf29c49 https://lit.dev/playground/#gist=25ef7a5ea9b73406b4418ba59cf... @customElement('like-button') class LikeButton extends LitElement { @property() liked = false; render() { return this.liked ? 'You liked this.' : html`<button @click=${() => this.liked = true}>Like</button>`; } }
- deleted 3y ago[deleted]
- dannye 3y agoTo make that a fair comparison Andrew his native code should be refactored to: https://jsfiddle.net/WebComponents/ovtc5wpx/ https://jsfiddle.net/WebComponents/ovtc5wpx/ customElements.define('like-button', class extends HTMLElement { static get observedAttributes() { return ['liked'] } get liked() { return this.hasAttribute('liked') } set liked(state) { this.toggleAttribute('liked', state) } constructor() { super().attachShadow({ mode:'open' }); } attributeChangedCallback() { this.connectedCallback(); } connectedCallback(){ this.onclick = (evt) => this.liked = !this.liked; this.shadowRoot.innerHTML = this.liked ? '<b>You liked this!</b>' : `<button>Like</button>`; } }); Now, a shadowRoot is a bit wasteful here, as inheritable styles *will* style shadowDOM. So we remove shadowDOM: customElements.define('l1ike-button', class extends HTMLElement { static get observedAttributes() { return ['liked'] } get liked() { return this.hasAttribute('liked') } set liked(state) { this.toggleAttribute('liked', state) } attributeChangedCallback() { this.connectedCallback(); } connectedCallback(){ this.onclick = (evt) => this.liked = !this.liked; this.innerHTML = this.liked ? '<b>You liked this!</b>' : `<button>Like</button>`; } }); To do that in Lit, you actually have to *ADD CODE* createRenderRoot() { return this; } Making the Lit code LONGER than the Native code import {html, css, LitElement} from 'lit'; import {customElement, property} from 'lit/decorators.js'; @customElement('like-button') class LikeButton extends LitElement { @property({type: Boolean, reflect: true}) liked = false; render() { return this.liked ? 'You liked this.' : html`<button @click=${() => this.liked = true}>Like</button>`; } createRenderRoot(){ return this; } } In real live projects you won't be nitpicking about these bytes and the 6K library/BaseClass Lit adds. Or the 7K lit-element. Or would you? When those bytes are added for each! component if you develop truly self-contained web components... Most Web Component Developers are still building Apps _with_ Components, not Apps _made of_ Components. When doing Native you will *ofcourse* develop your own *BaseClass* (like Lit is) And for 95% of your time you will just be doing Plain Old JavaScript code. Most Litters don't have a clue what is going on under the hood. Most Native developers just silently do everything native, they are not the type to evangelize their choice on Social Media. Their code will run without any issues, upgrades, or breakin changes, for the next 25 JavaScript years
- andrewmcwatters 3y agoThank you to both of you for posting your different takes!