We took a similar approach for our documentation search. [0]<p>You can see the "inverted index" is rendered inline in the page, since everything is generated at build time.<p>When you type something that matches a key in the index, we fetch that index key and add it to the results. [1] [2]<p>Obviously we could do a lot better in terms of relevancy, but it's simple and fast.<p>[0] <a href="https://docs.fastcomments.com/" rel="nofollow">https://docs.fastcomments.com/</a><p>[1] <a href="https://docs.fastcomments.com/index-ublJLBnXgz88.json" rel="nofollow">https://docs.fastcomments.com/index-ublJLBnXgz88.json</a><p>[2] <a href="https://github.com/FastComments/fastcomments-docs/blob/main/src/index.js#L92" rel="nofollow">https://github.com/FastComments/fastcomments-docs/blob/main/...</a>
I remember doing something similar a few years ago, I needed autocomplete for a shipping ports field, the data was too big though so I ended up using a csv file in an aws lamda function that filters based on the selected country and returns a much smaller subset. It lazy loaded after the user selected the country. To keep response times low I had to do a binary search on the raw csv bytes. It felt like I was reinventing databases but I liked the idea of it being self contained in a function.
My favorite autocomplete library is an ancient version of bootstrap-typeahead.js by Twitter. A single file with less than 400 lines of Javascript. They don't make these anymore :)<p>I use it everywhere where I need autcompletion. For example on the Music-Map:<p><a href="https://www.music-map.com" rel="nofollow">https://www.music-map.com</a><p>I made a fork of the code which is available here:<p><a href="https://www.gibney.org/0g-typeahead" rel="nofollow">https://www.gibney.org/0g-typeahead</a>
They hi-jacked the browser's `/` key to focus the field, which is something I hate. As a user, I want `/` to bring up Firefox's quick search bar, especially when reading documentation.<p>They should have just had the search field focused automatically but that would have done away with their "clever" hack to lazy-load the DB containing every page name.<p>Also, I'm confused, I thought <a href="https://mdn.dev/" rel="nofollow">https://mdn.dev/</a> was the new thing because Mozilla was stepping back from MDN. Is it a fork? They both carry Mozilla logos, so what's going on there?
Now I am curious if, in the real MDN production site, serach-index.json loading is triggered by the execution of /static/js/autocomplete.js, when their download should really be started in parallel by the shim.<p>Many websites leave a lot of performance on the table because of such behaviors.<p>My hypothesis is that, since this is easier for the developer, and works good enough, not many people really care. But these things add up, and the web becomes slower and slower.
I like mosra's search, implemented in m.css for magnum. He wrote a blog post on it here: <a href="https://blog.magnum.graphics/meta/improved-doxygen-documentation-and-search/" rel="nofollow">https://blog.magnum.graphics/meta/improved-doxygen-documenta...</a> and you can try it on the magnum docs site: <a href="https://doc.magnum.graphics/magnum/#search" rel="nofollow">https://doc.magnum.graphics/magnum/#search</a><p>Fast and can be served from a static site.
Are they using react for just this one thing on this page!? Honestly it wasn't very clear to me, but they seemed to indicate that. I wonder if that's just because it's the pattern at MDN, but I feel like shipping react along with the JSON has got to be huge.
As an aside here... MDN docs are pretty awesome. I've been learning pure vanilla Javscript on this site more than anywhere else.<p>I used to automatically include jQuery in every project as a habit/reflex.<p>Now, because of MDN, I never do that anymore, unless It makes total sense. Kudos guys!
I think adding search to the HTML standard makes more sense overall. The thing I hate about search like this is that they don't work with JS turned off (e.g. terminal browser). Why not just add a JSON search component to HTML itself?
In the code snippet they show the `startAutocomplete()` function checks for the "started" variable being true; but never actually sets it to true.
i'm wondering how much kb it loads before ready to search?<p>update: 144KB for JSON file<p>a little bit worrying, given their scale and potential bandwidth requirements
I thought this was going to be about advanced usage of <datalist>: <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...</a>
so, "144KB over the network" - how much does that equate to in memory?<p>And that's per page where the search has been activated, correct? With no sharing of that dataset between each page?