Description

This post is about a Project-release 0.4 for OSD600 course at Seneca College. For release 0.4, the students were required to push themselves further into Open Source Development World out of our comfort zone. I decided to work on a bit more complex issues on the Chatcraft project. Then, I found an issue that looked interesting and more difficult than the ones that I worked on before.

Progress

Since this issue requires moving a substantial amount of code in a page(or component) into another, I first needed to fully understand the code inside the page, which is ModelsSetting.tsx. Especially, I needed to understand the specific part that I am supposed to move. It was persist option, import option, and export option.

I first started to study persist option. It uses Dexie library. What it does is using indexed DB feature of browser. It stores data in indexedDB on browser, and some browsers can make it persist.

This part confused me a lot. At first, I understood persist option as something like even after I close the tab or window, the data is not deleted and when I open Chatcraft later, I can still retrieve the chat histroy. However, persist here doesn't mean that. Whether the persist option is turned on or not, the chat data is stored in IndexedDB. However, sometimes browsers delete the indexed data when it has not enough space or for some other reasons. persist here means preventing the browser from deleting the indexed data arbitrarily.

After I understand what persist option means, I encountered the second problem. Some of the browsers didn't work for persist option such as Safari. The option didn't work at all. On Chrome, it worked sometimes, but it didn't work for some other times. I researched about it, and then find out that it depends on the browser's behavior and decision. For example, the following factors can affect the availability of persist option of Indexed DB.

Reasons for Inconsistent Behavior of navigator.storage.persist() in Chrome are as follows:

• User Interaction Requirement:

For Chrome to grant persistent storage, it usually requires a user gesture (e.g., a click or a form submission). If the persist() method is called outside of such a gesture, Chrome might reject the request.
For example, if you call navigator.storage.persist() inside a background task or an event that wasn't directly triggered by the user, Chrome may not grant the storage permission.

• Engagement and Usage Frequency:

Chrome may also base its decision on how frequently the user interacts with your app. For apps that the user doesn't interact with often, Chrome may decide not to grant persistent storage.
Frequent user interaction (like daily usage) or installing your app as a PWA can improve your app’s chances of being granted persistent storage.

• PWA Installation:

If your app is installed as a Progressive Web App (PWA) or added to the user’s home screen, it has a higher chance of being granted persistent storage. Non-PWA websites might not be as likely to get persistent storage, especially if the user has not engaged much with your site.

• Quota and Storage Policies:

Chrome, like other browsers, has a quota management system to ensure that a site doesn’t take up too much local storage. Even if you request persistent storage, Chrome might deny it if the site has exceeded its storage limits or if the system is running low on space.

• Device-Specific Factors:

On some devices, particularly mobile or low-storage devices, Chrome may be more conservative about granting persistent storage to avoid using too much disk space.

• Browser Updates and Features:

Chrome might change how it handles persistent storage with new versions, and certain flags or experimental features could also affect the availability of navigator.storage.persist(). Occasionally, new browser features or settings might temporarily disable or restrict storage persistence.

In the next post, I write about implementing the solution.