feat!(store): fully rework and add auto save
Closes #1535 Fixes #1256
Rework and add a setting to enable a store to debounce save on modification (on calls like set, clear, delete, reset)
To be honest, I wonder why with_store works in this way, I'm thinking it should be creating a Resource and with that we can store the configs in Rust side so that we don't pass in path and auto_save in every call
To be honest, I wonder why with_store works in this way, I'm thinking it should be creating a Resource and with that we can store the configs in Rust side so that we don't pass in path and auto_save in every call
- with_store is older than the Resource api
- Feel free to rewrite the whole impl/api 😂 (i'm serious, the plugin probably deserves it having requests like https://github.com/tauri-apps/plugins-workspace/issues/15 in mind)
with_store is older than the Resource api
😮 makes sense then, ~~I could probably do it in this PR~~ maybe another PR
I don't think we can do synchronous commands right now with Tauri's IPC? The way we currently do thing is having something in the Rust side and give js side the ability to interact with it but things will stay in the Rust side, #15 means we either need the ability to do synchronous IPC or we reverse the process and make rust side request data from the js side
I don't think we can do synchronous commands right now with Tauri's IPC?
Nope, and i doubt we'll see this any time soon.
The way we currently do thing is having something in the Rust side and give js side the ability to interact with it but things will stay in the Rust side, https://github.com/tauri-apps/plugins-workspace/issues/15 means we either need the ability to do synchronous IPC or we reverse the process and make rust side request data from the js side
I mean, it's totally fine to not want to "solve" #15 i just think we never thought much about it.
@amrbashir Made a proof of concept, take a look see if this looks good to you
We probably need a way to create named stores to allow them to be shared easier, kinda like how the tray icons work, also still need to think about how should save on exit work since we can now having multiple different store settings
Note: didn't do the mobile part yet, didn't do the docs yet
Package Changes Through d8ae8b2bf81e2586ae3911bf8591deaf3bb24e71
There are 11 changes which include cli with prerelease, deep-link with prerelease, dialog with prerelease, sql with prerelease, fs with prerelease, positioner with prerelease, positioner-js with prerelease, shell with prerelease, store-js with prerelease, store with prerelease, updater with prerelease
Planned Package Versions
The following package releases are the planned based on the context of changes in this pull request.
| package | current | next |
|---|---|---|
| api-example | 2.0.0-rc.7 | 2.0.0-rc.8 |
| api-example-js | 2.0.0-rc.4 | 2.0.0-rc.5 |
| cli | 2.0.0-rc.1 | 2.0.0-rc.2 |
| deep-link | 2.0.0-rc.6 | 2.0.0-rc.7 |
| fs | 2.0.0-rc.5 | 2.0.0-rc.6 |
| dialog | 2.0.0-rc.7 | 2.0.0-rc.8 |
| http | 2.0.0-rc.5 | 2.0.0-rc.6 |
| persisted-scope | 2.0.0-rc.5 | 2.0.0-rc.6 |
| positioner | 2.0.0-rc.1 | 2.0.0-rc.2 |
| positioner-js | 2.0.0-rc.1 | 2.0.0-rc.2 |
| shell | 2.0.0-rc.3 | 2.0.0-rc.4 |
| single-instance | 2.0.0-rc.4 | 2.0.0-rc.5 |
| sql | 2.0.0-rc.2 | 2.0.0-rc.3 |
| store | 2.0.0-rc.3 | 2.0.0-rc.4 |
| store-js | 2.0.0-rc.1 | 2.0.0-rc.2 |
| updater | 2.0.0-rc.3 | 2.0.0-rc.4 |
Add another change file through the GitHub UI by following this link.
Read about change files or the docs at github.com/jbolda/covector
really good work btw
We probably need a way to create named stores to allow them to be shared easier, kinda like how the tray icons work, also still need to think about how should save on exit work since we can now having multiple different store settings
@lucasfernog What do you think about these? Currently we're doing nothing on exit, this is different from what we used to do, also do you think we should just prevent duplicated stores with the same path or maybe add a function to share a store with a name?
do you think we should just prevent duplicated stores with the same path
yes I think that's reasonable
I'll need to think about this a bit more on how to do it, I will be out for a few hours, can get back on is when I'm back
Where is the file stored by config plugin?
I couldn't find it under appDataDir()
Not sure what do you mean by config plugin, if you mean the store plugin, you can see the path used with resolve_store_path, it should be under appDataDir if your store's path is a relative path or if it's an absolute path then it will just use that path
Found it, thanks! @Legend-Master