@jsenv/navi 0.29.232 → 0.29.234

package/docs/form_changed.md

@@ -43,8 +43,10 @@ form sits in decides: a popup closes, a slide goes on, a form on a page does
 nothing.
 
 `--navi-reset` is the one to reach for when the form is a place one comes back
-to — an entry created, then the next one — since the fields go back to their
-`defaultValue` and the form is measured against that again:
+to — an entry created, then the next one: the fields go back to their
+`defaultValue`, ready for the next entry. (What the form is measured against
+stays what was just sent — see below — so the emptied form reads as changed,
+and the fields' own constraints are what keep an empty one from being sent.)
 
 ```jsx
 <Form action={createPlaceGroup} command="--navi-reset">

package/docs/i18n.md

@@ -143,8 +143,8 @@ preferring German resolves to German, and every key missing in German falls back
 to its key. With it, that browser lands on the app's best available language
 instead.
 
-It decides more than the wording: `<Time>`, `<Number>` and every format helper
-read the same signal, so **a document that never calls it follows the browser,
+It decides more than the wording: `<Time>` and the format helpers
+(`formatNumber`, `formatTime`, …) read the same signal, so **a document that never calls it follows the browser,
 dates and numbers included** — `2026-09-01` reads "09/01/2026" on an en-US
 machine and "01/09/2026" on a French one, from the same code and the same data.
 Nothing on screen says which reading is being applied, so this is worth one call

package/docs/navigation.md

@@ -99,10 +99,12 @@ moved by changing this one line.
 
 Two things about it:
 
-- **it belongs in the routes module, above the `route()` calls it governs** —
-  those read the base url as they are created. In the entry point it would be
-  too late: the import of the routes module runs first, and an import sorter
-  would put it there anyway;
+- **it belongs in the routes module, above `setupRoutes()`** — the base url
+  is read whenever an address is matched or built, and the first match happens
+  right there, as the routes are set up against the current address. In the
+  entry point it would be too late: the import of the routes module runs
+  first, `setupRoutes()` with it, and an import sorter would put the call after
+  anyway;
 - **the server has to answer the document for every address below it.** jsenv's
   dev server already does: an address it finds no file for is answered with the
   closest html file above it, `<dirname>.html` included, so `/admin/places/42`
@@ -341,17 +343,35 @@ a route action, and the redirection once the answer is there.
 
 ```js
 export const ADMIN_ROUTE = route("/admin");
-
-routeAction(ADMIN_ROUTE, async () => {
-  const me = await ME.GET.run();
-  firstSectionAllowed(me).redirectTo();
-});
+const anySectionMatchingSignal = anyMatchingRouteSignal([
+  PLACES_ROUTE,
+  USERS_ROUTE,
+]);
+
+routeAction(
+  ADMIN_ROUTE,
+  async () => {
+    const me = await ME.GET.run();
+    firstSectionAllowed(me).redirectTo();
+  },
+  // only on the landing itself: "/admin" also matches every section below it
+  () => !anySectionMatchingSignal.value,
+);
 ```
 
 `redirectTo()` replaces the entry rather than stacking onto it, so the back
 button still leaves by where the reader came in — the one property of a
 redirection worth keeping here.
 
+The params are not optional here, for two reasons. A container address matches
+everything below it, so without the gate the landing would fire on every
+section and send the reader back to the first one. And a route action declared
+without params is fetched ahead of the arrival — a link to it preruns it when
+the pointer reaches the link (see [dynamic_import.md](./dynamic_import.md)),
+which for a read is a head start and for a navigation is the navigation
+happening on a hover. Params say the action asks something of the address, and
+that is what keeps it from being prerun.
+
 What it costs, and there is no way around it: the address exists, and something
 is on screen while the request is out. That is honest — the reader IS waiting —
 so give `/admin` the screen a wait deserves (the section frame, a `<Loading>`)

package/docs/resource.md

@@ -514,9 +514,10 @@ two affordances for the same delete that must both go busy at once. Nothing else
 in the stack answers that question: the store holds the data, not who is
 currently writing it.
 
-Either way, what to READ afterwards is the store, or the instance that ran — a
-verb keeps no state of its own, so `GAME_CANDIDATES.POST.dataSignal` is empty
-whichever form ran it (see
+Either way, what to READ afterwards is the store, or the instance that ran —
+never the verb: a run made with params lands on the child those params made,
+so `GAME_CANDIDATES.POST.dataSignal` is empty whichever form ran it. The verb's
+own signals hold only a run made on the verb itself, with no params (see
 [actions.md](./actions.md#the-answer-is-kept-on-the-instance-that-ran)).
 
 Where it does not pay, and most call sites are here: one affordance, in one

package/package.json

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