Sometimes we gotta take matters into our own hands, am I right?
I was reading Aaron Gustafson’s Never Lose Form Progress Again which is just a wonderful idea for a Web Component. Basically you wrap a <form> in <form-saver> and it saves the data a person types into a form to localStorage so they don’t lose it if they do something like close the tab or refresh it.
I’ve always really liked how GitHub does this. Say I’ve spent a good amount of time typing up a new GitHub Issue or Pull Request description. Then I do something dumb like refresh the page or just close it without finishing. If I go back to that page, it’ll have what I saved. Here’s a quick GIF, where you can see a quick white flash of the page reloading, and my text still being there:
That’s what Aaron’s library does!
I set about playing with it, but it’s got some weird issue with how it’s packaged up on npm and how esm.sh serves it from a CDN. I’m sure it’s surmountable, but I was just playing around and didn’t feel like dealing with it.
I also happened to remember David Darnes similar approach with <storage-form>, so I gave that a spin as well. I like David’s approach too and how ultra simple it is. But I had my own little quibble! David’s approach here is that when the form is submitted it saves to localStorage unless the <form> happens to not have a submit button, then it saves on the change event automatically.
I prefer… both. I wanted my form to have a submit button and to have the data save automatically. Like the GitHub approach. I didn’t see any particular way to override the behavior in the component David provides, so I just snagged my own copy of the original. It’s only 60 lines of code, so really no big deal.
I just monkey patched it myself:
connectedCallback() {
this.forms.forEach((form) => {
this.updateForm(form);
// const eventType = this.getSubmitter(form) ? "submit" : "change";
const eventType = "change";
form.addEventListener(eventType, (event) => {
event.preventDefault();
Code language: JavaScript (javascript)The change event all the time, baby.
Sometimes you gotta just take matters into your own hands to get what you want. That’s the job.
In other HTML news, and this is back in May, but there’s been some discussion around native HTML templating. I’m sure there is lots of fancy stuff it’s supposed to be able to do, but I think of it just with the basics, like I wanna put {blog_post.title} in my <h1> and maybe native web tech should be able to do that… better.
Of course there are already ways. I can find the <h1> in JavaScript and change the .innerText, or more reasonably, I can produce the HTML with template literals sprinkling in JavaScript variables where needed. But what if it was just better? What if there were loops and logic and event handlers and stuff all handled nicely? There are a million technologies that help us with this (think JSX, mustache/handlebars, how every framework handles it differently, etc). Feels like that cowpath has been sufficiently paved, it’s time for web standards to come in. I was thinking of it yet again as I stumbled across Scott Jehl’s data binding idea again recently. I don’t know if we need more ways. We kinda need less ways.
OK I’ll leave you with a link to Frank M Taylor’s great You don’t know HTML Lists. Catnip for people like me that love a good classic web tech deep dive.