Personally I'd miss the JSX syntax, but this more than makes up for it by removing the entire whacky state vs. props thing. Although- how do you represent custom props here - arguments to the constructor? That'd be really elegant.
Do those styles and query selectors leak out of the component? I'm assuming they don't since that's the entire point of the idea of a component, but just want to be sure.
This was a stumbling-block of the fairly simplistic predecessors to the React/Angular generation - like in Backbone.js if you chose to implement 'render()' in such a naive way.
https://github.com/rishavs/Verdin/blob/master/src/views/comp...
I just wish that one of these days I will get off my ass and actually finish something that I start :D
What I don't like is this also shows (via the render method) how you can foot gun yourself if you aren't careful. Just slabbing in everything via `this.innerHTML` will lead to gross performance problems, among other things. There's also no real diffing (only matters on more complex concerns, in a way) so you're replacing everything just to update the count.
I know we're all suppose to know better (I doubt you did this except for the express purpose of showing just how simple the Web Component API can be), but I've seen example code end up in production more times than I can count, from all over the web, so be forewarned stewards!
<form>
<button onclick="form.counter.value -= 1;return false">-</button>
<input name="counter" value="0">
<button onclick="form.counter.value = 1 + +form.counter.value;return false">+</button>
</form>
Custom elements is just a mutation observer with callbacks, can be used with DOM 0 as well: class MyCounter extends HTMLElement {
connectedCallback() {
this.attachShadow({mode: 'open'}).innerHTML = `<style>...</style><form>...</form>`
}
}
customElements.define('my-counter', MyCounter)And the opinion has shifted from "this is the future" to "Web Component specs is aimed primarily at library authors, we don't expect people to author them by hand"