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>: 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. …

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. …

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. …