For years now I have wanted a “dashboard” somewhere central in my house. I think the inspiration comes from my childhood when my Mom would keep a paper calendar with family plans. At some point during my childhood, probably when I was around 8 or 9 years old I started checking the calendar at least a couple times a day. I was the oldest of 6 and I was becoming more and more aware that if I could answer my own questions about what was going on and not interrupt my Mom, everything worked a little bit better.

The selfhosting Jelu project is going well. I’ve spent a little bit of time over the past year cleaning up my library and I’ve updated the application a couple of times. And of course I’ve tracked all my reading. The application still has some rough edges but they keep making it better and it does what I need it to. If something better comes along hopefully I’m in a much better spot to migrate my data.

We’re just about done with another year. It’s been a while since we did one of these picture posts. We’ve been meaning to do them more often. Maybe this year we really start the habbit.

It looks like the last time we did a picture post was 2020. Wow, the kids are a lot older and 2024 sure did feel a lot more normal.

I had my first thoughts of wanting to do something with our doorbell a few years ago after we added our first smart home devices and tried to get a Ring doorbell, but it was too bulky to fit on our doorframe.

This idea remained vague until I saw a YouTube video, probably over a year ago, about how to turn an old doorbell into a smart home button. Once I saw that video, I knew I wanted that project to be my first foray into the world of small electronics, a world I have watched on YouTube for many years, waiting for the time to get into it.

I just launched the Corn Maze app for the Crow River Winery for 2024 (year 3).

There’s some more background about it in a previous post. But I had a bit more time to put into it this year then I have had in the past so I thought I’d share a bit about the improvements I’ve managed to make this year and some general thoughts on how the project is going.

First off, a little bookkeeping. I have been using Goodreads for years now to track my reading. It’s still a pretty good platform, but it’s also just a lot. A lot of ads. A lot of features I don’t use, like “Reading Challenges,” and a lot of the “Community” stuff.

One of the things I’m going to try to do over the next five years, though, is attempt to self-host as many applications as I can. I found Jelu. I set it up a few days ago and so far, it’s been a pretty good experience. I’ll have some more thoughts on it below, but something you should know is that the data I brought over from Goodreads did not have everything in it I wanted. This is probably my fault, but I’m still in the process of cleaning things up. As a result, the books I’m looking at that I’ve read this year might not be all the ones I actually read this year.

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.