applyListViewSkeletonRowCountUpdate
applyListViewSkeletonRowCountUpdate(
props):ListViewSkeletonRowCountMap
Defined in: packages/core/src/collections/listView/listViewSkeletonRowCountCookie.ts:88
Updates map with viewId’s new ListViewSkeletonRowCountEntry, re-inserted with a fresh,
monotonically-increasing seq (most-recently-used) and capped at
LIST_VIEW_SKELETON_ROW_COUNT_COOKIE_MAX_ENTRIES — the entries with the LOWEST seq (oldest) are
dropped once the cap is exceeded, so a caller visiting many different views over time never
grows this cookie unboundedly.
Orders by each entry’s own seq field, NEVER by the map’s JS object key order — a plain
object’s own key enumeration promotes an integer-LIKE string key (e.g. a config view’s
viewId: "1", legal and common) to the FRONT, in ascending numeric order, regardless of
actual insertion order (the JS spec’s [[OwnPropertyKeys]] enumeration rule) — and that
reordering is baked into the object ITSELF, not just one call’s own iteration, so even
rebuilding a Map from Object.entries(props.map) within a single call cannot recover true
order once props.map already contains such a key (confirmed live: a Map-only fix still
failed this exact scenario across two sequential calls). seq sidesteps the problem
entirely by never depending on key order at all (polish fix).
Parameters
Section titled “Parameters”number
The settled row count (already capped at that load’s pageSize by the
caller — this function does no capping of the VALUE itself, only of the map’s entry count).
boolean
Whether that result was the view’s last page (pagination.isDone).
The current map (from parseListViewSkeletonRowCountCookie).
viewId
Section titled “viewId”string
The view whose result just settled.
Returns
Section titled “Returns”The updated, LRU-capped map — a new object, map is never mutated.