@jsenv/navi 0.29.493 → 0.29.494

package/docs/resource.md

@@ -566,7 +566,8 @@ out with an example in its JSDoc:
   parent the store does not hold yet is left alone: its array comes with its
   next read.
 - **`.scopedOne(propertyName, callbacks)`** — every callback returns
-  `[ownerId, props | null]`; the property is `null` until one does. An owner
+  `[ownerId, props | null]`; the property is `undefined` until the owner's row
+  or a callback speaks for it, `null` when that answer holds none. An owner
   the store does not hold yet is left alone: the answer is the action's value,
   and the owner's next read brings its child.
 - **`.scopedMany(propertyName, { idKey, … })`** — `[ownerId, props]`; `PUT` (an

package/docs/testid.md

@@ -213,7 +213,7 @@ side holds is a vnode of yours that takes its own.
 Navi's own attributes are implementation, not a contract: `data-header`,
 `data-body`, `data-scrollable`, `data-variant`, `data-callout-*`,
 `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
+given (`navi_<n>`), 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. The exception is the state
 a guideline doc tells an app to read — `navi-refreshing`

package/package.json

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