@jsenv/navi 0.29.389 → 0.29.390

package/docs/drag_interactions.md

@@ -373,11 +373,19 @@ copy where the hand put it, over the thing appearing there.
 #### Naming what travels
 
 **The copy is already named, and it is the copy that does the visible travel.**
-It answers to `navi-drag-clone` (the wrapper carrying it paints nothing and takes
-no name), and `syncCloneWithDropTarget` moves it onto the destination inside the
-callback — so the piece the hand let go of slides to its place whether the
-application names anything or not. What is left to name is the OTHER one: the
-piece that was standing there and has to go the other way.
+`syncCloneWithDropTarget` moves it onto the destination inside the callback — so
+the piece the hand let go of slides to its place whether the application names
+anything or not. What is left to name is the OTHER one: the piece that was
+standing there and has to go the other way.
+
+The name is the copy's own, because two copies can be on screen at once — one
+still flying away while its `toss` is answered, another landing — and a name
+claimed twice aborts the transition. What every copy shares is the class
+`navi-drag-clone`, which is how a stylesheet reaches the landing:
+`::view-transition-group(.navi-drag-clone)`. A view-transition class is read
+from Chrome 125 on; before that the landing still plays, and only a rule written
+against the class goes unread. The wrapper carrying the copy paints nothing and
+takes neither.
 
 **And the original is hidden for the whole landing**, not only for the drag: it
 wears `navi-drag-clone-source` (`visibility: hidden`) until the promise returned

package/docs/pan_zoom.md

@@ -42,14 +42,21 @@ when it lands; the pan stepping back for what is carried across the surface (a
 `move`, a handle, a field, a popover — the same list a travelling box steps back
 for); the pinch not beginning as a pan under its first finger; the wheel and the
 pinch writing one `zoom`; the capture, the pointer the browser drops, the click
-the release leaves behind. A pointer pans only once it has travelled a few px
-(`data-drag-threshold`), so a tap stays a tap: a `longpress` declared beside
-`pan` still gets its hold, and a `double_click` still gets its two presses.
+the release leaves behind, and the next tap's click, which Chrome on Android
+drops after a touch drag whose `touchmove`s nobody refused (see
+[mobile_tap_suppression_after_drag.md](./mobile_tap_suppression_after_drag.md)).
+A pointer pans only once it has travelled a few px (`data-drag-threshold`), so a
+tap stays a tap: a `longpress` declared beside `pan` still gets its hold, and a
+`double_click` still gets its two presses. A press that does pan is the
+surface's: a `longpress` waiting on it gives up the moment the pan begins, even
+inside its own slop.
 
 Declared alone, `zoom` takes two fingers and the wheel and leaves one pointer to
 whatever else reads it: nothing captures it, waits on it or swallows its click
 until a second finger lands, so a `click` or a `longpress` declared beside `zoom`
-answers it as it would anywhere. `pan` alone leaves the wheel to the page.
+answers it as it would anywhere. From the second finger on, both are the pinch's,
+and a `longpress` waiting on the first gives up. `pan` alone leaves the wheel to
+the page.
 
 ### A surface that scrolls past: `data-pan-after-hold`
 

package/docs/resource.md

@@ -42,6 +42,7 @@ looks like ([data_states.md](./data_states.md#data-and-loading-are-independent))
   - [`.many(propertyName, childResource, restCallbacks)`](#manypropertyname-childresource-restcallbacks)
   - [`.scopedOne(propertyName, { idKey, GET, POST, PUT, PATCH, DELETE })`](#scopedonepropertyname--idkey-get-post-put-patch-delete-)
   - [`.scopedMany(propertyName, { idKey, GET, GET_MANY, POST, PUT, PATCH, DELETE, … })`](#scopedmanypropertyname--idkey-get-get_many-post-put-patch-delete--)
+  - [A relation declared on a scoped child](#a-relation-declared-on-a-scoped-child)
 - [When the backend answers a sub-route with the whole parent](#when-the-backend-answers-a-sub-route-with-the-whole-parent)
 - [Relations and autorerun](#relations-and-autorerun)
 - [`withParams()`: a scope with reruns of its own](#withparams-a-scope-with-reruns-of-its-own)
@@ -359,6 +360,43 @@ const GAME_CANDIDATES = GAME.scopedMany("candidates", {
 `idKey` names the child's own key inside its owner (`user_id` above); it defaults
 to `"id"`.
 
+### A relation declared on a scoped child
+
+A scoped child takes relations of its own — a column pointing at a shared data
+type:
+
+```js
+const TABLE_COLUMNS = TABLE.scopedMany("columns", {
+  idKey: "name",
+  GET_MANY: async ({ id }) => [id, await fetchJson(`/tables/${id}/columns`)],
+  // [id, [{ name: "email", dataType: { id: 2, name: "varchar" } }, …]]
+  PATCH: async ({ id, name, ...props }) => [
+    id,
+    await fetchJson(`/tables/${id}/columns/${name}`, {
+      method: "PATCH",
+      body: props,
+    }),
+  ],
+});
+TABLE_COLUMNS.one("dataType", DATA_TYPE);
+```
+
+Every column gets a reactive `dataType` read from the `DATA_TYPE` store, fed by
+what the scoped child's callbacks embed. The relation itself takes none of the
+callbacks whose result names the column — `.one()`'s `GET`/`PUT`/`DELETE`,
+`.many()`'s `GET_MANY`/`DELETE`/`DELETE_MANY`, and every callback of a
+`.scopedOne()`/`.scopedMany()`, whose `ownerId` would be the column: they name
+it by its `name` alone, and a column exists only inside its table — two tables
+can each have an `email`. Declaring one throws. A column's data type is read and
+changed through `TABLE_COLUMNS`, whose results say which table
+(`[id, { name, dataType }]`); the fields of a data type itself, through
+`DATA_TYPE`.
+
+A `.scopedOne()`/`.scopedMany()` chained on a scoped child works the same way,
+and keeps one value per column: `TABLE_COLUMNS.scopedMany("constraints")` gives
+`users.email` and `admins.email` a collection each, fed by the `constraints`
+embedded in each table's columns.
+
 ## When the backend answers a sub-route with the whole parent
 
 This is the common REST shape, and it is the reason `op` dispatch feels
@@ -405,7 +443,8 @@ parent's own fields change too, either let the parent GET rerun (see below) or
 Relationship mutations do **not** invalidate their parent by default. The exact
 rules, verified by `src/state/rest/tests/resource_graph_parent_rerun.test.js`:
 
-- `.scopedMany` child **POST** reruns the owner's singular `GET` — but only when
+- `.scopedMany` child **POST** reruns the owner's singular `GET`, whether it
+  goes through the child or through a `withParams()` scope of it — but only when
   the last GET response actually embedded that property. GET_MANY on the parent
   is never rerun by a child POST (a list of parents is not stale because one of
   them gained a child).
@@ -459,6 +498,11 @@ share is the **store**: an item updated through one is the same object in the
 others, so the fields of a row change everywhere without a request — only the
 membership of each list is a question its own scope answers.
 
+It scopes a relation as well as a resource, and the scope's actions are the
+relation's: `TABLE_COLUMNS.withParams({ withTypes: true }).GET_MANY` keeps the
+`[ownerId, items]` contract of `.scopedMany()` and replaces that table's
+columns.
+
 `withParams()` chains, merging the params —
 `USER.withParams({ role: "admin" }).withParams({ gender: "male" })` is
 `USER.withParams({ role: "admin", gender: "male" })`. Its second argument takes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.389",
+  "version": "0.29.390",
   "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.73",
+    "@jsenv/dom": "0.17.74",
     "@jsenv/humanize": "1.8.5",
     "@jsenv/validity": "0.4.5"
   },