SCALABLE: Save form data to localStorage and auto-complete on refresh

When I was in Amsterdam I was really impressed with the code that Rose was writing and I encouraged her to share it. Here it is: drop this script into a web page with a form to have its values automatically saved into local storage (and automatically loaded into the form if something goes wrong before the form is submitted).

// With the help of Jeremy Keith, I was able to create a fully scalable code sample that you can copy-paste into your project.
// It will save the user input value on blur, this includes radio buttons, checkboxes and date inputs besides regular text/number inputs.
// The only condition is that you give the form element on your page a data-attribute of data-form-topic="foo".
// This code snippet saves the data-attribute as the key to the localStorage, and the value of it will be an object with key/value pairs of the respective inputs name and value.
// Please refer to this gist somewhere in your code if you use it :)
// Happy coding!
// VARIABLE DECLARATIONS
// objects
let savedData = {};
let autocompletedData;
// HTML elements
const inputs = document.getElementsByTagName("input");
document.addEventListener("DOMContentLoaded", () => {
const form = document.querySelector("form");
if (window.localStorage) {
if (!form) {
return;
}
if (!form.dataset.formTopic) {
return;
}
let getFormTopic = localStorage.getItem(form.dataset.formTopic);
if (!getFormTopic) {
return;
}
autocompletedData = JSON.parse(getFormTopic);
var formTopic = form.dataset.formTopic;
console.log(formTopic);
function getKeyValue() {
for (const dataKey in autocompletedData) {
let value = autocompletedData[dataKey];
let formField = document.querySelector(
"[name = " + dataKey + "]"
);
switch (formField.type) {
case "radio":
formField = document.querySelector(
`input[name = '${dataKey}'][value = '${value}']`
);
formField.setAttribute("checked", "checked");
break;
case "checkbox":
formField.setAttribute("checked", "checked");
break;
case "file":
break;
default:
formField.value = value;
}
}
}
getKeyValue();
}
});
if (window.localStorage) {
function saveFormDataToLocalStorage(e) {
const form = e.target.closest("form");
let submitData = new FormData(form);
for (let [dataKey, value] of submitData.entries()) {
savedData[dataKey] = value;
console.log(dataKey, value);
}
window.localStorage.setItem(
form.dataset.formTopic,
JSON.stringify(savedData)
);
}
Array.prototype.forEach.call(inputs, function (input) {
switch (input.type) {
}
input.addEventListener("blur", function (e) {
e.preventDefault();
saveFormDataToLocalStorage(e);
});
});
}
view raw script.js hosted with ❤ by GitHub

Tagged with

Related links

StyleURL - share CSS tweaks instantly

This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).

Tagged with

Service Worker Registration  |  Web Fundamentals  |  Google Developers

Hmm …seems like I should probably wait for the load event before triggering navigator.serviceworker.register().

Tagged with

The Service Worker Lifecycle

The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.

Tagged with

If Not React, Then What? - Infrequently Noted

Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).

This is a spot-on description of the difference between back-end development and front-end development:

Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.

Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.

Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.

As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.

Tagged with

Something went wrong · molily

Debating complexity is pointless because it’s a subjective metric. Every developer has a different gut feeling about simplicity, complexity and the appropriate amount of complexity for a given task. When people try to find an objective definition, they come to wildly different results. And that’s okay.

Instead, we should focus on hard metrics from a user perspective. Performance, efficiency, compatibility, accessibility and fault-tolerance can be measured, tested and evaluated, automatically and manually.

Any amount of complexity is fine as long as these goals are met.

Tagged with

Related posts

Registering service workers

Pour one out for rel=”serviceworker”

Displaying HTML web components

You might want to use `display: contents` …maybe.

Switching costs

The enshittification of React …which was already pretty shitty for users.

JavaScript

Inside me there are two wolves. They’re both JavaScript.

Bugblogging

Also, tipblogging.