jhildenbiddle
commented
2 weeks ago Adding additional context from the "maintainers" channel on Discord:
@jhildenbiddle wrote:
...I don't love the idea of forcing more data into local storage because doing so will only exacerbate performance issues by forcing us to handle more data using non-async blocking APIs to handle larger amounts of data.
As explained in the article above, local storage uses a non-async API which blocks on all tabs/windows, not just the current page. JSON stringification and parsing APIs used to read/write data to/from local storage are also non-async. Compression is also, presumably, non-async (unless we opt to handle this in a web worker). More data in local storage means more work that needs to be done using these non-async APIs which will inevitably surface as performance issues.
Also worth considering is the fact that the search plugin currently maintains search data in both local storage and in memory for faster lookups. The more search data we have to manage, the more RAM the search plugin will consume. I'd much prefer we look into IndexDB + Dexie.js for "fixing" our search plugin: https://dexie.org/
Remember: At the time the search plugin was created, IndexDB did not exist. With Docsify v5, we have dropped legacy support and can therefore finally leverage modern browser APIs like IndexDB. Migrating our search plugin to IndexDB will allow us to handle read/writes asynchronously, remove the need forJSON parsing/stringification, and allow us to look up search results without maintaining search data in memory.
Feature request
Use localForage instead of localStorage.
Problem or desire
Solve the problem that too many search indexes cannot be stored in localStorage.
Proposal
https://github.com/localForage/localForage
Implementation
Because localForage uses async storage, it has an async API. It's otherwise exactly the same as the localStorage API.
Should just need to replace localStorage in
src/plugins/search/search.jsOther