You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: the option to prebuild the search index will be removed with the next big iteration of the search functionality of Material for MkDocs. If you're using this option, you can describe your use case and why you might want to keep it.
I'm currently in the process of rearchitecting the search functionality in order to address some of the current shortcomings. The next big iteration of the search will make it much more powerful, adding further abilities for extension (e.g. providing faceted/structural search through arbitrary custom fields).
However, one thing that stands in the way of significant improvement is the option to prebuild the index, because it means that all improvements have to be implemented twice, on the client- and server-side. Even worse, there are two possibilities for prebuilding during build-time – Node.js and Python – which means two separate server-side implementations with two entirely independent sets of dependencies with lots and lots of room for inconsistencies.
I want to keep things simple. Thus, I've decided that support for prebuilt indexes is going to be deprecated removed with the next major release because it gives me much more flexibility in rethinking the search functionality. I can already say that it will definitely be worth it, because the UX of search will be so much better, including:
Better search result summaries
Rich search results (including code blocks)
Faceted search (define custom fields)
... and more
Note that the prebuilding feature was always considered experimental, as denoted in the documentation.
Also interesting: some time ago, I benchmarked prebuilt indexes in #1465 (comment). I also measured the improvements the new search functionality will yield in this tweet, which shows that the upside of prebuilt indexes is shrinking even more.
The text was updated successfully, but these errors were encountered:
I've just opened a PR on the Insiders repository with the first draft of the new search functionality, which also removes support for prebuilt indexes. This issue can be considered resolved, as no objections were raised and the benefits of the new search outweigh the questionable benefits of prebuilt indexes.
TL;DR: the option to prebuild the search index will be removed with the next big iteration of the search functionality of Material for MkDocs. If you're using this option, you can describe your use case and why you might want to keep it.
I'm currently in the process of rearchitecting the search functionality in order to address some of the current shortcomings. The next big iteration of the search will make it much more powerful, adding further abilities for extension (e.g. providing faceted/structural search through arbitrary custom fields).
However, one thing that stands in the way of significant improvement is the option to prebuild the index, because it means that all improvements have to be implemented twice, on the client- and server-side. Even worse, there are two possibilities for prebuilding during build-time – Node.js and Python – which means two separate server-side implementations with two entirely independent sets of dependencies with lots and lots of room for inconsistencies.
I want to keep things simple. Thus, I've decided that support for prebuilt indexes is going to be
deprecatedremoved with the next major release because it gives me much more flexibility in rethinking the search functionality. I can already say that it will definitely be worth it, because the UX of search will be so much better, including:Note that the prebuilding feature was always considered experimental, as denoted in the documentation.
Also interesting: some time ago, I benchmarked prebuilt indexes in #1465 (comment). I also measured the improvements the new search functionality will yield in this tweet, which shows that the upside of prebuilt indexes is shrinking even more.
The text was updated successfully, but these errors were encountered: