Skip to content

Commit 3441fdc

Browse files
committed
docs: update readme to add known issues
1 parent e0021c0 commit 3441fdc

File tree

1 file changed

+21
-0
lines changed

1 file changed

+21
-0
lines changed

README.md

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,6 +33,7 @@ Build real-time, collaborative mobile apps that work seamlessly offline and auto
3333
- [Hooks](#hooks)
3434
- [Error Handling](#-error-handling)
3535
- [Debug Logging](#-debug-logging)
36+
- [Known Issues & Improvements](#️-known-issues--improvements)
3637
- [Examples](#-examples)
3738
- [Links](#-links)
3839

@@ -1157,6 +1158,26 @@ Enable detailed logging during development:
11571158
- Sync operations
11581159
- Change counts
11591160

1161+
## ⚠️ Known Issues & Improvements
1162+
1163+
### Reactive Queries & Write Connection Contention
1164+
1165+
**Issue:** `useSqliteSyncQuery` uses `writeDb` with op-sqlite's `reactiveExecute` to ensure queries see sync changes immediately. However, when data changes frequently (e.g., during active sync), the write connection can become a bottleneck.
1166+
1167+
**Potential improvement:** Have `cloudsync_network_sync()` return the list of updated tables. This would allow reactive queries to use `readDb` instead, with manual invalidation when sync completes for specific tables. Trade-off: manual invalidation logic vs. op-sqlite's built-in `reactiveExecute`.
1168+
1169+
### Optimistic Updates & Sync Blocking
1170+
1171+
**Issue:** With push notifications, sync can be triggered frequently. Since sync operations use `writeDb`, a user writing to the local database at the same time may experience delayed UI updates while waiting for the sync transaction to complete.
1172+
1173+
**Potential improvement:** Implement optimistic updates where local writes update the UI immediately, independent of sync status. This requires careful handling of conflict resolution when sync completes.
1174+
1175+
### First Install Empty State
1176+
1177+
**Issue:** On first app install, the initial sync may not return changes immediately (server may need time to prepare data). The app stops showing the loader and displays empty content, then shows the actual data on the second sync interval.
1178+
1179+
**Potential improvement:** Keep showing a loader until the first successful sync with data, or until a timeout since there might not be any data to fetch
1180+
11601181
## 📖 Examples
11611182

11621183
Check out the [examples](./examples) directory for complete working examples:

0 commit comments

Comments
 (0)