I’ve been using webcomponents heavily in my latest project. Built out a full SPA using vanilla js. They are not without problems, but GitHub is using them perfectly. GitHub isn’t pushing them to do what they aren’t yet good at. They’re amazingly suited for consistent components, especially view oriented ones.
GitHub also has in my opinion made the correct choice to make their own base element rather than using a standard library one like lit-html. A good base element has two things in my mind - styled component functions and shared util functions specific to your app. It’s amazingly easy to make a simple set of styled component base functions. Here’s the one I made for my project: <a href="https://github.com/jjcm/soci-frontend/blob/master/components/soci-component.js" rel="nofollow">https://github.com/jjcm/soci-frontend/blob/master/components...</a> (lines 6-32 for the styled component functions). The rest of your component should be shared functions specific to your use case. Once that base class is there they’re so easy to use.<p>Two caveats with webcomponents however. The first is Safari will be the bane of your existence. You should dev in safari if you can. If it works there it will work in all other browsers. The second is stay away from form elements, for now. Or if you do, use an encapsulating component that inserts a slotted input into the light dom. The form registration api isn’t fully supported yet except by chrome, and even then it’s a bit rough around the edges.
WebComponents are an amazing replacement for jQuery, get the best of frontend Component based development without the bloat and the JS toolchain! Vanilla JS is great with WebComponents. We even write them in python with Ryzom's transpiler:<p>```<p>class DeleteButton(Component):
tag = 'delete-button'<p><pre><code> class HTMLElement:
def connectedCallback(self):
this.addEventListener('click', this.delete.bind(this))
async def delete(self, event):
csrf = document.querySelector('[name="csrfmiddlewaretoken"]')
await fetch(this.attributes['delete-url'].value, {
method: 'delete',
headers: {'X-CSRFTOKEN': csrf.value},
redirect: 'manual',
}).then(lambda response: print(response))</code></pre>
```<p>Speaking of which, Rails ViewComponent looks a lot like Python Ryzom, except the later optionnaly supports data-binding over websockets.<p>But writing JS in Python is extremely satisfying if you already like writing Python more than you like writing JS ;)
For my sideproject (<a href="https://profilehunt.net" rel="nofollow">https://profilehunt.net</a>) I have been using a somewhat similar approach. I use Github ViewComponents (<a href="https://github.com/github/view_component" rel="nofollow">https://github.com/github/view_component</a>) for componentization of Rails views. It helps with more modular views which are easier to debug (errors usually point directly to the line in view code, unlike Rails views). I use StimulusJS (<a href="https://stimulus.hotwire.dev/" rel="nofollow">https://stimulus.hotwire.dev/</a>) for Javascript interactivity. Stimulus is great, it allows me to write more structured reusable JS controllers without global event listeners and ids. For my project I have heavily used these two to create a Trello like board which behaves like an SPA. State and routing is still on server. I just fetch HTML on clicks and render it using Stimulus. It is usually fast enough as I only fetch small components and append them to DOM, but in case it's not I use loading animations.
If you want to take a look at how it is done, this blog post (<a href="https://boringrails.com/articles/hovercards-stimulus/" rel="nofollow">https://boringrails.com/articles/hovercards-stimulus/</a>) explains it really well.<p>edit: Fixed a link and grammar.
I do pretty much everything with Web Components these days.<p>It's so nice to be able to pick things I need from different frameworks, like Ionic, vaadin, Shoelace, etc... and they all just work together.<p>I tend to implement vanilla web components, I enjoy managing the life cycle and don't find it particularly burdensome. Of course. Lit-html is a big reason why that's easy to do. I use it for rendering. I generally avoid using the shadow dom unless I have a really good reason.<p>My components all self-register, and are pretty encapsulated. They all maintain internal state, but for more global state I use a library I wrote called ApplicationState [1].<p>It's hard to imagine going back to the framework churn after experiencing the freedom of Web Components.<p>It really feels like we've finally realized the promise of composability, reusability, encapsulation and performance with Web Components.<p>[1] <a href="https://claytongulick.github.io/applicationstate/" rel="nofollow">https://claytongulick.github.io/applicationstate/</a>
I was really excited about web components until I discovered that slots and CSS isolation are a package deal.<p>Absolutely great for the developer that wants to ship pre-built components that cannot be affected by the CSS of the site they're used in; absolutely useless when you want to make re-usable components for your <i>own</i> app, where you very much want slot content to be styled using the CSS you already have.
I'm currently working on testing a UI with Selenium that uses Shadow DOM all over the place. It's hot garbage, and I have no idea why anybody thought this was a good idea.<p>Something goes wrong in CI and you'd like to dump the DOM to figure out why? Too bad, the entire page is sitting inside a Shadow DOM, and you get to see an empty body tag and a timeout waiting for an element to appear.<p>Want to click that button that's nested 5 Shadow DOMs deep? Have fun creating a monster JS query to manually trawl though the Shadow DOMs to click it, because Selenium has no idea how to access the button. And that's if you're lucky and the Shadow DOM is marked "open". If it's marked closed, you can go sit on your thumb.<p>It's like someone looked at iframes and thought "hey, that's a great idea!" and never stopped to think why they were considered bad practice already 20 years ago.
Would love to see why they <i>did not</i> choose lit-element, it was one of the best I tried in a recent experiment of ~5 libs.<p>The big thing holding back webcompinents at this point is a data sharing strategy, and I think we could get away with actually using components to store and manage data:<p><a href="https://www.vadosware.io/post/sade-pattern-services-as-dom-elements/" rel="nofollow">https://www.vadosware.io/post/sade-pattern-services-as-dom-e...</a><p>The github repo (which also happens to contain how to write a web component in lit-element, slim.js, tonic, vue, svelte):<p><a href="https://gitlab.com/mrman/services-as-dom-elements" rel="nofollow">https://gitlab.com/mrman/services-as-dom-elements</a>
At my work web components were purposed recently for creating a ui component library of which I was skeptical. On the whole I was skeptical of web components viability and future but this post relieves some of that tension.<p>The other thing I was worried about was that it was planned to after writing this web component lib, to wrap these components in React. Does anyone have any experience or insights into a React wrapped web component lib?
I've refreshed myself on web components, templates and shadow DOM, and I understand how each of them works, but I only see immediate benefits from templates. The rest seems a bit like abstraction for abstraction's sake and syntax sugar over existing capabilities.<p>What am I missing, what's the elevator pitch for web-components and shadow DOM?<p>Scoped styles seems to be something that's pushed with shadow DOM a lot, but isn't <style> in the page body illegal HTML (despite yes, it works)?
We've started converting everything to web components using Stencil. Allows us flexibility to have the same look and feel no matter what framework we're using.<p>Took a minute to figure out how to get React/Vue components to render inside of a web component, but now we're all set.
I have a very dumb question. I'm currently trying to implement web components into a pretty basic flask site, and I'm really having trouble. Does anyone know any resources about basic implementation that I can review?<p>I was interested in Lit, and am try to bundle that, but it's not working at all, and I really feel like I'm missing something.
I started using ficusjs for some experiments [2]. I built a signature button for Metamask [1].<p>What's great is that:<p>- I use preact's htm as a renderer [3], which is JSX but as template strings.<p>- The API is like (p)react but a bit more generalized. I like it.<p>- The web component concept is great. Especially for mixing server-side rendering and JavaScript-powered components.<p>That last one IMO is web components killer feature. I can now wrote a mini component and then I tugg it in with the other 99% of my page that is rendered server side.<p>It means, I'm able to serve my users quickly. I have SEO'd everything too. Cool!<p>-1: <a href="https://github.com/TimDaub/web3-sign-msg" rel="nofollow">https://github.com/TimDaub/web3-sign-msg</a><p>- 2: <a href="https://docs.ficusjs.org/" rel="nofollow">https://docs.ficusjs.org/</a><p>-3: <a href="https://github.com/developit/htm" rel="nofollow">https://github.com/developit/htm</a>
In my side project I use Vue CLI's async webcomponents target to generate a webcomponents.js can be imported into a script tag and <some-element props="123"/>. I was at a loss how to include compiled SFCs (components) into a server rendered app. IME, Vue tooling assumes a Node JAMstack SPA and the Django boilerplates were a pain. Guys who wanted to sprinkle interactivity to their apps were at a loss.
Something I've never understood how to handle with vanilla web components: if there's some state that needs to be shared and kept in sync between multiple components, how do you do it?<p>(For comparison, in React you can pass the state down as props from a common ancestor, and in Clojure frameworks all app state is in a giant object referenced by components as needed.)
On the topic of web components, does anyone know if AMP is still using them? I heard they switched over to Preact but I couldn't find an official announcement.
"At GitHub, we pride ourselves on delivering a first-class developer experience."<p>Ugh, every time I see such PR-ese language, I want to stop reading any further