Closed mbostock closed 4 months ago
I think this needs some more tweaking? See this search for [data loaders].
Should we demote examples relative to the docs pages? The lib/
and inputs/
pages feel like they should be the same priority as examples, but the core pages should probably be higher.
Also needs documentation for the new search config.
I think Minisearch doesn't have per-document boosting, only per field. But in the client we could sort based on the score times an additional "boost" field (that defaults to 1).
In the future a user could add this boost value to a page's front-matter, maybe.
(Half-related, we've also mentioned that maybe keywords should be boosted less than titles, e.g. 2 instead of 4, but I didn't experiment with that).
I found you can do per-document boosting with the boostDocument option, so I’ve added that.
I’ve also now changed it to not expose MiniSearch; instead the search.index option returns an async iterable of additional results to index. This gives us a little more flexibility, but it also means that you can’t discard previously-indexed search results programmatically… so maybe it would be better to just expose MiniSearch? Anyway, it’s probably fine for now and we shouldn’t worry about it.
Yes I prefer this approach to exposing MiniSearch. You can replace an existing document by providing the same id (and if you want to delete it, replace it with an empty text—or better yet use the search: false option).
There is a bug in that the usual results now have a double slash (e.g., https://observablehq.com/framework//loaders
). [FIXED]
Alternative to #1323.