What is a Utility Web Component?

Or should it be called a Functional Web Component…

I previously wrote a post about the wc-upgrader and how we can approach loading vanilla web components. This is helpful for upgrading standard elements to Custom Elements that track internal state or show some sort of UI. While I was building it though I realized there is a much better approach in some circumstances, doing the same exact thing but letting the browser do it for you.

As part of the web component suite of technologies we have the custom element spec. This spec defines two categories available to us; Autonomous and customized built-in elements. Wc-upgrader was built with autonomous elements in mind because there is no upgrading mechanism. For customized built-in elements however there is.

This brings us to a host of neat new paradigms like an easy route to progressively enhance our websites from multi-page apps to single-page apps using a component driven approach without the need for a Javascript framework or view library.

In Practice (It’s Awesome!)

My first Utility Web Component is based around how we can send data back to the server. The initial plan was laughable from a design perspective. Initially the premise was to extend the form element and have a new attribute that would provide a secondary endpoint definition. If Javascript was available, the element that would get updated and use this new address to run a fetch() call. This of course is opinionated, non-flexible, and just doesn’t give us much benefit.

While that implementation was bad, the approach was on the right track. By default (no JS) we would send data to the endpoint defined in the form’s action attribute like any other request. If Javascript is available, the constructor for the Custom Element is able to execute which means our app has access to Javascript and we can begin to make it more SPA like. When the form gets upgraded, instead of sending the data to an endpoint it will instead pass it to the specified callback function as an object and the developers code figures out what to do with it. (Perhaps sending it to a server, a gRPC call, or something like Redux.

It’s probably easiest to visualize how this manifests by seeing it in action. Below we see the default behavior on the left hand side executing. This submits the data to an HTTP endpoint (that happens to return it as json) which results in a new page loading.

On the right hand side we see the enhanced behavior. Instead of sending the data to a server we consume it with our applications logic. In this demo we see a modal popup with the data that was submitted. Our Web Component would still work without Javascript but it gets better when Javascript is around.

Summary

So here’s the final answer. A Utility Web Component is a custom element that extends another element using the built in browser mechanisms that when loaded, changes the functionality of our application. If you want to learn more about how I implemented the demo you can check out the spa-form here.

I think Functional Web Component sounds better and your changing the function of your site but I’m concerned that it will be confused with functional programing. Let me know your thoughts. For now, I’m thinking we’ll call then Utility Web Components.

WC-Upgrader module

If you haven’t heard yet, Web Components are here, most notably Custom Elements. We now have a platform API for defining our own HTML elements and composing them in our projects. While the platform API allows for us to write native components they still have to be loaded into the browser which brings us to a problem.

What’s the Problem?

If we have custom element markup in our application such as:<custom-element>Some Text as a child node</custom-element> the Some Text as a child node will be the only thing the browser understands on initial load. This means we can potentially have a bit of a repaint (likely including layout) like shown below.

I wanted to take a progressive enhancement approach to this problem of jitter with web components. The premise of the idea is that the HTML is already there in a base configuration and gets updated to something new. If we have an h1 element and do the same upgrade we get a much more pleasing result.

The other bonus to this approach is how it differs from popular JS libraries like React. If a user has Javascript disabled a react site won’t render (unless done so server side) but if we take this progressive enhancement approach our base content exists and then we can spice it up dynamically if possible.

OK, that was the why, what about the how?

WC-Upgrader is a JS Utility that ‘upgrades’ elements to the specified custom element when they are defined.

My initial approach was to initialize a custom-element and then set it’s innerHTML equal to that of the element needing to be upgraded and then delete it. This was a simple approach but had a nefarious bug. If you have elements getting upgraded and then parent elements getting upgraded, the child custom-elements will be re-appended to the DOM meaning their constructor will execute every time. If a component isn’t properly optimized you can quickly imagine how burdensome this could become.

The solution is a little more zesty in that we manually move the node tree from the old element to the custom element one child at a time to avoid constructors re-running when they don’t need to.

Yeah… I meant how do I use it…

It’s pretty simple as its still in its infancy as best practices around web components continue to involve. You can check out the git repo and start hacking in just a couple of minutes. Looking forward to hearing your thoughts on this approach!