Another layer in sync engine is composable storage.
Now you can specify a chain of storages. Each can listen transactions to
update some state. Though subscription for state is invoked one by one
until non-undefined is provided.
See tests to understand API.
Here I also migrated our server data loading and synchronization to this
storage api.
## Description
Fixes payloads with File Map Set etc.
## Steps for reproduction
Upload image. see it works
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
0000)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env` file
Here added support for syncing nanostores atoms
as sync objects. Had to add some tracking of update source though it
seems like a more solid solution than previous variant.
Need to test performance caz stores updates are now synchronous and not
debounced anymore.
Sync client is getting some shape. Here I abstracted all immerhin
related api into SyncObject and added SyncObjectPool to combine multiple
objects. Objects are identified by unique name.
Here added SyncClient class which will be base for our new sync engine.
For now it can synchronize one immerhin store.
Event emitter is shared with canvas directly to avoid indirection of
iframe postMessage api.
This also partially fixes the issue with messages pollution and conflict
with react devtools.
Oleg Isonen