frontend-patterns/research/candidates/InvalidateAndReproject.md

37 lines
1.7 KiB
Markdown
Raw Normal View History

---
title: Invalidate and Reproject
status: draft
maturity: hypothesis
families: [projection, synchronization]
scales: [L3, L6]
admission: research-candidate-only
---
# Invalidate and Reproject
Context: several views derive from remotely accepted records. Problem: a successful
write does not refresh every observation. Freshness competes with network work and
interaction continuity.
Proposed solution: identify affected observations after acceptance and reload or
replace them from authoritative data. Guard against obsolete responses and preserve
unfinished drafts separately. Show accepted-but-refresh-failed when necessary;
a failed refresh does not undo the accepted mutation.
Consequences: views can converge without treating speculative data as truth, but
invalidation scope and ordering need explicit contracts. Blind cache replacement
loses edits; broad refresh costs bandwidth. A continuous subscription or authoritative
response containing all affected data may avoid a separate fetch.
Evidence: T04 describes React Router action revalidation and stale response handling,
including its limits. One framework mechanism, not independent application recurrence.
Exact known uses of this whole draft: unknown. Hypothesis only.
Proposed connection: depends on outcome information from
[Mutation Outcome Tracking](MutationOutcomeTracking.md) and preserves
[Local Draft State](LocalDraftState.md). Client ordering cannot replace server checks.
T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
Connections are research proposals, not admitted graph edges.
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).