How MDN's Autocomplete Search Works
hacks.mozilla.org
hacks.mozilla.org
You can see the "inverted index" is rendered inline in the page, since everything is generated at build time.
When you type something that matches a key in the index, we fetch that index key and add it to the results. [1] [2]
Obviously we could do a lot better in terms of relevancy, but it's simple and fast.
[0] https://docs.fastcomments.com/
[1] https://docs.fastcomments.com/index-ublJLBnXgz88.json
[2] https://github.com/FastComments/fastcomments-docs/blob/main/...
I use it everywhere where I need autcompletion. For example on the Music-Map:
I made a fork of the code which is available here:
These days, due to the rest of the project, I've been using Angular and Material's Autocomplete component, which I've found very easy to customise for in-memory indexes or hits to a remote ElasticSearch 'suggester' proxy endpoint.
Gnoosic uses the same library, and here you can navigate with the cursor keys:
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.
Also, I'm confused, I thought https://mdn.dev/ 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?
> They should have just had the search field auto-focused automatically but that would have done away with their "clever" hack to lazy-load the DB containing every page name.
this would steal away the focus and is not good for accessibility (unless you're building a search engine)
Press ctrl-f twice.
It seems to me that mdn.dev is intended to be the future home of MDN web docs since it is collaborative now, and no longer exclusively managed by Mozilla. But they haven't actually made the transition yet, as any link on mdn.dev points back to the old (current) site at developer.mozilla.org
It's quite nice for keyboard-only web navigation.
It's ' to trigger quick find in links only mode.
Enter never goes to the next result though, so I am not sure if that is just something different between his setup and mine. I have to use F3 to go to the next result.
Sorry if that wasn't clear. (English is not my first language)
https://www.tenforums.com/tutorials/120679-enable-disable-qu...
1. It disappears after a few seconds.
2. It has no "next/previous/highlight all" etc. buttons (it still have these features, just no clickable buttons)
It still makes no sense to me.
I guess maybe a small portion of people would find the auto-disappearing thing useful, even though in normal Ctrl+F all you need to do is pressing Esc.
But the second "feature" totally baffles me. It's not like Ctrl+F is some expensive GUI to launch, why would I want to not have these buttons? Even if you don't need them at all (I don't), you can simply not click them, there is no downside by having them.
Page Info -> Permissions -> Override Keyboard Shortcuts
You're not the first one to point it out. Please join github.com/mdn/yari to raise your voice. It's an Open Source project after all.
> They should have just had the search field focused automatically
Why? There's a lot of JS to load to make that work. If you never need to do a search (e.g. from a Google search) it would be a potential waste.
> Also, I'm confused, I thought https://mdn.dev/ was the new thing because Mozilla was stepping back from MDN. Is it a fork?
That domain is just an alias we don't currently use. It's still the old MDN from Mozilla. No fork.
Confused by what this comment is meant to say exactly, but just in case its not known already, seems this situation is what the autofocus attribute is for @ https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att..., no JS needed
No, this would be extremely wrong: it’d open on-screen keyboards automatically on platforms that use them, mess with screen readers by dropping them in the search box rather than at the head of the page, and break keyboard functionality, most significantly things like arrow keys and Space for in-page navigation.
The autofocus attribute sometimes seems like a good idea, but it’s actually almost never desirable.
This is one of the two comments on the article (the other being the rationale as a response for why they used the '/' key to do that behavior.)
Many websites leave a lot of performance on the table because of such behaviors.
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 think GPS question was rather whether the page loads the start autocomplete script on focus, and the script triggers download of the json data, as in the pseudo code, or whether the real code triggers downloading of both in parallel (the script and the json data)?
Fast and can be served from a static site.
I used to automatically include jQuery in every project as a habit/reflex.
Now, because of MDN, I never do that anymore, unless It makes total sense. Kudos guys!
Plus, if it was added to the spec, then Safari users wouldn't be able to use it.
update: 144KB for JSON file
a little bit worrying, given their scale and potential bandwidth requirements
Rather that than hitting a search endpoint (after typing a certain amount of characters).
A large chunk of the world's population still pays a locally-expensive rate for mobile bandwidth, and we're increasingly leaving them behind - or worse, pushing them into zero-rating internet plans which mean they can only use Facebook and WhatsApp while avoiding the rest of the web: https://en.wikipedia.org/wiki/Zero-rating
I see in your npm page that despite compatibility "some adjustments" might be needed, aka you broke compatibility. If you did a breaking change, you need to up that major version my man.
Please stop with this sentimental versioning, it just causes issues for the rest of us who want to rely on npm's ability to not upgrade stuff on breaking changes, now everyone's gonna have to lock you package version to 0.6 so they don't get your breaking stuff from 0.7.
And that's per page where the search has been activated, correct? With no sharing of that dataset between each page?