[Go Make Things] A simpler way to build dynamic user interactions

By rahmat hidayat

Thursday, May 30, 2024

​ Yesterday, we looked at two different ways to build more resilient websites and web apps. Today, let's talk about how to add dynamic user interactions to static HTML. Let's dig in! Most of what we build is forms While there are clearly exceptions to this, a lot of the dynamic stuff we build is really just forms and server reloads. For example, my Lean Web Club coaching platform features buttons that users can press to bookmark tutorials or coding resources for quick access later. Here's how I make those fast, resilient, and easy to maintain as a developer. The default experience is a button wrapped in a form. The form also includes two [type="hidden"] fields that include the id of the content to bookmark, and the action to do: either remove or add the bookmark. <form action="/api/favorites" method="POST"> <input type="hidden" name="id" value="12345"> <input type="hidden" name="do" value="remove/add"> <button aria-pressed="true/false"> Bookmark </button> </form> When the user clicks the button, the form makes a POST to the URL specified in the [action] attribute. The server updates the user's bookmarks using the information from the form, then send them back to the page they were just on. The HTML sent from the server uses SSR to generate the bookmark form with updates values. No JavaScript is needed at all, but… I can make the experience a lot better with it. The whole form gets wrapped in a <fave-button> Web Component that listens for submit events on the form. Instead of reloading the page, it uses the fetch() method to contact the server, and updates the required fields once it gets back a response. <fave-button> <form action="/api/favorites" method="POST"> <input type="hidden" name="id" value="12345"> <input type="hidden" name="do" value="remove/add"> <button aria-pressed="true/false"> Bookmark </button> </form> </fave-button> I had previously been handling this whole interaction entirely with JavaScript. This new setup is faster, requires less code, is easier to maintain, is easier to reason about as a developer, and is less prone to breaking. Progressive enhancement doesn't have to be hard I often hear that progressive enhancement like this requires developers to write the same code twice. It doesn't. Most the dev work happens on the server. Most of the client-side patterns are similar: intercept a click or submit, make a fetch() request, render an update into the UI. I have just a handful of Web Components that I reuse across many, many different types of UI because the basic interaction patterns are the same. It's made my developer life so much easier. I can help your team get there, too. Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+