@jsenv/navi 0.29.489 → 0.29.490

package/docs/form_changed.md

@@ -27,9 +27,12 @@ what follows the send still follows it — the popup closes, the slide moves on,
 the page changes. The user is done either way; there was simply nothing to
 send.
 
-`canSendWhileUnchanged` turns that off, for a form where sending the same thing
-twice is the point — a single button firing a notification, an action whose
-duplicates are fine.
+`canSendWhileUnchanged` turns that off, for a form whose send is the act itself
+rather than its fields: a request that exists even empty (join, ask, raise a
+hand), a step that moves on, a creation whose screen opens already filled —
+from the url, from last time's answers, from the defaults a `stateSignal`
+declares — and a send whose duplicates are the point (a single button firing a
+notification).
 
 ```jsx
 <Form action={notify} canSendWhileUnchanged>
@@ -89,11 +92,13 @@ are what keep an empty one from being sent.
 
 A creation lands on the page the server just made, and its id comes back with
 the response — too late for a prop. Do it in the action, which is where the
-answer is (a creation always has something to send, so there is no "the press
-did nothing" case for `command` to cover):
+answer is. A creation that may open already filled — a draft restored from the
+url — takes `canSendWhileUnchanged`, or its press does nothing at all: no send,
+and the navigation that lives in the action never runs:
 
 ```jsx
 <Form
+  canSendWhileUnchanged
   action={async (value) => {
     const game = await createGame(value);
     navTo(`/games/${game.id}`);
@@ -201,6 +206,16 @@ does not register with the group around it. Nothing goes up (its value is not
 collected, the form stays unchanged whatever it does) and nothing comes down
 (the form's reset, its validation cascade).
 
+Enter is the exception. In a text field, standalone or not, Enter sends the
+group around it (`--navi-send`), the way Enter submits an HTML form; in a
+picker's popup it sends the picker — its own value, not the field's — and
+closes it. A field with an `action` of its own commits that action instead. A
+field that helps find the answer says which list it drives with `navi-list`:
+Enter then picks the row under the arrows, and does nothing while none is. A
+field whose Enter must send nothing at all — a street typed before its
+suggestion filled the city — says `enterSendsNothing`; the browser's own Enter
+(a datalist choice) still happens.
+
 What it does **not** say is "ignore everything around me". `disabled`,
 `readOnly` and `loading` travel on their own contexts and go on reaching it,
 deliberately: a door with no value of its own can still write into the form

package/docs/group.md

@@ -43,7 +43,11 @@ Live examples: `src/control/demos/15_group_demo.html`.
 - **Seams**: a member with a member before it is pulled back by one border
   width, so the two borders along a seam become one line — the member's own
   `--border-width` when it declares one, else the group's `--group-border-width`
-  (default: `--navi-control-border-width`).
+  (default: `--navi-control-border-width`). Members that draw no border have
+  no line to share: `seamColor` (and `seamWidth`, 1px by default) sets them
+  that far apart and paints the gap — `<SplitButton seamColor="…">` for two
+  borderless halves. In css, `--group-seam-color` and `--group-seam-width`,
+  set on the group or around it.
 - **Corners**: a member loses the radius on each side where it faces another
   member. A single member keeps its own radius — a group of one looks like the
   control alone.

package/docs/i18n.md

@@ -192,25 +192,40 @@ which pins one region beside navi's dates and ignores `setSupportedLanguages`.
 Each helper takes `lang` and otherwise reads the signal above; the component is
 for JSX, the function for a string (a `title`, a notification).
 
-| Value                   | Component                                          | String                                           |
-| ----------------------- | -------------------------------------------------- | ------------------------------------------------ |
-| a number                | `<Quantity>`                                       | `formatNumber`                                   |
-| a day                   | `<Time type="date">`                               | `formatDay`                                      |
-| a month                 | `<Time type="month">`                              | `formatMonth`                                    |
-| a day and its time      | `<Time type="datetime">`                           | `formatDatetime`                                 |
-| a time of day           | `<Time type="time">`                               | `formatTimeOfDay`, or `formatTime` from a `Date` |
-| a clock from a count    | `<Time type="hour"\|"minute" format="timestring">` |                                                  |
-| two times of day        | `<TimeRange>`                                      | `formatTimeRange`                                |
-| a day relative to today | `dayLabel` on `<Time type="date">`, beside the day | `formatDayRelative`                              |
-| an instant, from now    | `<Time type="relative">`                           | `formatTimeRelative`                             |
-| a duration              | `<Time type="duration">`                           | `formatDuration` and its per-unit siblings       |
-| items read as one list  |                                                    | `formatList`                                     |
+| Value                           | Component                                          | String                                           |
+| ------------------------------- | -------------------------------------------------- | ------------------------------------------------ |
+| a number                        | `<Quantity>`                                       | `formatNumber`                                   |
+| a size in bytes                 |                                                    | `formatByteSize`                                 |
+| a day                           | `<Time type="date">`                               | `formatDay`                                      |
+| a month                         | `<Time type="month">`                              | `formatMonth`                                    |
+| a day and its time              | `<Time type="datetime">`                           | `formatDatetime`                                 |
+| a time of day                   | `<Time type="time">`                               | `formatTimeOfDay`, or `formatTime` from a `Date` |
+| a clock from a count            | `<Time type="hour"\|"minute" format="timestring">` |                                                  |
+| two times of day                | `<TimeRange>`                                      | `formatTimeRange`                                |
+| a day relative to today         | `dayLabel` on `<Time type="date">`, beside the day | `formatDayRelative`                              |
+| an instant, from now            | `<Time type="relative">`                           | `formatTimeRelative`                             |
+| a duration                      | `<Time type="duration">`                           | `formatDuration` and its per-unit siblings       |
+| the time elapsed since, ticking | `<Time type="duration" since={instant}>`           |                                                  |
+| items read as one list          | `formatList` over elements                         | `formatList`                                     |
 
 A spelled day writes its year only when it is not in `now`'s year (`year:
 "auto"`, see `formatDay`): appending the year by hand writes it twice for a
 date in another year. A capital letter at the start of a value is
 `<Text capitalize>`, not a sliced string.
 
+The shape of a number is asked of `formatNumber` too: it takes
+`Intl.NumberFormat`'s options in the reader's language — a fixed precision
+(`formatNumber(seconds, { minimumFractionDigits: 1, maximumFractionDigits: 1 })`
+→ "1,0"), a sign (`signDisplay: "exceptZero"` → "+3") — and `<Quantity>`
+forwards the fraction digits and the sign. A time written to the second (a log
+line, a "checked at") is `precision: "second"` on `formatTime`,
+`formatDatetime`, `formatTimeOfDay` and `<Time type="time"|"datetime">`.
+
+A list whose items are elements — a `<TimeRange>` per span — goes through
+`formatList` as well: given an element, it returns a fragment with each element
+at its place between the language's words, where a hand-written " et " would
+join them in one language only.
+
 ## Changing what navi says
 
 `naviI18n` holds navi's own texts. Register on it to override a default or to

package/docs/interactions.md

@@ -93,6 +93,27 @@ turned down where it is read (see
 [`refuse`](./drag_interactions.md#the-hand-pulls-and-nothing-follows-refuse),
 which the carrying interactions answer with).
 
+A value can also say what it is besides what it does, as
+`{ answer, verb, optimistic }`, `answer` being one of the four:
+
+```jsx
+<List.Item
+  interactions={{
+    reorder: { answer: saveOrder, verb: "PUT" },
+    toss: { answer: remove, verb: "DELETE" },
+    swipe_left: { answer: archive, verb: "PATCH" },
+  }}
+/>
+```
+
+`verb` says the answer writes, which a function cannot say about itself. Under a
+[network policy](./network_policy.md) holding writes the interaction does not
+happen, and the policy's words are said where the hand made it — before anything
+moves, for a gesture: a carried thing is not picked up, a swiped row resists like
+a wall. `optimistic` is for a `reorder` or a `land` drawn at once and written
+after ([drag_interactions.md](./drag_interactions.md#answered-at-once-optimistic)).
+A falsy `answer` is "not this one" too.
+
 ### The interactions navi detects
 
 | Key                                                | Read from                                                   |
@@ -199,9 +220,15 @@ finger was — is `findEvent(event, ["pointerdown", "pointerup", "click",
 Everything goes through the interaction gate of the **nearest control** — itself,
 an ancestor, or the one control it wraps, in that order. So a disabled, read-only
 or busy control answers a swipe the way it answers a click: it says why, where the
-interaction happened, and nothing runs. A `Box` with no control anywhere near it
-still answers a callback; only the two requests (`"request_action"`,
-`"request_ui_action"`) have nothing to ask, and say so in dev.
+interaction happened, and nothing runs. A gesture asks the gate where the hand
+meets it, not once it has played: a carried thing is not picked up — the gate
+speaks at the instant the grab would have been felt — and a swiped row resists
+the way a side nothing is declared for does, the gate speaking the first time the
+hand pulls that way. A row that goes all the way out before being told it was
+never free to go is a press that looks accepted and fails after. A `Box` with no
+control anywhere near it still answers a callback; only the two requests
+(`"request_action"`, `"request_ui_action"`) have nothing to ask, and say so in
+dev.
 
 A `Box` that lays out **several** controls — a row of badges, a toolbar — belongs
 to none of them: its interactions are its own, answered with no gate. A click on
@@ -276,8 +303,11 @@ element that declares the gesture.
 
 While the answer takes time, the element **stays where the gesture left it**, and
 comes back once it settles — a failure leaves the row in place to be tried
-again. What a success does to it is yours (a list that redemands its rows, a row
-that leaves): navi does not make it disappear.
+again, and says why on it once it is back, read the way a refused drag's answer
+is ([drag_interactions.md](./drag_interactions.md#carrying-something-move-reorder-land-toss-leave)):
+rejecting with nothing comes back without a word. What a success does to it is
+yours (a list that redemands its rows, a row that leaves): navi does not make it
+disappear.
 
 ## Twice, whichever hand it is
 
@@ -540,7 +570,9 @@ teardown, so a travelling container above it does not take the gesture (see
 ## Reference
 
 - `src/control/interaction/interaction_registry.js` — the prop, the four values,
-  the registry.
+  `{ answer, verb, optimistic }`, the registry.
+- `src/control/interaction/interaction_refusal.js` — how a refusal is said,
+  before and after.
 - `src/control/interaction/interaction_press.js` — swipes, holds and the two
   taps, and what a swipe writes on the element.
 - `src/control/interaction/interaction_keyboard.js`,

package/docs/list_refresh.md

@@ -125,7 +125,10 @@ same (next section).
 A composition is about the **values** its params hold, not the reader instance:
 `GET_RANGE.bindParams({ scope: "thread" })` called from two places reads and
 writes the same one. A verb in `rerunOn.GET_RANGE`, or `reader.invalidate()`,
-drops the compositions — they stand for an order that is gone — and
+drops the compositions — they stand for an order that is gone;
+`reader.revalidate()` keeps them and has the lists on screen ask again for
+their window, for a collection that may have moved (the app back from the
+background) — and
 `memoryBudget` (1000 ranks by default) trims the ranks far from any window,
 which are asked for again if the user goes back to them.
 

package/docs/navigation.md

@@ -318,6 +318,12 @@ param that qualifies a screen is not a place, and one entry per write turns a
 single back-press into as many as the user moved. A state whose values ARE places
 says so — see [`history: "push"`](#a-state-whose-values-are-places-history-push).
 
+One answer may be kept as several params — a level and its reach,
+`?levels=…&level_exact=…` — and drawn by one control whose value is the object.
+`stateSignalGroup({ levels: levelsSignal, level_exact: levelExactSignal })` is
+that object: read from the params, following each of them, and written back
+into them as one move — one history entry.
+
 #### A value written per frame
 
 Every write reaches the address, synchronously, and browsers refuse an address
@@ -380,6 +386,13 @@ be written about it (see
 [route_transitions.md](./route_transitions.md#a-page-opened-from-anywhere)), and
 its `matchingSignal` read outside the tree.
 
+Which page is on screen is the containers' answer, not the routes': several can
+match one address, and only the order of the branches says which renders.
+`renderedPageSignal` holds it — `{ route, params }` of the deepest page the
+routers render, a section's own sub-router included, the fallback's
+`routeFallback()` when nothing matches. Naming the screen being left, counting
+where people go: read it there rather than walking a copy of the route table.
+
 A section with a shared prefix owns its own sub-router: one leaf on
 `/dashboard/` whose element renders its own `<Route>` tree and chrome, handing its
 local state down through `elementProps`. Pages sharing a layout but no prefix
@@ -578,6 +591,16 @@ A, B, A, B… growth, and the scroll comes back — and one step forward too. On
 towards entries of this document, and never when the push carries explicit
 state. An arrow that must ALWAYS behave as a back is `navBack()`.
 
+Further back, a push is an arrival even when it means a return: a bar entry
+leading back to a thread whose address names the item one was reading
+(`/games?at=<id>`) is, by its path, a new arrival at the top — the same push from
+a notification would be one. Only the link knows, and it says so:
+`<Link asReturn>`, `navTo(url, { asReturn: true })`. The push still stacks its
+entry, and lands like a back: the document where that address was last left,
+its lists on the positions they kept there
+([scroll.md](./scroll.md#where-the-list-opens-and-where-it-is)). An address never
+left opens at its top as usual.
+
 ### A page that is not whole yet
 
 A position is put back into whatever the page shows at that moment. When that is

package/docs/network_policy.md

@@ -111,15 +111,26 @@ all, so it is left alone, and so is a function handed to a control's `action`:
 it is wrapped into an action with no verb, even when it calls one, so the
 control is not held and the write fails after the press with a
 `NetworkPolicyError` ([resource.md](./resource.md#a-function-calling-the-verb-or-the-instance)).
-Such a control says what its function does to the server with `actionVerb` —
-`<Input type="checkbox" boolean action={(on) => saveSetting("weather", on)}
-actionVerb="PATCH" />` — and is then held up front, with the policy's message.
+Such a control, or a `<Form>`, says what its function does to the server with
+`actionVerb` — `<Input type="checkbox" boolean action={(on) => saveSetting("weather", on)}
+actionVerb="PATCH" />`, `<Form action={sendDraft} actionVerb="POST">` — and is
+then held up front, with the policy's message: a form's fields and its submit
+alike.
 `createAction(callback, { meta: { verb } })` says the same of an action declared
 once, and opts it into what the action layer holds — a control bound to a write verb is read-only, a completed `"GET"`
 is not rerun — but its callback is still called when it runs: answering from
 the store and settling with a `NetworkPolicyError` are done by the callbacks a
 `resource()` wraps.
 
+A gesture's answer is a function navi cannot see into either, and says what it
+writes in its declaration —
+`interactions={{ reorder: { answer: saveOrder, verb: "PUT" }, toss: { answer: remove, verb: "DELETE" } }}`
+([interactions.md](./interactions.md#the-four-values)). Under the policy it does
+not happen, and the policy's message is said where the hand made it, before
+anything moves: a carried thing is not picked up, a swiped row resists as a wall
+does. Undeclared, the gesture plays to the end and the write it calls fails
+after — said on the element, the way any refused answer is.
+
 ## Holding writes while reads go out
 
 `reads: "network"` keeps the first half of the policy and drops the second: the

package/docs/popup_lift.md

@@ -7,7 +7,8 @@ edit sheet; a drawing in a corner becomes the drawing full width. The page
 recedes behind a wall, the box leaves its place, travels and grows, and comes
 back into its place on close — or, with
 `animation={{ open: "scaling", close: "lifting" }}`, only lands somewhere on
-close (see [lifting on the way back only](#lifting-on-the-way-back-only)).
+close, which a `Popover` does too (see
+[lifting on the way back only](#lifting-on-the-way-back-only)).
 
 It is not a way to open a dialog with a nicer entrance. A dialog that shows
 something else than what was pressed — a menu, a confirmation, a form the
@@ -255,6 +256,16 @@ does the opening's own exit play: while a closing lift runs, the dialog's
 transitions are off, or `scaling`'s exit would keep the dialog painted into the
 picture of the state it closes into.
 
+**A popover lands the same way.** A `Popover` — a `Popup` or a `Picker` in
+popover mode — takes the same `animation={{ open, close: "lifting" }}` and
+`liftAnchor`: an invitation shown out of the top bar, whose "Later" puts the
+app's tile away in the settings wheel, flies the tile into the wheel as it
+closes. Left without `liftAnchor`, the lifted node goes back into the anchor the
+popover was placed against. The popover itself leaves with the page's picture,
+fading as the node travels; its own exit is off for the same reason as the
+dialog's. Only the close lifts: a popover opens placed against its anchor,
+never out of it, so a plain `"lifting"` gives it no movement either way.
+
 **The box it lands in is rendered by the close.** `liftAnchor` is read once the
 close has been made, `onClose` included, inside the transition: a state written
 in `onClose` has rendered by the time the landing is looked up. It is also the
@@ -275,8 +286,9 @@ and dev warns.
 
 **Tell the collecting close from the others.** Escape, the back button and a
 press on the wall close the dialog too, and usually mean "not now" rather than
-"collect". A `Dialog`'s `onClose` receives who asked (`e.detail.requester`, the
-button of a `--navi-close`), and only the close that collects writes the state.
+"collect". A `Dialog`'s or a `Popover`'s `onClose` receives who asked
+(`e.detail.requester`, the button of a `--navi-close`), and only the close that
+collects writes the state.
 The others land nowhere: the fixed `liftAnchor` names nothing, so they wait out
 those 300 ms, fade out, and dev warns.
 

package/docs/popup_open.md

@@ -206,7 +206,12 @@ names none, and on whoever asked when nothing else says. In that order:
    the press is the only thing that knows that point.
 2. **the `anchor` prop** — where this popup opens when nobody says.
 3. **`detail.source`** — who asked. A button therefore opens the popup on
-   itself, and a popup passed as its own source is its own anchor.
+   itself, and a popup passed as its own source is its own anchor. A source
+   bigger than what the popup comes out of — a whole row pressed, a crest
+   inside it — names that part: `navi-command-proxy-for="<id>"` on the button
+   makes the element with that id the source the popup reads, what a Popover
+   is placed against and what a lifting Dialog lifts from and lands back into.
+   The press, the value and the focus stay the button's.
 
 A `Popover` is positioned against it; a `Dialog` only reads it for
 `sizeFromAnchor` and `animation="lifting"` (see [popup_lift.md](./popup_lift.md)).
@@ -471,6 +476,40 @@ 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.
 
+### Awaiting the answer: `askPopup`
+
+A gesture whose outcome is a question waits for it where the gesture is: a card
+thrown off the list asks "delete it?" and either goes or flies home, a player
+dropped on the release zone asks "remove them from the game?". The question is a
+popup, and the answer is how it closed. `askPopup` opens it as `--navi-open`
+does and settles once it has closed:
+
+```js
+import { askPopup } from "@jsenv/navi";
+
+toss: async (event) => {
+  const { confirmed } = await askPopup(deleteDialogRef.current, event, {
+    value: alert.id,
+  });
+  if (!confirmed) {
+    throw undefined; // the card goes home, nothing said
+  }
+},
+```
+
+`confirmed` is a yes: a `--navi-confirm`, or a send the popup closed on — a
+`<Form>` inside it, a row's `--navi-send`. Everything else is a no, every way
+out included: Escape, the backdrop, the cross, a link leaving, Back, the popup
+leaving the page. It settles after `onClose`, and after the yes's own action:
+a button's command waits for its action, so a confirm that deletes has deleted.
+Asked again while the popup is still open, the earlier question is answered no
+and the new one waits for the close. Nothing opening — no popup found, a press
+that closed it a moment ago — rejects with `undefined`, which a gesture's answer
+reads as a refusal to say nothing about.
+
+The popup stays the popup: uncontrolled, with its own say over closing, and
+nothing in it knows it was asked rather than opened.
+
 ### Closing when a button also runs an action
 
 A button that carries both runs them in that order: the action first, the
@@ -800,6 +839,54 @@ it — the shape of a popup that is a LAYER over the screen, whose address is
 [navigation.md](./navigation.md#a-layer-over-the-screen-what-its-address-may-say)'s
 decision.
 
+To land on a page with such a popup open — "see the details" leading to a
+profile with its results sheet over it — the link says which, the way the
+popup's `navState` says it:
+
+```jsx
+<Link
+  route={PROFILE}
+  routeParams={{ id }}
+  open={{ id: "results", type: "push" }}
+>
+  Voir le détail du calcul
+</Link>
+// or navTo(PROFILE.buildUrl({ id }), { open: { id: "results", type: "push" } })
+```
+
+The page's entry is pushed, then the popup's own, as its opening would write
+it: closing the sheet leaves the reader on the profile, and Back then leaves
+the profile. The popup need not be mounted yet — it reads its key when the
+page mounts it. A popup whose open state is a url param needs none of this:
+its `buildUrl` already says it.
+
+### State that belongs to the popup: `ownSignals`
+
+What a popup was opened on beside its `value` — the seat of a game a share
+sheet is about — and what is chosen inside it — the result slide shown in a
+level sheet — often lives in the address too, so a reload or a return finds
+it. It means nothing once the popup is closed, and navi writes it away with
+the open state:
+
+```jsx
+<Dialog
+  signal={gameShareSignal}
+  value={game.id}
+  ownSignals={[gameShareSlotSignal]}
+>
+```
+
+Every close empties them (writes `undefined`, a state signal's default, out of
+the url), whatever closes the popup — its cross, a keep-close landing back,
+Escape, Back — and at the moment that close says: a keep-close lands on an
+address without them, a cancel going back empties what the entry behind still
+held, written by an `onOpen` before the push. A `navState` popup closed by a
+link leaving keeps them on the entry left, where Back finds the popup open on
+what it was showing. A signal two popups share (a sheet and the
+plate opening it both reading `?rank_result=`) is emptied by whichever
+closes. `Dialog`, `Popover`, `SidePanel`, `Popup` and `Expandable` take it; a
+`Picker` writes its own in `onClose`, which runs before its close lands.
+
 ### `open`, and what it costs
 
 `open` is the one-way half of `signal` — the parent re-renders with a boolean
@@ -980,6 +1067,17 @@ the gesture that opens the popup; `useAsyncData` reads it (see
 and aborts of a screen left ([network_policy.md](./network_policy.md)) apply; a
 reload keeps the open state, so it keeps the request too.
 
+**The request leaves at the press, the content is built at the hover.** A press
+on what opens the popup — a `--navi-open` or `--navi-toggle` button — preruns
+the route actions its opening changes, read as if the popup were already open:
+the request leaves at the pointerdown, not when the open state is written. The
+content may be built earlier: a `Picker`, or a popup given an `anchor`, builds
+it when the pointer rests there (see `mount`, below). On a computer the rows
+therefore arrive a press later than the content they fill. That is the price of
+a read keyed by the popup — one sheet per card, one request per card: a pointer
+crossing a list of cards has chosen none of them, and a hover that asked would
+ask for each card it crossed.
+
 The popup owning its request — `useAsyncData(action, { run: true })` — is the
 fallback, for a parameter chosen inside the popup and dying with it: a filter
 the sheet itself holds and nothing else remembers. Hand-written, with `run()`
@@ -996,15 +1094,17 @@ not leave with the close. A `Picker` told no value whose value something reads
 is the exception: it builds its popup as soon as that value is read (see
 [above](#a-press-that-opens-a-popup-and-acts-on-it)).
 
-A `Dialog` nobody has asked for yet is not even built. It stands in as its bare
-`<dialog>` — the id a command finds, the element a press announces itself on —
-and the dialog proper is built at the first request: an open, a press on what
-opens it, its `signal` or `open` saying open. From then on it stays built. So a
-list whose rows each hold a few dialogs (a sheet per seat, a share sheet per
-card) pays one element per closed dialog at every mount, not a dialog: a row
-may carry the dialogs of its own actions. It is built at once when something
-needs it from the start — open at mount, a `navState`, an `anchor` (a hover
-builds the content ahead of the click), or a `mount` other than the default.
+A `Dialog` or a `Popover` nobody has asked for yet is not even built — nor a
+`Popup` or a `SidePanel`, which render one of the two. It stands in as one bare
+element (a `<dialog>`, a `<div>`) — the id a command finds, the element a press
+announces itself on — and the popup proper is built at the first request: an
+open, a press on what opens it, its `signal` or `open` saying open. From then on
+it stays built. So a list whose rows each hold a few popups (a sheet per seat, a
+share sheet per card) pays one element per closed popup at every mount, not a
+popup: a row may carry the popups of its own actions. It is built at once when
+something needs it from the start — open at mount, a `navState`, an `anchor` (a
+hover builds the content ahead of the click), or a `mount` other than the
+default. A `Picker`'s popup is the picker's own, built with it.
 
 "Closed" is two states, not one — never opened yet, and closed again after an
 opening — so the `mount` prop answers both at once: