@jsenv/navi 0.29.107 → 0.29.108

package/docs/form_changed.md

@@ -36,7 +36,8 @@ duplicates are fine.
 
 The form has answered its question; `command` says what the screen does about
 it — dismiss the popup (`--navi-close`), move on the slide map
-(`--navi-left`…), go to a page (`--navi-nav-to:/games/42`), stay put
+(`--navi-left`…), go to a page (`--navi-nav-to:/games/42`), go back to the one
+the reader came from (`--navi-nav-back:/games`), stay put
 (`--navi-void`). Left out, the surface the form sits in decides: a popup closes,
 a slide goes on, a form on a page does nothing.
 

package/docs/navigation.md

@@ -384,7 +384,8 @@ top, the phone's own) leaves by where the reader came in:
 
 The link stays a link — an address, a middle click, the keyboard, `aria-current`
 — only the way there changes. It is the same word as `navTo(url, { replace:
-true })` and `route.redirectTo()`.
+true })` and `route.redirectTo()` — and as `<Button replace>`, on an `href` or
+on a `--navi-nav-to` command.
 
 A replaced entry inherits the state of the one it takes the place of (so does
 `route.redirectTo()`): **an entry's state does not say how it arrived**. Only
@@ -427,6 +428,13 @@ back button would walk straight back into it — a loop with no way out of the
 app. Without a `fallback`, a `navBack()` with nothing of ours behind does
 nothing.
 
+Said by a button, it is a command, the fallback being its argument the way
+`--navi-nav-to` carries its destination:
+
+```jsx
+<Button command={`--navi-nav-back:${USER_ME_ROUTE.buildUrl()}`}>←</Button>
+```
+
 ## Tabs that travel: `RouteTravel`
 
 `<RouteTravel>` wraps the `<Route>` tree of a row of tabs and makes every change

package/docs/testid.md

@@ -83,12 +83,30 @@ error message, a section, a row — put the testid on the surrounding component
 (`<Field data-testid="email-field">`, `<Box data-testid="cart-row">`); anything
 built on `Box` forwards it to its own element.
 
+A picker's popup is the one element the application does not render itself:
+`<Picker>` builds it, so a `data-testid` on the picker names the trigger and
+nothing names the popup. `popupTestId` does:
+
+```jsx
+<Picker data-testid="tie-break" popupTestId="tie-break-sheet">
+  …
+</Picker>
+```
+
+Most tests do not need it — a testid on what the popup holds (`<Box
+data-testid="place-pick">` among the children) names the screen, not the frame,
+and is the better name for a test that reads or clicks the content. Reach for
+`popupTestId` when the frame IS what the test looks at: a screenshot of the
+popup's surface, its position, its size, its backdrop.
+
 ## What not to target
 
 Navi's own attributes are implementation, not a contract: `data-header`,
 `data-body`, `data-scrollable`, `data-variant`, `data-callout-*`,
-`navi-control*`, `.navi_*` class names, and the ids navi generates when none is
-given (`useId`). They change without notice and without a migration note.
+`navi-control*`, `.navi_*` class names, the ids navi generates when none is
+given (`useId`), and the ids it derives from yours (a picker's popup id is built
+from the picker's, so the suffix is navi's even when the base is not). They
+change without notice and without a migration note.
 Likewise a `view-transition-name` or a CSS variable: those exist to draw, not
 to be found.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.107",
+  "version": "0.29.108",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {