2.4 KiB
TaskNotes Data Flow
This document records the intended data-flow model for the refactor.
Source of Truth
Task data is stored in Markdown files with frontmatter inside the user vault.
Primary source of truth:
- markdown file content
- Obsidian metadata cache for indexed read access
TaskNotes should avoid introducing a competing internal database for core task state.
Read Path
- Vault files change.
- Obsidian metadata cache updates.
TaskManagerand related adapters read task state from metadata cache.- Domain services and views consume normalized
TaskInforepresentations.
Write Path
- A view, modal, command, or API endpoint requests a task mutation.
- The request flows through
TaskServiceor a dedicated mutation collaborator. - Frontmatter/body changes are written to the markdown file.
- Obsidian metadata cache emits update events.
- Event listeners invalidate caches and refresh views.
Cache Principles
Current intent:
- metadata cache remains the primary read accelerator
- plugin-local caches should be derived and invalidatable
- derived caches must never become a second source of truth
Refactor rule:
- every plugin-local cache should document:
- owner
- key
- invalidation trigger
- whether stale reads are acceptable
Event Flow
Current event propagation uses plugin/task-manager events plus view-level refresh handling.
Refactor direction:
- distinguish domain events from UI refresh events
- normalize event payload types
- keep low-level file events from leaking too far into UI modules
Bases Boundary
Bases values and entries are not a stable internal domain model. They should be adapted into local TaskNotes types before the rest of the code depends on them.
Refactor rule:
- use local adapter types for the subset of Bases APIs the plugin actually uses
- prefer
unknownplus narrowing overany
Date and Recurrence Flow
Date handling is a historically sensitive area.
Refactor rule:
- parsing and coercion should happen at the boundary
- internal logic should use explicit date semantics
- recurrence expansion should remain centralized rather than duplicated in views
Operational Principle
When debugging a behavior problem, the first question should be:
"Is this a source-data issue, an adapter issue, a domain-logic issue, or a view-refresh issue?"
The architecture should make that answer obvious.