The boundary between AcquisitionsPanel.vue and AcquisitionResultTable.vue is blurred: both do data-fetching, and refresh logic is spread across both. Spun off from #20, where the fix adds yet another fetch (getListedSellTypeIds) inside the table. Worth defining a clear split — ideally the panel orchestrates data/refresh and the table is (closer to) pure presentation.
Current state
AcquisitionsPanel.vue — fetches market types + prices (getMarketTypes, appraisalStore.getPrices), builds enriched, owns the Refresh button + auto-refresh toggle, hosts the buy/sell modals, passes enriched down as items.
AcquisitionResultTable.vue — receives items, but also fetches its own data (open orders via getListedSellTypeIds), and owns filtering, grouping, tax calc, sorting, and rendering.
So data-fetching lives in both components and the "refresh" concept is implicit and split.
Scope
Decide and document the intended responsibility split (e.g. panel = data orchestration + refresh + fetching; result table = presentation over fully-prepared rows).
Reconcile where the open-order/listed state is fetched (see #20) with that split.
Refactor accordingly so each component has one clear job.
Explicitly out of scope
The behavioural bug fix in #20 (getting the listed state to refresh at all) — this is a structural follow-up, not a re-do of that fix.
Acceptance criteria
Data-fetching is not duplicated across the panel and the table; responsibilities are clearly separated.
The listed/unlisted refresh behaviour from #20 still works after the refactor.
## Summary
The boundary between `AcquisitionsPanel.vue` and `AcquisitionResultTable.vue` is blurred: both do data-fetching, and refresh logic is spread across both. Spun off from #20, where the fix adds yet another fetch (`getListedSellTypeIds`) inside the table. Worth defining a clear split — ideally the panel orchestrates data/refresh and the table is (closer to) pure presentation.
## Current state
- `AcquisitionsPanel.vue` — fetches market types + prices (`getMarketTypes`, `appraisalStore.getPrices`), builds `enriched`, owns the Refresh button + auto-refresh toggle, hosts the buy/sell modals, passes `enriched` down as `items`.
- `AcquisitionResultTable.vue` — receives `items`, but **also** fetches its own data (open orders via `getListedSellTypeIds`), and owns filtering, grouping, tax calc, sorting, and rendering.
So data-fetching lives in *both* components and the "refresh" concept is implicit and split.
## Scope
- Decide and document the intended responsibility split (e.g. panel = data orchestration + refresh + fetching; result table = presentation over fully-prepared rows).
- Reconcile where the open-order/listed state is fetched (see #20) with that split.
- Refactor accordingly so each component has one clear job.
## Explicitly out of scope
- The behavioural bug fix in #20 (getting the listed state to refresh at all) — this is a structural follow-up, not a re-do of that fix.
## Acceptance criteria
- [ ] Data-fetching is not duplicated across the panel and the table; responsibilities are clearly separated.
- [ ] The listed/unlisted refresh behaviour from #20 still works after the refactor.
## Related
- Follow-up to #20.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
The boundary between
AcquisitionsPanel.vueandAcquisitionResultTable.vueis blurred: both do data-fetching, and refresh logic is spread across both. Spun off from #20, where the fix adds yet another fetch (getListedSellTypeIds) inside the table. Worth defining a clear split — ideally the panel orchestrates data/refresh and the table is (closer to) pure presentation.Current state
AcquisitionsPanel.vue— fetches market types + prices (getMarketTypes,appraisalStore.getPrices), buildsenriched, owns the Refresh button + auto-refresh toggle, hosts the buy/sell modals, passesenricheddown asitems.AcquisitionResultTable.vue— receivesitems, but also fetches its own data (open orders viagetListedSellTypeIds), and owns filtering, grouping, tax calc, sorting, and rendering.So data-fetching lives in both components and the "refresh" concept is implicit and split.
Scope
Explicitly out of scope
Acceptance criteria
Related