feat(data-table): lay one element across a whole row - #53
Merged
Conversation
Every table cell is `overflow_hidden`, which is what keeps a long value out of its neighbour's column. It also means a row that wants to say ONE thing across its full width cannot say it through a cell: a section heading put in the leftmost column is cut at that column's edge however much empty room the rest of the row has, and the final render widths are resolved inside the table from a measured viewport, so no caller-side offset can fix it either. `MoonTableRow::banner` / `MoonDataRow::banner` take one element and paint it across the row, after the cells and outside their clipping. Painting last decides what the eye sees, never what the mouse reaches: the wrapper is deliberately not occluded, so a cell underneath stays clickable. The consequence to design around is the opposite of occlusion - a handler on the banner and one on a cell beneath it both fire for a single click, and a caller that wants the banner to win says so itself. `has_banner` is a crate-internal predicate rather than an exposed field: the forward crosses a module boundary and nothing below it is observable without a rendering harness, so the conversion would otherwise be untestable, while a public field would let any module move the element out of a row it does not own.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Every
MoonDataTablecell isoverflow_hidden— that is what keeps a long value out of itsneighbour's column. It also means a row that wants to say ONE thing across its full width cannot
say it through a cell: a section heading placed in the leftmost column is cut at that column's
edge no matter how much empty room the rest of the row has. Fixing it from the caller's side is
not possible either, because the final render widths are resolved inside the table from a
measured viewport (
auto_width_columns), so any offset computed outside is wrong exactly on anarrow panel.
MoonTableRow::banner/MoonDataRow::bannertake one element and paint it across the row,after the cells and outside their clipping.
Two design points worth reviewing:
HitboxBehavior::BlockMousehitbox, set solely by
occlude(), and this wrapper calls neither — so a cell underneath staysclickable. The consequence to design around is the opposite of occlusion: a handler on the
banner and one on a cell beneath it both fire for a single click. Documented on the builder.
has_banneris apub(crate)predicate, not an exposed field. The forward crosses a moduleboundary and nothing below it is observable without a rendering harness, so the conversion would
otherwise be untestable; a public field would let any module in the crate move the element out
of a row it does not own. It carries
#[cfg_attr(not(test), allow(dead_code))]— conditional, soa real orphaning still warns.
How to verify
data_row_conversion_preserves_banner_presenceis mutation-proven: deleting the forward inas_table_rowreddens it, and it asserts both directions so a mutation that hard-codestruecannot pass. The baseline refresh adds exactly the two new
banner()signatures.