forked from mengyxu/noob-components
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
54 lines
3.0 KiB
54 lines
3.0 KiB
3 months ago
|
# Observations
|
||
|
|
|
||
|
|
## Exported Component Path
|
||
|
|
|
||
|
|
- The live `ListTableV2` used by the examples page is exported from [packages/base/index.ts](../../../../packages/base/index.ts) via `./data/list-table-v2/list-table-v2.vue`.
|
||
|
|
- Earlier styling work had touched a different file, `packages/base/data/list-table-v2.vue`, which is not the component currently exported to the examples app.
|
||
|
|
|
||
|
|
## Section 8 Fixed Row Height Behavior
|
||
|
|
|
||
|
|
- Section 8 of the demo page uses plain columns without explicit widths.
|
||
|
|
- In the exported component, fixed row height mode had not originally changed the width path directly, but row-height handling and width/render behavior were easy to confuse because the exported implementation diverged from the older wrapper file.
|
||
|
|
|
||
|
|
## Wrapping Logic
|
||
|
|
|
||
|
|
- There is no explicit semantic classifier for “wrappable” vs “unwrappable” values.
|
||
|
|
- For normal body cells, width estimation uses shrink-wrap text measurement, which is effectively an unwrapped width preference.
|
||
|
|
- For normal body cells, row-height estimation uses wrapped text measurement at the current column width.
|
||
|
|
- Rendered body cells are wrappable by default through CSS:
|
||
|
|
- `white-space: normal`
|
||
|
|
- `word-break: break-word`
|
||
|
|
- Header text is explicitly non-wrapping through CSS:
|
||
|
|
- `white-space: nowrap`
|
||
|
|
- Custom renderer / slot cells are not text-measured with pretext; they use fallback height behavior instead.
|
||
|
|
|
||
|
|
## Minimum Width Logic
|
||
|
|
|
||
|
|
- If a column has explicit `width`, runtime style sets:
|
||
|
|
- `width = explicitWidth`
|
||
|
|
- `minWidth = explicitWidth`
|
||
|
|
- `maxWidth = explicitWidth`
|
||
|
|
- If a column has explicit `minWidth`, that value becomes the computed `minWidth`.
|
||
|
|
- Otherwise, automatic `minWidth` is derived from measured text statistics:
|
||
|
|
- measure shrink-wrap width of header text
|
||
|
|
- measure shrink-wrap width of sampled cell text
|
||
|
|
- compute `mean` and `variance`
|
||
|
|
- set `minWidth = max(mean - 2 * sqrt(variance), MIN_BASE_WIDTH) + CELL_PADDING`
|
||
|
|
- This means auto `minWidth` is a statistical lower bound, not the width of the longest value.
|
||
|
|
- If computed config is unavailable, the runtime fallback path uses `col.minWidth ?? 120` with a floor of `50px`.
|
||
|
|
|
||
|
|
## Timestamp Width Bug Root Cause
|
||
|
|
|
||
|
|
- Timestamp columns were rendered using formatted values, but width estimation had been measuring raw values.
|
||
|
|
- Example:
|
||
|
|
- rendered timestamp looked like `2026-04-08 12:34:56`
|
||
|
|
- width estimation measured the raw Unix value like `1712579696`
|
||
|
|
- This mismatch caused timestamp columns to be under-sized relative to their actual displayed content.
|
||
|
|
- The discrepancy between section 1 and section 4 timestamp-related widths came from the width hook deriving stats from sampled measured values, combined with the mismatch between raw and formatted text.
|
||
|
|
|
||
|
|
## Fix Applied During This Session
|
||
|
|
|
||
|
|
- `usePretextColumnWidths` now accepts `formatCellValue` so width estimation uses the same displayed text as the rendered cell.
|
||
|
|
- The exported `ListTableV2` passes its `formatCellValue` implementation into the width hook.
|
||
|
|
- Scoped lint passed on the touched table-v2 files after this change.
|