State Management Recipes
상태의 주인, 저장 중 편집, 비동기 응답과 복구를 다루는 구현 패턴.
이 자료로 구현하기
원문 주소와 버전이 포함된 요청문입니다. 복사한 뒤 만들 화면과 요구사항을 채워 에이전트에게 전달하세요.
FROM PRINCIPLE TO PRACTICE
이 원리로 만든 예제 1
예제를 열어 직접 조작하고, 관찰한 동작을 이 문서의 원리와 비교해 보세요.
저장 스냅샷·중복 제출·나가기Save ownership
- 저장 작업의 소유권과 응답 순서
Settings의 필수 패턴을 함께 실행하며 각 패턴의 역할을 구분합니다.
- 저장 작업의 소유권과 응답 순서
Domain classification: design-engineering. Lifecycle: experimental.
Repository Boundary
These are Design Engineering behavior recipes. The root recipes/ directory remains the Layout corpus. A behavior recipe may reference a Layout recipe but cannot import state logic into its reusable CSS.
Reusable Method
Choose a task, then review its owner map, event flow, substitution rules, and acceptance sequences.
- Settings with explicit save: draft, submission, acknowledgement, and guarded departure.
- Search filters and detail: route state, out-of-order reads, and stable selection.
- Multi-step form: retained fields, validation, branching, and final submit.
- Deletion and supported undo: identity, duplicate policy, recovery, and actual reversibility.
Composition Matrix
E means essential to this recipe's declared behavior; S means substitutable when the stated requirement changes; O is optional with its own contract; — means not required. Pattern names link to their standalone contracts.
| Pattern | Settings | Search/detail | Multi-step form | Delete/undo |
|---|---|---|---|---|
| Single owner | E | E | E | E |
| Derived state | E | E | E | O |
| ID selection | — | E | — | E |
| Draft/baseline | E | — | E | — |
| Submitted snapshot | E | — | E | — |
| Unsaved navigation | E | — | E | — |
| Latest request wins | O | E | O | — |
| Single flight | E | — | E | E |
| Optimistic overlay | O | — | — | S |
| URL state | O | S | O | O |
| Identity reset | E | E | E | E |
| Versioned restore | O | — | O | — |
Single owner and identity reset are lifecycle foundations in these recipes even where the short stack emphasizes task-specific mechanisms. For a fixed identity, reset may be implemented simply by disposal; reused screens must invalidate their old generation.
Substitution risks: replacing URL state loses history/deep-link recovery unless another navigation owner provides it. Replacing a pending deletion with an optimistic overlay requires definitive rejection versus uncertain-outcome handling. Replacing explicit save with autosave changes the recipe and needs a separate write ordering contract.
Opinionated Guidance
Keep compositions smaller than the complete catalog. Optional restore and optimistic display should solve a named user need. Do not create a new primitive merely because a screen combines several existing ones.
Platform-Specific Guidance
Keep native form behavior, router transitions, and focus restoration in the consuming UI. Model examples have no rendered geometry; use the linked Layout recipes to name scroll and source-order ownership.
Unsupported Absolutes
The matrix describes proposed compositions, not universal requirements for every settings or search screen. It does not claim that all combinations have executed browser evidence.
Verification Contract
Each recipe must expose a unique ownership map, a failure interleaving, and the consequence of replacing an essential choice. Execute consumer integration sequences separately from the 12 pattern model examples.
Source, License, And Attribution
Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
IA Navigation
Parent: State Management. Next: Continue the state management route.
