1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
//! Large-data surfaces: a virtualized list, two tables, and a tree.
//!
//! [`Table`] lays out every row it is given as [`Table::rows`], because the
//! caller built those elements already; handed a count and a closure through
//! [`Table::rows_from`], it lays out only the ones its viewport holds.
//! [`DataGrid`] takes a render closure and lays out only the rows its viewport
//! holds, which is what buys it column resizing and reordering, a pinned
//! group, selection over an incompletely loaded set, opened rows, and cell
//! editing. `docs/components.md` has the guidance on which to reach for.
//!
//! None of these owns the data. Rows, order, expansion, and selection are all
//! caller-owned; each surface reports what was operated and renders exactly
//! what the caller says is true, so a host that refuses a change keeps showing
//! the state that still holds.
//!
//! The rule that separates these from the rest of the library: **only rendered
//! rows publish semantics.** A virtualized surface holds a viewport, not a
//! data set, so a test can assert only what is on screen. The container node
//! carries the total in `value`, which is how a snapshot stays honest about
//! the difference between a thousand items and the twelve that are drawn. A
//! [`Tree`] counts the rows it disclosed, so a node under a shut branch, a
//! disclosed node that scrolled past the edge, and a node that is not in the
//! data at all remain three different things.
//!
//! Virtualization needs a bounded viewport. Every surface here takes a
//! `visible_rows` bound, and without one it sizes itself to its content and
//! lays every row out — which is the right answer for a settings summary and
//! the wrong one for a hundred thousand log lines.
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;