88 lines
3.1 KiB
Markdown
88 lines
3.1 KiB
Markdown
# Asset Bank Composition Base Components Agenda
|
|
|
|
Status: Open
|
|
Domain Owner: `docs/studio`
|
|
Cross-Domain Impact: `docs/packer`
|
|
|
|
## Problem
|
|
|
|
The `Bank Composition` section depends on two new Studio components:
|
|
|
|
- `StudioDualListView<T>`
|
|
- `StudioAssetCapacityMeter`
|
|
|
|
Those components need a first-wave contract and scope before the section shell or middleware can be implemented safely.
|
|
|
|
## Context
|
|
|
|
The current direction is already partially fixed:
|
|
|
|
- `StudioDualListView<T>` should be abstract;
|
|
- the first concrete subclass should be asset-details-specific;
|
|
- right-list ordering must support `move up`, `move down`, and visible indices;
|
|
- `StudioAssetCapacityMeter` should be a vertical, game-like progress bar with color bands and percentage text;
|
|
- both components should stay intentionally dumb and leave family-specific rules to middleware/controller logic.
|
|
|
|
## Options
|
|
|
|
1. Build highly generic reusable components from the start.
|
|
2. Build bank-composition-scoped Studio components with narrow first-wave APIs.
|
|
3. Skip dedicated components and build the section directly inside `AssetDetails`.
|
|
|
|
## Tradeoffs
|
|
|
|
1. Highly generic components risk overengineering before the first section is proven.
|
|
2. Narrow first-wave components keep momentum and preserve room to generalize later from real usage.
|
|
3. Inline section code would move faster once, but it would bury behavior that already deserves named UI building blocks.
|
|
|
|
## Recommendation
|
|
|
|
Build dedicated first-wave components with narrow APIs:
|
|
|
|
- abstract `StudioDualListView<T>` as the transfer-list base;
|
|
- one asset-details concrete subclass first;
|
|
- `StudioAssetCapacityMeter` as a dumb vertical meter component with color thresholds and percentage display.
|
|
|
|
Do not force broad reuse rules yet.
|
|
|
|
### First-Wave Component Baseline
|
|
|
|
The first-wave component contract should stay intentionally small.
|
|
|
|
`StudioDualListView<T>` should expose only the hooks needed for the initial bank-composition section:
|
|
|
|
- row text and/or row graphic projection;
|
|
- current left and right collections;
|
|
- current selection state;
|
|
- move left-to-right;
|
|
- move right-to-left;
|
|
- `moveUp`;
|
|
- `moveDown`;
|
|
- visible index refresh for the right-side list.
|
|
|
|
The first concrete asset-details subclass should render rows directly.
|
|
Do not introduce a separate row renderer abstraction yet.
|
|
|
|
`StudioAssetCapacityMeter` should start as a dumb visual component with these baseline inputs:
|
|
|
|
- `progress` in the `0..1` range;
|
|
- a label, including percentage text when needed;
|
|
- a severity band state;
|
|
- optional hint text.
|
|
|
|
## Open Questions
|
|
|
|
No open questions remain in this agenda wave.
|
|
|
|
### Resolved In This Agenda Wave
|
|
|
|
The following points are now closed:
|
|
|
|
1. `StudioDualListView<T>` should expose only a narrow first-wave hook set for row projection, selection, transfers, reordering, and right-list index refresh.
|
|
2. The first concrete asset-details subclass should own row rendering directly.
|
|
3. `StudioAssetCapacityMeter` should start with `progress`, label, severity band state, and optional hint text.
|
|
|
|
## Next Suggested Step
|
|
|
|
Turn this into a `decision` that fixes the first-wave component contracts for `StudioDualListView<T>` and `StudioAssetCapacityMeter`.
|