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
{{ message }}
Repository navigation
Feature: Use localForage instead of localStorage #2281
...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.
Activity
[-]Use localForage instead of localStorage[/-][+]Feature: Use localForage instead of localStorage[/+]jhildenbiddle commentedon Jun 19, 2024
Adding additional context from the "maintainers" channel on Discord: