Doesn't a searchbox with typeahead and instantly updating results still require a backend? Isn't that backend not the most important ingredient of this use-case?
Or did you send a large payload of objects to the frontend and have it indexed clientside with e.g. lunr.js?
I've used fuse.js for this, but for a use-case where we knew we had less than a hundred documents to index and where the access control was simple and the content reasonably stable. I'd never use this for a search feature in e.g. an admin backend or a large, content-rich webapp.
Yeah the "pure" backend side (DB/queries to it) was not a problem and something I was already comfortable with. I did not use a client JS library for filtering, I was trying to stick to pure HTML response routes as much as possible. In addition to the typeahead search I had some dropdown and radio toggle filters. I wanted these to all be reactive to each other, eg, you shouldn't be able to select the region "North America" if none of the current typeahead results have that as a region. I found this confusing to implement within the HTMX paradigm. I had a lot of HTML partial templates and had trouble mentally modeling how it was all fitting together.
TBF, probably partially a skill issue. But I know that just going back to a "normal" approach where my backend returned a huge payload and then I wrote the filtering/rendering in JS, was sooo much simpler to think about, even if it resulted in more total code.
I'm working on my first project with htmx and had a similar dilemma. The core issue is that the input form itself has some state, in terms of which options are selected or which options are available. Even in the case of a simple drop down, the user's selection can get cleared if they drill into a result and then hit the browser back button.
At first I was reaching for JS and this feels good—total control! But I wanted to challenge myself to use a hypermedia based approach, and in the end the outcome felt better.
One key insight was that I needed to rerender the form too when I returned the results. At first I only inserted the results into the page and left the form untouched. Later I also realized that if you want to encode the entire search in the url as parameters, then you need a way to render that combo of results and form state on page load anyway.
I guess where it can get tricky is with the templating system. I used FastHTML and wrote all my HTML as Python code. This gives the full expressiveness of the programming language, which is nice, but it seems that templating systems typically provide plenty of logic and control flow. A single template can do a lot. For your example of making only certain regions selectable depending on search results, you could pass the list of regions into the template engine and use a for loop capability in the template.
But hey, you found a way that works and that's great. Just wanted to share that I found with a bit of paradigm shift I found the hypermedia approach really straightforward and clean.
> At first I was reaching for JS and this feels good—total control! But I wanted to challenge myself to use a hypermedia based approach, and in the end the outcome felt better.
I've built a search page that used meilisearch as backend and a simple "SPA" in vanilla JS once.
It was completely "Hypermedia based" because I stored all the state of search/facets/pagination for the SPA in the URL(query args). A URL is limited in what it can store, but its a neat storage for state, especially because it's limited :)
Then if you landed on a page with certain query args, the state would be rebuilt from that, and the request to meilisearch would be constructed from this "state", sent there, and the objects in the response would be the state for the results.
Doesn't a searchbox with typeahead and instantly updating results still require a backend? Isn't that backend not the most important ingredient of this use-case?
Or did you send a large payload of objects to the frontend and have it indexed clientside with e.g. lunr.js? I've used fuse.js for this, but for a use-case where we knew we had less than a hundred documents to index and where the access control was simple and the content reasonably stable. I'd never use this for a search feature in e.g. an admin backend or a large, content-rich webapp.