@jsenv/navi 0.29.417 → 0.29.419

package/docs/error_handling.md

@@ -42,24 +42,20 @@ validation message on the **requester** (the submit button, not the form):
 - The message is a constraint on the control (`navi_action_error`) rather than a
   render of its own, and it **auto-resets on the next action**: hitting submit
   again clears it and re-submits, instead of the form being stuck invalid.
-- `actionErrorEffect` changes that: `"throw"` re-throws the error from a layout
-  effect so the nearest `<ErrorBoundary>` takes it (a control cannot throw from
-  an event handler and be caught — see the comment in
-  [use_execute_action.js](../src/action/use_execute_action.js)), and anything
-  else — `"none"` — means the control displays nothing because something else
-  does. `<Details>` uses that: its `<ActionRenderer>` shows the error inside the
-  open panel.
+- `actionErrorEffect="throw"` re-throws the error from a layout effect so the
+  nearest `<ErrorBoundary>` takes it — an error thrown from an event handler
+  reaches no boundary. `"none"` means the control displays nothing because
+  something else does: `<Details>` uses it, its `<ActionRenderer>` showing the
+  error inside the open panel.
 - `onActionError(error, event)` fires alongside whichever display was chosen —
   it is for reacting to the failure, not for showing it (showing stays claimed
   by the message or the boundary). Its siblings on every control with an
-  `action` — `onActionStart`, `onActionEnd`, `onActionAborted` — are in
-  [actions.md](./actions.md#the-instance-a-control-runs).
+  `action` are in [actions.md](./actions.md#the-instance-a-control-runs).
 
 #### A refusal that carries a link
 
-The callout is not limited to a sentence. When the refusal has somewhere to go —
-"this slot is already taken by that game" — the mapping returns an element and
-the callout holds it, link included:
+When the refusal has somewhere to go — "this slot is already taken by that game"
+— the mapping returns an element and the callout holds it, link included:
 
 ```jsx
 <Form
@@ -79,55 +75,39 @@ the callout holds it, link included:
 >
 ```
 
-That is the whole thing: the message arrives on the button that was pressed, it
-survives whatever ran before it (a `command` waits for its own action), and it
-clears itself on the next submit. A refusal with a destination does **not** need
-a render of its own in the page.
+The message arrives on the button that was pressed, survives whatever ran before
+it (a `command` waits for its own action), and clears itself on the next
+submit: a refusal with a destination does **not** need a render of its own in
+the page. Being an element, the message:
 
-Two consequences of the message being an element:
-
-- it is rendered as a **preact tree of its own** into the callout, not as part
-  of the app tree, so it receives no context from the app. Anything reading
-  global signals — a navi `<Link route>`, a store — works; anything expecting an
-  app `Context.Provider` above it does not, and has to be given what it needs
+- is rendered as a **preact tree of its own** into the callout, not as part of
+  the app tree, so it receives no context from the app. Anything reading global
+  signals — a navi `<Link route>`, a store — works; anything expecting an app
+  `Context.Provider` above it does not, and has to be given what it needs
   through props;
-- it has no one-line form, so nothing derives a `title` from it — the callout is
+- has no one-line form, so nothing derives a `title` from it — the callout is
   the only place it is shown. A string or an `Error` message still writes the
   control's `title` when the control has none of its own.
 
-[form_error_mapping_jsx demo](../src/control/demos/form_error_mapping_jsx/demo.html)
-shows a mapping answering with a different component per error kind.
+Reference: `src/control/demos/form_error_mapping_jsx/demo.html`, a mapping
+answering with a different component per error kind.
 
 ### A screen's data failed — a route action
 
 Nobody clicked; the page simply cannot be drawn. It is the page, or a piece of
 it, that is replaced — by an ancestor, never by a prop on the page. That is what
-`useAsyncData`'s default means: **delegate**. The component says what it renders
-when it has data, and what it cannot render is somebody else's job, up the tree:
-`<Loading>` for the wait, `<ErrorBoundary>` for the failure, both written
-between a container `<Route>` and its branches — the boundary OUTSIDE the
-`<Loading>`, since a page suspends first and fails second. The shape of that
-tree, and why a wrapper brackets a subset of the branches, is in
+`useAsyncData`'s default means: **delegate**, the wait to `<Loading>` and the
+failure to `<ErrorBoundary>`, the boundary OUTSIDE the `<Loading>` since a page
+suspends first and fails second. The shape of that tree is in
 [navigation.md](./navigation.md#loading-data).
 
-Inside the component when the error is part of what the screen draws rather than
-a screen of its own:
-
-```jsx
-const [game, loading, error, dismissError] = useAsyncData(gameAction, {
-  loading: true,
-  error: true,
-});
-```
-
-`game` and `error` arrive **together**: a refresh that failed does not unmake
-the answer the action already had, so the screen keeps what it has and says the
-failure on it, and `dismissError()` takes that message away without asking
-anything again. That is the whole difference between the two shapes — a boundary
-replaces the subtree by definition, this one writes on it — so reach for the
-boundary when the failure means the screen cannot be drawn at all, and for this
-when it means one thing about it is out of date. How the component draws the
-states it is handed is [data_states.md](./data_states.md).
+When the error is part of what the screen draws rather than a screen of its own,
+`useAsyncData(action, { loading: true, error: true })` hands it over **beside**
+the answer the action already had: the screen keeps what it has, says the
+failure on it, and `dismissError()` takes the message away without asking
+anything again. Reach for the boundary when the failure means the screen cannot
+be drawn at all, for this when it means one thing about it is out of date (see
+[data_states.md](./data_states.md#an-error-is-a-message-on-the-screen-not-the-screen)).
 
 And one row rather than the whole list: `<List.Item error>` replaces the row's
 content with the message — what the row stood for did not happen, so drawing it
@@ -137,24 +117,10 @@ as if it had would be a lie.
 
 Not an error at all, and not to be modelled as one: a value the app or the
 browser refuses is a **status on the control**, carried by navi's constraint
-validation. Never throw to reject a value — see `src/control/rules/`.
-
-An app's own rule joins that set as a constraint — `{ name, check }`, where
-`check(field)` reads `field.uiState` and returns a message or `null`:
-
-```jsx
-<Input constraints={[TEXT_SHAPE_CONSTRAINT]} />; // this control
-registerGlobalConstraint(TEXT_SHAPE_CONSTRAINT); // every control
-```
-
-A constraint is an object, so it carries whatever it needs to decide — there is
-nothing to pass through an attribute. The attributes the shipped constraints
-read (`required`, `data-single-space`, `data-displayable`…) exist because those
-constraints are global and need a per-field switch; a constraint written for
-one call site does not.
-
-Where such a rule belongs — a navi constraint, a @jsenv/validity rule the
-server runs too, or both — is `docs/field_validation.md`.
+validation. Never throw to reject a value. An app's own rule joins that set as a
+constraint — `constraints` on one control, `registerGlobalConstraint` for every
+control — and where such a rule belongs, a navi constraint, a @jsenv/validity
+rule the server runs too, or both, is [field_validation.md](./field_validation.md).
 
 ## What a failing action does
 
@@ -176,24 +142,21 @@ awaiting another one fails with it:
 ```
 
 The error is in `errorSignal` all the same: a screen reads it there whether or
-not anything was waiting on the promise. `useAsyncData`, `errorSignal` and an
-`onError` passed to the run are still how a render asks for it.
-
-Code that lets such a rejection float gets the runtime's own unhandled-error
-report — window `error`, the jsenv overlay in dev — and that is the right answer
-for it: nothing had to guess whether someone was waiting.
-
-**Some runs have nobody to reject at**, and they say so where they start: one
-started from a signal effect because its params changed, one started by the
-render that reads it (`{ run: true }`), one whose failure the control that
-started it already draws, a routing whose result every caller drops.
-They pass through [`runUnwatched()`](../src/action/run_unwatched.js), which takes
-the rejection without hiding the error — it stays in `errorSignal`. That is
-every place navi swallows one but the prefetch on intent, dropped without a
-word since nothing on screen asked for it and the arrival runs the action again
-([dynamic_import.md](./dynamic_import.md#ahead-of-the-render-intent)). Taking
-it is what obliges that place to ask the next question: did anything display
-this error? (below).
+not anything was waiting on the promise — `useAsyncData`, `errorSignal` and an
+`onError` passed to the run are how a render asks for it. Code that lets such a
+rejection float gets the runtime's own report — an `unhandledrejection`, the
+jsenv overlay in dev — and that is the right answer for it: nothing had to guess
+whether someone was waiting.
+
+**Some runs have nobody to reject at**: one started from a signal effect because
+its params changed, one started by the render that reads it (`{ run: true }`),
+one whose failure the control that started it already draws, a routing whose
+result every caller drops. navi takes their rejection itself without hiding the
+error — it stays in `errorSignal` — and taking it is what obliges navi to ask
+the next question: did anything display this error? (below). The prefetch on
+intent is dropped without a word, since nothing on screen asked for it and the
+arrival runs the action again
+([dynamic_import.md](./dynamic_import.md#ahead-of-the-render-intent)).
 
 Two things must never become a rejection, and do not. **A navigation**: the
 routing's promise is what the browser calls the navigation itself, and rejecting
@@ -202,18 +165,15 @@ of an update**: several actions run for one update, so their outcomes are
 gathered with `allSettled` — one failure is an outcome to record, not something
 that takes the other five down.
 
-Why the failure does no more than that: **at the instant an action fails, nothing can
-know whether a screen will display it.** A route action runs before its page
-renders — often before that page exists — so any decision made there about "will
-someone show this?" is a guess, and it is wrong for the most common case in the
-app. So no decision is made there.
+The failure does no more than that because, at the instant an action fails,
+nothing can know whether a screen will display it: a route action runs before
+its page renders, often before that page exists.
 
 ## Claiming an error: `__handled_by__`
 
 Whatever displays the error sets `error.__handled_by__` (via
-`markErrorAsDisplayedBy` in
-[action_error_report.js](../src/action/action_error_report.js)). That mark means
-one thing and only one: **this error is on screen somewhere.**
+`markErrorAsDisplayedBy`). That mark means one thing and only one: **this error
+is on screen somewhere.**
 
 It is the same mark the jsenv supervisor reads to keep its dev overlay out of
 the way: a window `error` or `unhandledrejection` carrying it is not shown. An
@@ -237,32 +197,18 @@ unhandled error — window `error` event, jsenv overlay in dev — pointing at t
 code that produced it.
 
 **Being read is enough to call the report off**, displayed or not. Once a render
-has the error, everything that can happen next is already covered without this
-module: it is displayed (and marked), or it is thrown — and a thrown error either
-finds a boundary that displays it, or reaches window on its own, since preact
-re-throws what no boundary handled. Reporting it here too would be a second
-voice, and the wrong one: this module cannot see which of those happened.
-
-**And a render stopped in the middle read nothing after it.** `useAsyncData`
-delegates a failure by throwing it out of the render — that is how the error
-reaches the boundary. The render ends on that line, so a second `useAsyncData`
-below it, even one asking for `error: true`, is never called and never claims
-its own error. "Nobody read it" would then be true and meaningless: the order of
-two hook calls would decide whether the app is told it has a bug. So the throw
-speaks for the failures waiting for the same answer alongside it — a url change
-fails its route actions together — and none of them is reported. What is on
-screen is the failure the render was stopped at, which is the same story. A
-failure arriving _later_, after the page was replaced by what displays the first
-one, is not covered: nothing tells it apart from an action nobody reads.
-
-One error is never reported whoever looks at it: a **`NetworkPolicyError`**.
-The app declared the state that produced it and the request never left, so there
-is no bug to point at — it is data a screen shows. When one reaches window
-anyway, navi cancels the event, which keeps the browser console and the jsenv
-overlay out of it. A boundary displaying one still leaves a `console.error` line
-in dev: `preact/debug` logs every error a boundary catches, and reads nothing
-that would tell it the error is handled
-([network_policy.md](./network_policy.md)).
+has the error, everything that can happen next is already covered: it is
+displayed (and marked), or it is thrown — and a thrown error either finds a
+boundary that displays it, or reaches window on its own, since preact re-throws
+what no boundary handled. A render stopped by a delegated throw also speaks for
+the failures waiting on the same answer alongside it — a url change fails its
+route actions together — so none of them is reported; a failure arriving later,
+after the page was replaced by what displays the first one, still is.
+
+A **`NetworkPolicyError`** is never reported, whoever looks at it: the app
+declared the state that produced it and the request never left, so there is no
+bug to point at (see [network_policy.md](./network_policy.md), with the one
+`console.error` line `preact/debug` still writes in dev).
 
 So what reaches the report is an error **nothing looked at** — an action nobody
 reads, a prerun for a page never opened. And _when_ it is reported follows from
@@ -272,9 +218,8 @@ that:
 - but a route action fails ON the url change, before its page exists — it is the
   routing itself that brings what will display the error. So the deadline waits
   for the document to stop moving and for the frame that paints what the routing
-  brought. Anything faster tells an app that is displaying "you are offline" that
-  it displayed nothing (measured: the screen arrived ~12ms after a plain
-  macrotask deadline).
+  brought: anything faster tells an app displaying "you are offline" that it
+  displayed nothing.
 
 Waiting longer costs nothing, precisely because a read is enough to call it off:
 what is still unread by then was going to stay unread. The same error reaching
@@ -289,9 +234,9 @@ easy to miss when writing another one:
   whether anything is displayed, turns a boundary into a bug swallower: a
   `TypeError` it then re-throws reaches window marked as on screen, so the
   overlay that would have pointed at it stays out of the way — a blank page AND
-  a silent one. navi's boundary marks
-  just before rendering its fallback, and re-throws untouched when it has no
-  fallback — nothing to display means nothing handled.
+  a silent one. navi's boundary marks just before rendering its fallback, and
+  re-throws untouched when it has no fallback — nothing to display means nothing
+  handled.
 - **Reset on the document URL, not only on the rerun.** Re-running the failed
   action is one way out; going somewhere else is the common one. A boundary that
   only watches the action stays in place of every page after the failure,
@@ -300,12 +245,15 @@ easy to miss when writing another one:
 The one reason to write your own: **filtering what you take.** navi's takes
 everything its subtree throws. An app that wants its own bugs to stay visible
 displays only what is data to it — an error carrying an HTTP status, a
-`NetworkPolicyError` — and re-throws the rest **unmarked**, so the overlay still does
-its job. `markErrorAsDisplayedBy` and `errorIsDisplayed` are exported for that:
+`NetworkPolicyError` — and re-throws the rest **unmarked**, so the overlay still
+does its job. `markErrorAsDisplayedBy` and `errorIsDisplayed` are exported for
+that:
 
 ```jsx
 const PageErrorBoundary = ({ children, fallback }) => {
   const [error, resetError] = useErrorBoundary();
+  // + the second rule: resetError() once the document URL (useDocumentUrl())
+  //   is no longer the one the error was caught on
   if (!error) {
     return children;
   }

package/docs/field_validation.md

@@ -10,8 +10,7 @@ them apart is the whole subject.
 **What only a browser can answer.** A keystroke blocked before the value exists,
 a callout placed next to the field, `required` on a radio group, `data-one-of`
 reading an option list out of the document, the moment a message appears
-(typing? blur? submit?).
-This is navi's, and it stays navi's.
+(typing? blur? submit?). This is navi's, and it stays navi's.
 
 **« Is this value acceptable ».** A length, a set of allowed characters, a
 value that renders nothing, a business rule. This is not a DOM question — a
@@ -26,20 +25,17 @@ a validity rule, and the constraint is only its browser-side caller.
 ## Constraints
 
 A constraint is `{ name, check(field) }` — a bare `check` function is accepted
-too. `check` returns `null` when the value
-passes, or the message to show — a string, or `{ message, target }` when the
-callout belongs on another element than the control itself.
+too. `check` returns `null` when the value passes, or the message to show — a
+string, or `{ message, target }` when the callout belongs on another element
+than the control itself.
 
 Navi's own constraints are switched on by an attribute on the control —
-standard when the platform has one, `data-*` when it does not.
-
-**They are written as props, in camelCase.** A constraint declares the attribute
-it reads (`data-no-emoji`) and a control accepts the prop that stands for it
-(`noEmoji`), putting it on the control host under the attribute name — the same
-conversion `element.dataset` does. So `singleSpace` is what you write and
-`data-single-space` is what ends up in the DOM (and in the devtools, and in a
-test selector). The attribute form is accepted too, for a control written in
-plain HTML.
+standard when the platform has one, `data-*` when it does not. **They are
+written as props, in camelCase**, which land on the control host as the
+attribute the constraint reads — the conversion `element.dataset` does:
+`singleSpace` is what you write, `data-single-space` is what ends up in the DOM
+(the devtools, a test selector). The attribute form is accepted too, for a
+control written in plain HTML.
 
 | prop                            | attribute                                   | refuses                                                                         |
 | ------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------- |
@@ -52,9 +48,9 @@ plain HTML.
 | `noEmoji`                       | `data-no-emoji`                             | an emoji, where a name, an identifier or a title does not want one              |
 | `maxLineBreaks`                 | `data-max-line-breaks`                      | a value holding more line breaks than that                                      |
 | `oneOf`                         | `data-one-of`                               | a value outside the option list its CSS selector points at                      |
-| `sameAs`                        | `data-same-as`                              | a value differing from the field it names                                       |
+| `sameAs`                        | `data-same-as`                              | a value differing from the field its CSS selector points at                     |
 | `minDigit`, `minUpperLetter`, … | `data-min-digit`, …                         | a password missing a kind of character                                          |
-| `timeAfter`, `timeMinDuration`  | `data-time-after`, `data-time-min-duration` | a time span that ends before it starts, or is too short                         |
+| `minDuration`                   | `data-time-after`, `data-time-min-duration` | a `TimeRangeSpin`/`TimeRangeWheel` span ending before it starts, or too short   |
 
 ```jsx
 <Input required singleSpace noEmoji maxLength={80} />
@@ -75,39 +71,33 @@ the leading and trailing spaces are removed and a run of spaces becomes one:
 <Input name="title" singleSpace="autoFix" />
 ```
 
-- **At commit, never while typing.** The correction runs when the field is
-  left, and before an action reads the value. Correcting on each keystroke would
-  eat the space the person is about to follow with a word, so an action run
-  from typing (a search, debounced or not) reads the value as typed.
-- **Nothing to say.** The correction is validity's own `SINGLE_SPACE_RULE`, so
-  the value always passes the rule: no callout, and a server re-checking with
-  `singleSpace: true` accepts what it receives.
-- **It lands everywhere the value lives**: the field, its ui state, the bound
-  `signal`. A `disabled` or `readOnly` field is left alone, since its value is
-  the app's and not the person's.
-- **`singleSpace` is the only constraint that offers it.** A correction is worth
-  it only where it cannot change what the person meant; a `maxLength` silently
-  cutting a text would.
+- **At commit, never while typing**: when the field is left, and before an
+  action reads the value. Correcting on each keystroke would eat the space the
+  person is about to follow with a word, so an action run from typing (a
+  search, debounced or not) reads the value as typed.
+- **Nothing to say**: the correction is validity's own rule, so no callout, and
+  a server re-checking with `singleSpace: true` accepts what it receives.
+- **It lands everywhere the value lives** — the field, its ui state, the bound
+  `signal` — except in a `disabled` or `readOnly` field, whose value is the
+  app's and not the person's.
+- **`singleSpace` is the only constraint that offers it**: a correction is worth
+  it only where it cannot change what the person meant, which a `maxLength`
+  silently cutting a text would.
 
 Most constraints take a `<name>Message` prop to replace their sentence for one
 field (`requiredMessage`, `singleSpaceMessage`, `oneOfMessage`…; `step` and the
 time span constraints have none). To change it everywhere, override the i18n
-key instead — see below.
+key instead — see [Messages](#messages).
 
 Two props sit beside them and belong to the browser alone, because they act
 before there is a value to validate: `charGuard` blocks a keystroke that is not
-in its character class, `maxLengthGuard` blocks the one that would overflow (and
-truncates a paste). Both show what they refused in a callout rather than
-silently swallowing it.
-
-`charGuard` takes a character class or one of validity's preset names, so a
-field can refuse the keystroke with the same knowledge the value is checked
-against: `charGuard="tel"`, `charGuard="slug"`, `charGuard="noEmoji"`. Refusing
-the keystroke and refusing the value are different jobs — the pair
-`maxLengthGuard`/`maxLength` is the same split — and a guard brings the value
-check along: `maxLengthGuard` is checked at submit as `maxLength`, `charGuard`
-sets an `Input`'s `pattern` from its class unless one is given. `maxLength`
-alone is the submit-only half.
+in its character class (or one of validity's preset names: `charGuard="tel"`,
+`"slug"`, `"noEmoji"`), `maxLengthGuard` blocks the one that would overflow and
+truncates a paste. Both show what they refused in a callout rather than
+silently swallowing it. Refusing the keystroke and refusing the value are
+different jobs, and a guard brings the value check along: `maxLengthGuard` is
+checked at submit as `maxLength`, `charGuard` sets an `Input`'s `pattern` from
+its class unless one is given. `maxLength` alone is the submit-only half.
 
 **A guard answers for the gesture, never for what the field already holds.** A
 value can arrive already outside the class or already too long — a
@@ -119,21 +109,12 @@ is already there is the constraint's business, and it says so at submit.
 
 ## Reading the validity without submitting
 
-`useConstraintValidityState(ref)` gives the control's validity as it stands,
-re-read whenever it changes:
-
-```js
-const state = useConstraintValidityState(inputRef);
-state.valid; // false
-state.single_space.messageString; // the sentence
-state.reported; // "max_length" — the one the callout says
-```
-
-Several constraints fail at once and only one sentence is shown: the one with
-the highest priority — an `error` status first, then `required`, then the
-platform's own constraints, then navi's and the app's, ties going to the first
-registered. `reported` names it, so a summary drawn beside the field says the
-same thing as the callout rather than picking a second one.
+`useConstraintValidityState(ref)` gives the control's validity as it stands
+(see its JSDoc). When several constraints fail at once, only one sentence is
+shown: the one with the highest priority — an `error` status first, then
+`required`, then the platform's own constraints, then navi's and the app's, ties
+going to the first registered. `reported` names it, so a summary drawn beside
+the field says the same thing as the callout rather than picking a second one.
 
 `src/control/demos/validation/text_rules_demo.html` is that, one rule per row: a
 value that breaks it, its message read live, and a submit to see the callout.
@@ -142,46 +123,25 @@ value that breaks it, its message read live, and a submit to see the callout.
 
 Every sentence navi says is a key in `naviI18n`, and the validation ones are
 `constraint.*`. An app changes one for its whole app by registering over it:
-
-```js
-import { naviI18n } from "@jsenv/navi";
-
-naviI18n.add("constraint.single_space.consecutive", {
-  fr: "Pas deux espaces d'affilée.",
-});
-```
+`naviI18n.add("constraint.single_space.consecutive", { fr: "…" })`.
 
 The keys of everything validity owns are validity's own key prefixed with
 `constraint.` — `single_space.start` is `constraint.single_space.start`,
 `char_class.slug` is `constraint.char_class.slug`. That is deliberate: the
 sentence a server returns and the sentence the field shows are looked up under
 one name, so making them agree is registering one key, not maintaining a
-translation table. See `src/control/rules/validity_bridge.js`, and `i18n.md` for
-how the registry itself works.
+translation table. See [i18n.md](./i18n.md) for how the registry itself works.
 
 ## An app's own rules
 
 An app puts its rules in the package its server reads too, and then decides, per
-rule, who runs it.
+rule, who runs it — see validity's
+[Rules of your own](../../../tooling/validity/README.md#rules-of-your-own) and
+[Front and back](../../../tooling/validity/README.md#front-and-back-sharing-what-is-worth-sharing).
+The navi side:
 
-**Both sides.** The rule is a validity rule; navi wears it as a constraint.
-
-```js
-// shared/src/text_rules.js — read by the server and by the front
-export const MAX_WORDS_RULE = {
-  name: "maxWords",
-  applyOn: (maxWords, value) => {
-    if (maxWords === undefined || typeof value !== "string") {
-      return null;
-    }
-    const count = value.trim().split(/\s+/).length;
-    if (count <= maxWords) {
-      return null;
-    }
-    return { key: "max_words", params: { max: maxWords, count } };
-  },
-};
-```
+**Both sides.** The rule is a validity rule; navi wears it as a constraint,
+built once:
 
 ```js
 // front — once, at module level: a constraint rebuilt on every render is a new
@@ -195,9 +155,9 @@ const MAX_WORDS_CONSTRAINT = constraintFromValidityRule(MAX_WORDS_RULE, {
 <Textarea constraints={[MAX_WORDS_CONSTRAINT]} />;
 ```
 
-The rule's key is looked up in `naviI18n` under `constraint.max_words`, so
-register it there — or pass `formatMessage` beside the parameters to say it
-through the app's own i18n instead.
+The rule's key is looked up in `naviI18n` under `constraint.<key>`
+(`constraint.max_words`), so register it there — or pass `formatMessage` beside
+the parameters to say it through the app's own i18n instead.
 
 **The server alone.** A rule needing the database, another user's data or a
 secret stays in `createValidity({ rules })` and never reaches the front; its