The current implementation uses localStorage which comes with a set of limitations and flaws that might become apparent for long-time/intensive users of this app.
See #588, #566, #536
The main 3 issues that I personally have encountered are:
localStorage will reach its maximum capacity and not accept any more data.
After reaching max capacity or experiencing a non-clean process kill/system shutdown, localStorage might corrupt and empty itself, causing all chat history to be lost.
localStorage is not prepared to handle separate streams of data coming from different tabs. In fact you can't even open a second tab because the localStorage object that each tab works with is completely isolated from any changes made by other tabs. If you do, the last tab to write to localStorage will overwrite the data written by any and all other open tabs before it.
My suggestion is to implement chat storage using Dexie.js (IndexedDB wrapper). This is a more fit solution to storing the large strings of text contained in chats while using localStorage to save the settings, key, etc.
This will avoid running out of storage in localStorage, and it can be written to from multiple tabs simultaneously without interferences between them; allowing for multiple tabs to be used at once without the issues that come with doing this in the current version of the app.
By using the BroadcastChannel API, changes to the DB made by other tabs are reflected instantly in all open tabs.
It seems like the components involved need to implement logic to be re-rendered when data affecting them changes.
I don't know if this is the best solution to this issue given the size of the codebase is nearing 10,000 lines and my experience with a project using a Dexie.js DB and featuring updates in real time for all tabs accessing it, is limited to small, much simpler projects.
I can contribute to this feature but would like confirmation from the maintainer as my last contribution was never approved, rejected, or acknowledged, so I'm reluctant to start working on such a big refactor if there's no chance for it to be merged to upstream.
Input from other users/coders would be extremely valuable since this is only one possible solution and someone else might have a better or more solid plan to tackle this issue.
The current implementation uses localStorage which comes with a set of limitations and flaws that might become apparent for long-time/intensive users of this app.
See #588, #566, #536
The main 3 issues that I personally have encountered are:
My suggestion is to implement chat storage using Dexie.js (IndexedDB wrapper). This is a more fit solution to storing the large strings of text contained in chats while using localStorage to save the settings, key, etc.
This will avoid running out of storage in localStorage, and it can be written to from multiple tabs simultaneously without interferences between them; allowing for multiple tabs to be used at once without the issues that come with doing this in the current version of the app.
By using the BroadcastChannel API, changes to the DB made by other tabs are reflected instantly in all open tabs. It seems like the components involved need to implement logic to be re-rendered when data affecting them changes.
I don't know if this is the best solution to this issue given the size of the codebase is nearing 10,000 lines and my experience with a project using a Dexie.js DB and featuring updates in real time for all tabs accessing it, is limited to small, much simpler projects.
I can contribute to this feature but would like confirmation from the maintainer as my last contribution was never approved, rejected, or acknowledged, so I'm reluctant to start working on such a big refactor if there's no chance for it to be merged to upstream.
Input from other users/coders would be extremely valuable since this is only one possible solution and someone else might have a better or more solid plan to tackle this issue.