@jsenv/navi 0.29.482 → 0.29.483

package/docs/data_states.md

@@ -38,6 +38,12 @@ the component reads:
 | `error: true`   | suspends                  | `error`, plus `dismissError` |
 | both            | `loading`                 | `error`                      |
 
+A delegated failure is thrown whatever the action still holds: a refresh that
+fails — the rerun when the app comes back to the foreground, a dependency's —
+takes rows that were on screen to the boundary, whose fallback replaces them. A
+reader with something to keep showing asks for `error: true`, and each reader of
+a shared action decides this on its own.
+
 The invariant that makes this worth relying on: **`loading: true` never
 suspends.** Not while the action runs, not while a debounced binding is
 settling, not while it holds params nobody has started yet, not after a failure

package/docs/dynamic_import.md

@@ -214,8 +214,10 @@ failed as failed: a second `import()` of the same address is refused without a
 request, for the life of the document. So a retry has nothing to do —
 `error.action.rerun()` fails again at once, on the same failure — and the one way
 out is a fresh document: **`window.location.reload()`**, which the screen offers
-in words the reader understands. navi does not reload on its own: a document
-reloading itself is a loop waiting to happen.
+in words the reader understands. Not navi's own `reload()`: it asks the route
+actions again inside this same document, and the import fails again at once.
+navi does not reload on its own: a document reloading itself is a loop waiting
+to happen.
 
 The page or the component reading its code says it where it stands, as above. A
 failure left to a boundary reaches it like a failed read does; a boundary that

package/docs/navigation.md

@@ -388,7 +388,12 @@ section of pages shares one:
 <Route>
   <ErrorBoundary
     fallback={({ error, resetError }) => (
-      <ErrorScreen error={error} onRetry={resetError} />
+      <ErrorScreen
+        error={error}
+        // the rerun lifts the boundary; resetError only dismisses, and a
+        // page that never loaded has nothing to show once dismissed
+        onRetry={error.action ? () => error.action.rerun() : resetError}
+      />
     )}
   >
     <Loading fallback={<GameSkeleton />}>
@@ -452,6 +457,9 @@ with `currentAlso={[PLACE_ROUTE]}`, and `currentExcept` names a place under the
 section it does NOT stand for. Both amend what a link claims about itself and
 nothing else — neither is an answer to a route that lies about where the reader
 is (see [what its address may say](#a-layer-over-the-screen-what-its-address-may-say)).
+A bar entry drawn as a button for its press feedback says the same with
+`<Button route currentAlso currentExcept>`: it is drawn as a link and wears
+`aria-current="page"` from the same reading.
 
 The routing takes a plain click that moves this tab, and nothing else. A link
 with `target="_blank"` (or any `target` other than `_self`) opens the app in that

package/docs/popup_open.md

@@ -455,7 +455,10 @@ None of them is "one popup per row of a list", which is what a picker is for.
 
 `onOpen` is called on every open (for when, see
 [above](#onopen-runs-before-the-popup-has-built-anything)), and `onClose` on
-every real close, with `detail.isCancel` when the close meant "revert". Neither
+every real close, with `detail.isCancel` when the close meant "revert" and
+`detail.isConfirm` when it was a `--navi-confirm` saying yes — so a shared Dialog
+asking a yes/no question after a gesture already over answers it there
+(`onClose={(e) => e.detail.isConfirm && release()}`). Neither
 can veto: `onClose` is the close happening, not a request to close. The refusals
 are navi's: a close over a control mid-action, and a `Picker`'s close over a
 value that does not validate.
@@ -923,6 +926,11 @@ option is the component drawing its own wait
 (`useAsyncData(action, { loading: true })`); what is not an option is neither.
 Both are on `src/layout/demos/13_popup_loading_demo.html`.
 
+The failure has no boundary of its own either: delegated, it lands on the
+nearest `<ErrorBoundary>` above the popup — the one holding the page, whose
+fallback replaces the page under it. A read inside a popup takes `error: true`
+and says the failure where it stands.
+
 What the popup gains is everything a page has: the request leaves **with the
 screen**, in parallel with the rest of what the address needs, instead of behind
 the gesture that opens the popup; `useAsyncData` reads it (see

package/docs/testid.md

@@ -149,7 +149,9 @@ or waits for it to show, targets what the row draws: a testid on its content.
 What navi builds itself is named through props. A `data-testid` on a `<Picker>`
 names the trigger; `popupTestId` names the popup it builds (the callout, under
 `mode="callout"`), and `confirmTestId` / `cancelTestId` the yes and no buttons
-of a `type="confirm"` picker's default body:
+of a `type="confirm"` picker's default body. Likewise `menuTestId` names a
+`SplitButton`'s chevron half, and `previousTestId` / `nextTestId` a `Spin`'s
+two ways out (a `DaySpin`'s, a `NumberSpin`'s):
 
 ```jsx
 <Picker data-testid="tie-break" popupTestId="tie-break-sheet">

package/package.json

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