Summary
Multiple packages under internal/tui/components import internal/data directly, coupling the UI rendering layer to the storage/domain model types.
Affected files
| File |
Imports internal/data |
| internal/tui/components/attentionpicker.go |
Yes |
| internal/tui/components/preview.go |
Yes |
| internal/tui/components/reindex.go |
Yes |
| internal/tui/components/sessionlist.go |
Yes |
Problem
UI components should receive display-ready data rather than raw storage types. The current arrangement means:
- Any change to internal/data models (field renames, type changes, new fields) forces updates across multiple UI component files.
- The boundary between the data access layer and the presentation layer is blurred. It becomes difficult to reason about what is a storage concern vs. a display concern.
- Components cannot be tested without constructing data.Session, data.Turn, etc. structs — there is no local "view model" type that could be minimally populated for tests.
Suggested fix
Introduce view-model types either within the tui package or as a tui/viewmodel sub-package. The top-level tui.Model translates data.Session → tui.SessionVM before passing to components. Components then depend only on the view-model types and have no direct import of internal/data. This keeps the data → tui conversion in one place and decouples rendering from storage schema.
This is a gradual refactor: components can be migrated one at a time without breaking the build.
Summary
Multiple packages under internal/tui/components import internal/data directly, coupling the UI rendering layer to the storage/domain model types.
Affected files
Problem
UI components should receive display-ready data rather than raw storage types. The current arrangement means:
Suggested fix
Introduce view-model types either within the tui package or as a tui/viewmodel sub-package. The top-level tui.Model translates data.Session → tui.SessionVM before passing to components. Components then depend only on the view-model types and have no direct import of internal/data. This keeps the data → tui conversion in one place and decouples rendering from storage schema.
This is a gradual refactor: components can be migrated one at a time without breaking the build.