This component is a modern replacement for my old jQuery predictive typing plugin. I’ve reimagined it as a standards-based web component.

# Basic usage

To use the component, wrap it around your input field and specify an endpoint:

<dynamic-datalistendpoint=“/api/search”><labelfor=“search”>Search<inputtype=“text”id=“search”name=“search”placeholder=“Type to search…”/></label></dynamic-datalist>

As users type, the component makes GET requests to that endpoint, passing in the typed value as the “query” parameter (e.g., /api/search?query=WHAT_THE_USER_TYPED). The response from the endpoint is used to populates a dynamic datalist element with the results.

The structure of the response should be JSON with an options array of string values:

{“options”:[“option 1”,“option 2”,“option 3”]}

# How it works

Under the hood, the component:

1. Adopts (or creates) a datalist element for your input,
2. Listens for “input” events,
3. Debounces requests (waiting at least 250ms) to avoid overwhelming your API,
4. Sends requests to your endpoint with the current value of the input,
5. Reads back the JSON response,
6. Updates the datalistoption elements, and
7. Dispatches the update event.

All of this happens transparently—users just see autocomplete suggestions appearing as they type.

# Need POST?

You can change the submission method via the method attribute:

<dynamic-datalistendpoint=“/api/lookup”method=“post”><labelfor=“lookup”>Lookup<inputtype=“text”id=“lookup”name=“lookup”/></label></dynamic-datalist>

This sends a POST request with a JSON body: { "query": "…" }. Currently GET and POST are supported, but I could add more if folks want them.

# Custom variable names

As I mentioned, the component uses “query” as the parameter name by default, but you can easily change it via the key attribute:

<dynamic-datalistendpoint=“/api/terms”key=“term”><labelfor=“search”>Term search<inputtype=“text”id=“search”name=“term”/></label></dynamic-datalist>

This sends the GET request /api/terms?term=….

# Working with existing datalists

If your input already has a datalist defined, the component will inherit it and replace the existing options with the fetched results, which makes for a nice progressive enhancement:

<dynamic-datalistendpoint=“/api/cities”><labelfor=“city”>City<inputtype=“text”id=“city”list=“cities-list”placeholder=“Type a city…”/></label><datalistid=“cities-list”><option>New York</option><option>Los Angeles</option><option>Chicago</option></datalist></dynamic-datalist>

Users see the pre-populated cities immediately, and as they type, API results supplement the list. If JavaScript fails or the web component doesn’t load, users still get the static options. Nothing breaks.

# Event handling

If you want to tap into the component’s event system, it fires three custom events:

• dynamic-datalist:ready - Fired when the component initializes
• dynamic-datalist:update - Fired when the datalist is updated with new options
• dynamic-datalist:error - Fired when an error occurs fetching data

const element = document.querySelector(“dynamic-datalist”);element.addEventListener(“dynamic-datalist:ready”,(e)=>{console.log(“Component ready:”, e.detail);});element.addEventListener(“dynamic-datalist:update”,(e)=>{console.log(“Options updated:”, e.detail.options);});element.addEventListener(“dynamic-datalist:error”,(e)=>{console.error(“Error:”, e.detail.error);});

Each event provides helpful detail objects with references to the input, datalist, and other relevant data.

# Demo

Check out the demo for live examples (there are also unpkg and ESM builds if you want to test CDN delivery):

# Grab it

The project is available on GitHub. You can also install via npm:

npminstall @aarongustafson/dynamic-datalist

If you go that route, there are a few ways to register the element depending on your build setup:

# Option 1: Define it yourself

import{ DynamicDatalistElement }from“@aarongustafson/dynamic-datalist”;customElements.define(“dynamic-datalist”, DynamicDatalistElement);

# Option 2: Let the helper guard registration

import“@aarongustafson/dynamic-datalist/define.js”;// or, when you need to wait:import{ defineDynamicDatalist }from“@aarongustafson/dynamic-datalist/define.js”;defineDynamicDatalist();

# Option 3: Drop the helper in via a <script> tag

<scriptsrc=“./node_modules/@aarongustafson/dynamic-datalist/define.js”type=“module”></script>

Regardless of how you register it, there are no framework dependencies—just clean autocomplete powered by your API. As I mentioned, it’s also available via CDNs, such as unpkg too, if you’d prefer to go that route.

Over the 3 weeks since it launched, I’ve been keeping an eye on the traffic patterns, reviews, and mentions of Tipr across the intarwebs, but I’ve also been busily adding some new features, which brings me to this post. I knew people with iPhones and other capable mobile browsers were quite happy with Tipr, but folks without a mobile browser or with a sucky one were not, in my opinion, getting as much out of Tipr as I’d like them to. I wanted to correct that.

My first thought was to create an SMS service for Tipr, but there’s no way I can afford to rig up a server capable of receiving and replying to SMS messages and I certainly could not afford to pay the $1000-2000/month for an SMS short code (after all, I’m not making any money on this thing). Then the answer dawned on me: Twitter.

Since Twitter offers an SMS interface (40404 once you register your mobile), I could simply piggy back on their service to offer Tipr via SMS. All I had to do was build a TwitterBot capable of receiving and responding to messages. Lots of folks have built IM bots in the past, but there weren’t that many TwitterBots and there was even less information about building one. Even with the odds stacked against me, however, after about an hour of reading the Twitter API documentation and 6 hours of actual programming, I had built a working PHP-based TwitterBot class.

The whole thing works using Twitter’s direct message functionality and runs several independent services to do things like reciprocate friendships, check the inbox, process responses, and send messages back. Unfortunately, the API was only able to get me so far, so I did have to resort to a little hackery to get some of it to work, but in the end, the Tipr TwitterBot, which sits on top of my generic TwitterBot class is pretty solid and quite responsive — even with the 70 API calls in 60 minutes limitation, most messages receive a response in approximately 45 seconds (depending on your network and whether Twitter is releasing a new feature and takes the service offline for a few minutes).

Overall, I’m pretty happy with the results and the early beta testers seem to be liking it as well. Hopefully some of you out there will find it as useful (if not more so) than the web interface. If you’re on Twitter, give it a shot and let me know what you think.