Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Use localForage instead of localStorage #2281

Open
sy-records opened this issue Oct 18, 2023 · 1 comment
Open

Feature: Use localForage instead of localStorage #2281

sy-records opened this issue Oct 18, 2023 · 1 comment
Assignees
Milestone

Comments

@sy-records
Copy link
Member

sy-records commented Oct 18, 2023

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.js


Other

@sy-records sy-records changed the title Use localForage instead of localStorage Feature: Use localForage instead of localStorage Oct 18, 2023
@jhildenbiddle jhildenbiddle added this to the 6.x milestone Mar 2, 2024
@sy-records sy-records self-assigned this Jun 19, 2024
@jhildenbiddle
Copy link
Member

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.

@jhildenbiddle jhildenbiddle modified the milestones: 6.x, 5.x Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants