Convert neDB and redux to Dexie and dexie-react-hooks

[gotjoshua]

I know that many devs love redux, but every time i approach a project that uses it, i get seriously turned off.

@zxch3n how much do you love redux?

When I added the integration profiles for gitlab, i used dexie and the code is much less mysterious

onezoomin@7f2a0d8#diff-e08048882bb180d378ecac731666e52caaab5f29d8270b1240776a8fd0248fc7R180
connects to the indexDB directly with functional style:
onezoomin@7f2a0d8#diff-c3cd800e80ce1b4da8401d52b993f94bdedd2eec00fadcd7addc73bff5fada2fR25

react hooks for useLiveQuery are also super convenient:
onezoomin@7f2a0d8#diff-78148f22ef19662a9cd2cd536e1e55b23eff393dfbef4b62698e4aab9e1d91a4R244

I propose to at least convert the whole settings DB to dexie, so we can compare how things work out.

I also think that the current export import system could be easily adapted for migration.

I know this is a radical proposal, but it is a big step towards simplifying the code base towards a local-first / offline-first approach.

Curious to read some opinions...

[zxch3n]

I agree. The current state management is messy. In many cases, it does things twice unnecessary: 1. update the app state, 2. update the DB. This is designed badly and introduced a lot of bugs.

Thanks for your time digging for a better solution. I'm ok with replacing redux. Does Dexie work well in electron? I'm a little concerned about the case where people delete and reinstall the app

[gotjoshua]

I'm ok with replacing redux.

Glad to hear it! (I am also open to entertain convincing arguments to keep it)

I'm a little concerned about the case where people delete and reinstall the app

well, i assume that app delete would wipe the db. We need to rely on export import for that. And i've been thinking about a setting for auto backup, that could write to the user's file system and check on startup if indexDB has been wiped and ask if restore is desired.

There is also navigator.storage.persisted() to consider.
But this issue comment says:

Yes by default all origins in Electron are granted durable storage, so they are not evicted automatically under storage pressure.

and this issue has quite some strategies to consider:
element-hq/element-web#9220

Does Dexie work well in electron?

Seems to work great (but i have limited experience) I guess it won't be accessible from the node side of electron... but it can be accessed by web-workers.

[gotjoshua]

accessible from the node side of electron

is this important @zxch3n ?

What role does node play in PomLog?

[zxch3n]

is this important @zxch3n ? What role does node play in PomLog?

It can make things easier when you want to set up tests or allow users to write their own script to extract or analyze their data.

well, i assume that app delete would wipe the db. We need to rely on export import for that. And i've been thinking about a setting for auto backup, that could write to the user's file system and check on startup if indexDB has been wiped and ask if restore is desired.

If so, I prefer to use LevelDB or DB built upon it. LevelDB supports many different environments. In our case, we can use https://github.com/Level/levelup, it supports both browser and node. Or use a wrapper like PouchDB.

[gotjoshua]

I set up the issue for the first task:
onezoomin#6

I think its best to only do the settingsDB at first:

1. it is rather self-contained
2. it is conceptually most suitable for potentially non-persistent data
3. it is a managable size
4. i already started with the setting for gitlab integration tokens

[zxch3n]

Yes, I agree

[gotjoshua]

Some more resources about electron persistence

https://livebook.manning.com/book/electron-in-action/chapter-12/8

https://gauriatiq.medium.com/electron-app-database-with-dexie-js-indexeddb-and-web-worker-570d9a66a47a