@jsenv/navi 0.29.419 → 0.29.421

package/docs/create_and_edit.md

@@ -215,6 +215,16 @@ By hand this is a `useEffect` keyed on `game?.id` — `[game]` is the natural,
 wrong, thing to write — and a passive effect is too late: the screen opens
 **already changed**, and Save sends the resource back untouched.
 
+`defaultValue={game?.name}` on the fields needs no copy — a field follows a new
+default while it holds no edit
+([control_value.md](./control_value.md#a-defaultvalue-follows-what-it-was-read-from))
+— and fails the same way: a default is a suggestion the form does not hold, and
+confirming one is an answer
+([form_changed.md](./form_changed.md#what-counts-as-already-held)), so the
+untouched game goes out on the first Save. What the copy gives up is that
+follow: a game moved while the screen is open stays as `onLoad` found it — which
+a screen left on saving, and copied afresh when it opens again, can afford.
+
 **Or the screen waits, showing nothing of the form**: a skeleton until the
 resource is there, then the form holding its values from its first render —
 for a screen that can be blanked without the person losing their place.

package/docs/data_states.md

@@ -73,14 +73,13 @@ means something different:
 whose params name a row the store already holds — read earlier by a `GET_MANY`,
 a relation, a list — starts on the second line, not the first: the row is
 drawn, the request goes out behind it, and a failure lands beside it like any
-refresh failure. A row known from the previous page load counts too, when the
-resource asks for it:
+refresh failure. A `GET` of a row the store lacks starts on the first line, so
+what is drawn is never a different row — a `GET` bound through a signal (a route
+action, a `bindParams` holding one) included, when the signal moves to other
+params. A row known from the previous page load counts too, when the resource
+asks for it:
 [`persist`](./resource.md#persist-the-last-answer-drawn-again-after-a-reload)
-puts a reload on the second line as well. A `GET` bound through a signal — a
-route action, a `bindParams` holding one — is on the second line when the signal
-moves to params it has not answered yet, with the previous params' row: its
-`data` stays that row until the new answer lands, whether or not the store holds
-the new one.
+puts a reload on the second line as well.
 
 **The emptiness test is `data === undefined`, never `loading`.** Reading
 `loading` as "there is nothing to display" blanks the screen on every refresh —

package/docs/form_changed.md

@@ -16,9 +16,11 @@ later.
 
 ## Sending nothing is the default
 
-Submitting a form nobody touched — one just rendered, one whose fields still
-hold their defaults, one reopened and left alone — runs **no action**. No
-request, nothing in the network tab.
+Submitting a form nobody touched — one just rendered, one reopened and left
+alone — runs **no action**. No request, nothing in the network tab. The
+exception is a field still showing its `defaultValue`: confirming a suggestion
+is an answer, sent once (see
+[What counts as already held](#what-counts-as-already-held)).
 
 Everything around the action still happens: the constraints are checked, and
 what follows the send still follows it — the popup closes, the slide moves on,

package/docs/popup_open.md

@@ -894,14 +894,24 @@ off it (the default of a picker told no value), fields a surrounding form
 submits, a size measured from outside. `"idle"` is `"always"` minus the cost on
 the render that draws the page.
 
-Whatever the value but `"while-opened"`, intent on the anchor — a pointer
-entering it, focus landing in it — builds the content ahead of the click,
-`onOpen` or not. A `"while-opened"` popup is warmed only by a press on what
-opens it (a `--navi-open` button, a picker's trigger when a press opens it, an
-expandable's UI part), throws that content away when the press ends without
-opening it — one content at a time — and is never warmed on a
-`Dialog`/`Popover` with an `onOpen`: the one value where the content is always
-built after `onOpen`.
+Whatever the value but `"while-opened"`, intent on what opens the popup builds
+the content ahead of the click, `onOpen` or not: a pointer over its anchor, or
+focus landing in it. The anchor only says where the popup is placed, so what
+counts is the control that intent is aimed at: the anchor itself when it is a
+control, or the one the popup is written in (a picker's trigger). Any other
+control inside the anchor keeps the intent for itself. A player's own picker,
+inside a card that another picker opens from, warms the player's callout and
+never the card's sheet; tiles anchored on the whole bar they sit in warm only
+the menu of the tile under the pointer. A pointer on a trigger that a press does
+not open — a picker with `openOn={[]}`, or one opened by a hold — warms nothing:
+the card it draws is pressed all day for what it holds. Focus on it still warms,
+since the keyboard opens it.
+
+A `"while-opened"` popup is warmed only by a press on what opens it (a
+`--navi-open` button, a picker's trigger when a press opens it, an expandable's
+UI part), throws that content away when the press ends without opening it — one
+content at a time — and is never warmed on a `Dialog`/`Popover` with an
+`onOpen`: the one value where the content is always built after `onOpen`.
 
 `"while-opened"` is for content whose fresh state is its initial state. An
 untouched field does not need it to show a new `defaultValue`: it follows one

package/docs/scroll.md

@@ -136,7 +136,7 @@ makes that possible is `searchText` on the `List` — without it the list sees n
 children and nothing else.
 
 - **While the search is on**, the list scrolls back to its first row every time
-  the best matches change (the top `renderBudget` rows, by id and
+  the best matches change (as many top rows as the window draws, by id and
   `matchInfo.matchScore`), so a letter that promotes nobody new leaves the list
   where the user put it.
 - **When the search is emptied**, the list returns to the offset it was at when
@@ -286,13 +286,24 @@ sheet, a handful of tabs. A collection whose size the caller does not decide
 </List>
 ```
 
-The run draws only the rows inside the **render window** — `renderBudget` of
-them, 100 by default — and holds the room of the others with fillers, so the
-scrollbar says how long the collection is and the DOM says how many rows fit a
-screen and some. The window slides as the user scrolls, ahead of the direction
-the user goes, so the budget has to exceed what the scroller shows at once,
-with room for that lookahead: the list warns below 30, and when a budget leaves
-fewer than two rows beyond the screen.
+The run draws only the items inside the **render window** — `renderBudget`,
+`"100item"` by default — and holds the room of the others with fillers, so the
+scrollbar says how long the collection is and the DOM says how many items fit a
+screen and some. The window slides as the user scrolls, three quarters of what
+the screen leaves of it ahead of the direction the user goes, so the budget has
+to exceed what the scroller shows at once, with room for that lookahead: the
+list warns when it leaves less than two items beyond the screen.
+
+The budget is a count of items or a size: `"300px"`, or `"150%"` of the
+viewport of the box that scrolls the list. A size is for items that do not
+weigh the same: a list mixing one-line items and full cards (a thread of past
+games and games to come) holds ten times more of the first on a screen than of
+the second. `"100item"` covers four screens of the one-line items and thirty of
+the cards, and nobody scrolls to the thirtieth; a count right for the cards
+leaves blank screens when a fling crosses the one-line items. With a size, the
+window weighs the items it draws where they stand, and an item it has not drawn
+yet like the drawn items next to it — items of one kind come together — then
+weighs it again once it is drawn.
 
 A run whose rows all fit the window is just rows: nothing is virtualized, and
 it costs what the same rows would as children. There is no reason to hold back
@@ -304,12 +315,15 @@ A popup's content is built in the click that opens it (see
 [popup_open.md](./popup_open.md)), and a page coming back in a route transition
 is built in the transition's update callback: rows below the fold cost the same
 there as rows on screen, and delay the movement. `renderBudget` takes
-`{ initial, after }` for exactly this: `initial` rows in the commit the browser
-paints first — what a phone screen shows, plus a few — counted from the row the
-list opens on, and `after` from the paint on. A position handed back with its
-`visibleCount` sizes that first window itself, whatever `initial` guessed. The
-runs ask their source for `after` rows from the start, so the smaller first
-window costs no second request.
+`{ initial, after }` for exactly this: `initial` for the picture the browser
+paints first, counted from the item the list opens on, and `after` from the
+paint on. `initial: "100%"` is the screen and nothing more, whatever the items
+weigh: a few are drawn to be measured, and the window is sized on them before
+the browser paints — a count (`initial: 6`) is a guess that holds for one kind
+of item only. A position handed back with its `visibleCount` sizes that first
+window itself, whatever `initial` says. The runs ask their source for a page of
+items (`<List.Items pageSize>`, 100 by default) whatever either says, so the
+smaller first window costs no second request.
 
 The switch waits for the paint itself. Do not rebuild it with a `useEffect`
 that widens a slice: preact runs a component's pending effects early when that

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.419",
+  "version": "0.29.421",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {
@@ -34,7 +34,7 @@
     "preact": "^11.0.0-rc.2"
   },
   "dependencies": {
-    "@jsenv/dom": "0.17.85",
+    "@jsenv/dom": "0.17.86",
     "@jsenv/humanize": "1.8.6",
     "@jsenv/validity": "0.4.5"
   },