-
Notifications
You must be signed in to change notification settings - Fork 24
Add api-audit md file that list down some api need to handle while offline. #140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for docs-ohc ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|-------------------------|-------------------|-------------------------------------------------------------------------------------| | ||
| **Phase 1: Caching** | Week 1 – Week 3 | • Dexie schema & IndexedDB setup<br>• `PersistQueryClientProvider` integrated<br>• Selective caching (`meta.persist`) verified<br>• Implementation of all tech config mention in phase 1<br>• Offline reads tested | | ||
| **Phase 2: Offline Writes**(mid-evaluation) | Week 4 – Week 6 | • `offlineWrites` table created<br>• `saveOfflineWrite` hooked into forms| | ||
| **Phase 3: Synchronization** | Week 7 – Week 9 | • `syncOneWrite`, retry/backoff, and `computeBackoffDelay` complete<br>• `detectAndMarkConflict` implemented<br>• Implementation of all tech config mention in phase 3<br>• End-to-end sync (offline → online) tested | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd revise the estimate for sync, you would need to handle a lot of situations:
- ex: how are you going to handle cases when patient data isn't available in facility? User could unknowingly create them.
- how to convey the conflict to the user (depending on various forms)?
| **Phase 1: Caching** | Week 1 – Week 3 | • Dexie schema & IndexedDB setup<br>• `PersistQueryClientProvider` integrated<br>• Selective caching (`meta.persist`) verified<br>• Implementation of all tech config mention in phase 1<br>• Offline reads tested | | ||
| **Phase 2: Offline Writes**(mid-evaluation) | Week 4 – Week 6 | • `offlineWrites` table created<br>• `saveOfflineWrite` hooked into forms| | ||
| **Phase 3: Synchronization** | Week 7 – Week 9 | • `syncOneWrite`, retry/backoff, and `computeBackoffDelay` complete<br>• `detectAndMarkConflict` implemented<br>• Implementation of all tech config mention in phase 3<br>• End-to-end sync (offline → online) tested | | ||
| **Phase 4: Notifications** | Week 10 – Week 12 | • Conflict notification event/UI built<br>• `resolveConflict` helper added<br>•Optimization & Performance<br>•User Testing & Documentation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UI here could address the 2nd point mentioned.
- Keep it facility specific, so facility settings page.
- Syncing when transitioning from offline to online is fine. You can display toast notifications during/after this transition and prompt the user to clear any conflicts or failures.
This MD file contains details about the list of some standard workflows and backend APIs of these workflows. The tables present in this MD provide an idea about the dynamic data that needs to be cached. The APIs listed in the table are the ones that help to operate the UI of the workflows mentioned in this document.
Using these tables, we can decide on route registrations in the workbox. This is the initial step before creating the CEP for the offline-support project.