Summary
JobsProvider (JobsContext.tsx) holds all job/milestone state, including the assertionId mapping to real on-chain assertions, in plain useState(seedJobs). There's no backend and no client-side persistence, so refreshing the page discards every job created and every milestone submitted/disputed/resolved in the session, reverting to the three seed jobs. A visitor's real activity against the live contract leaves no lasting trace in the app itself.
Scope
- Persist
jobs (including each milestone's assertionId/submittedAt) across reloads. No backend exists for this app, and none should be introduced just for this; a client-side store is sufficient and consistent with job metadata already living entirely off-chain in the browser.
- Independent of the on-chain state reconciliation issue, this can be built in either order. Without reconciliation in place yet, a persisted status is only as accurate as the optimistic status the app currently sets, no worse than today's in-session behavior, just no longer lost on reload.
Proposed approach
Back JobsProvider's state with localStorage (read on mount, write on every jobs change), keyed so it doesn't collide with other apps' storage. If the on-chain state reconciliation work has landed by the time this is picked up, reconcile any milestone with an assertionId against get_assertion_state on mount, after loading persisted state and before rendering, so a stale persisted status never outlives a real state change that happened while the tab was closed. If not, plain persistence of the current optimistic status is still a real improvement on its own.
Summary
JobsProvider(JobsContext.tsx) holds all job/milestone state, including theassertionIdmapping to real on-chain assertions, in plainuseState(seedJobs). There's no backend and no client-side persistence, so refreshing the page discards every job created and every milestone submitted/disputed/resolved in the session, reverting to the three seed jobs. A visitor's real activity against the live contract leaves no lasting trace in the app itself.Scope
jobs(including each milestone'sassertionId/submittedAt) across reloads. No backend exists for this app, and none should be introduced just for this; a client-side store is sufficient and consistent with job metadata already living entirely off-chain in the browser.Proposed approach
Back
JobsProvider's state withlocalStorage(read on mount, write on everyjobschange), keyed so it doesn't collide with other apps' storage. If the on-chain state reconciliation work has landed by the time this is picked up, reconcile any milestone with anassertionIdagainstget_assertion_stateon mount, after loading persisted state and before rendering, so a stale persisted status never outlives a real state change that happened while the tab was closed. If not, plain persistence of the current optimistic status is still a real improvement on its own.