The Problem

One of the crucial features I wanted <much-select> to support is value transformation and validation. This is important for configuring <much-select> to allow users to input “custom” values (not just the predefined options in the list) but you still need some guard rails on the values the user can enter. Accomplishing this through standard web APIs proved to be a daunting task. I tried some different things and I’m going to describe what I came up with and why.

The Challenge

In the life cycle of a <much-select> a lot of events are triggered. Events can trigger additional events leading to big cascades of events that can block the main browser thread. We can prevent this from happening with debouncing.

Two example of this in <much-select>:

1. Each keypress when a user is filtering down a list of options. If we debounce keypress events by a half a second or so the UI looks smoother and we do a lot less work.
2. Updating the options in the <much-select> following a relevant DOM change. However, DOM changes can come in in rapid succession. Waiting a 10th of a second or so, for changes to stabilize/finish before updating the options saved a lot of work.

Changes and re-renders in the DOM can be costly. Reducing their frequency significantly improves the responsiveness of <much-select> and enables it to manage larger lists of options more efficiently.

The Problem

A lot of Options

I need <much-select> to support a lot of options. I’ve been testing with 10,000 options. <much-select> needs to be able to filter that list down “fast”. By that I mean it needs to feel fast to the user.

Big Options

The size (or length) of options also plays a role. If the options are fairly simple and short (e.g. city names), that’s a lot different than options with long labels and even longer descriptions (e.g. book titles).

Elm Inside a Web Component

A Whiny Introduction

This is part 1 of a story I never wanted to write. I have heard over and over again something along the lines of, “don’t make a UI widget, leave that to the platform or to someone else.” Those people are right.

What kind of UI widget, you ask? It’s that white whale, a multi-select widget. There are a lot of them out there. If I had spent more time studying the ones that folks have already made, I would probably have been better off, but when you’re doing a project in your spare time (at least it started out that way), just building it is a lot more fun.