wtclaude
5b5006c365
The three things core owes the client half before it can leave, all additive, all MODULE_API 1.2.0 → 1.3.0. `player.invite.accepted` is the third extension slot. Core's invite page owned a UO game-account step — it read a `gameAccountSignup` flag out of core's own settings and posted to a shard route — and an invite is a core concept that staff receive too, so the page stays and its optional next step becomes a slot. Named for the place, like the other two. Whether there is a step at all is the filling module's call, made from data core does not have; core keeps the shell, the skip control and the destination. `icon` on a nav item, because without it the six extracted UO rows would have been the only text-only entries in a sidebar where every other row has a glyph. Core supplies no fallback — an invented one is core making a presentation choice for content it knows nothing about. `icon` was already among the fields an override may not touch, so the concept predates a module being able to send one. `api.BASE` was in §3.5 from the first draft and never actually published. `request` is fetch-only, so an EventSource builds its own URL, and the shard's live feed is two of them; the alternative is a module hardcoding `/api/v1`, which asserts something about core that core has not promised. `AcceptInvite` is the one legitimate reader of `extensionFor` outside Slot.jsx: the answer decides a NAVIGATION, not a decoration. Decoration goes inside `<Slot wrap>`, which is why `hasExtension` stayed deleted. Co-Authored-By: Claude <noreply@anthropic.com>
30 lines
1.9 KiB
JavaScript
30 lines
1.9 KiB
JavaScript
// The client's copy of MODULE_API_VERSION. It must equal the server's
|
|
// (server/src/modules/version.js) — the two halves version ONE contract
|
|
// (docs/website/MODULE_API.md §1.1), and a module checks whichever half it is
|
|
// talking to: `coreApi` against the server's at load time, `window.__rg.version`
|
|
// against the client's before it registers anything.
|
|
//
|
|
// Duplicated rather than fetched, and that is deliberate. The value has to be on
|
|
// `window.__rg` before the first module chunk evaluates, which is earlier than
|
|
// any network round trip could answer — a fetched version would mean either an
|
|
// await before render or a module reading `undefined`. The cost of the copy is
|
|
// that the two files can drift, so a test asserts they agree
|
|
// (client/test/moduleRegistry.test.js) rather than trusting a bump to remember
|
|
// both.
|
|
// 1.3.0 — three additions, all from Phase 3 slice 3 needing them: a nav item may
|
|
// carry an `icon` component (§3.3), core declares a third slot
|
|
// `player.invite.accepted` (§3.7), and `window.__rg.api` gained `BASE`, which
|
|
// §3.5 always documented and shared.js never published. Additive throughout: a
|
|
// module written against 1.2.0 is unaffected. The server half is untouched and
|
|
// bumps anyway, for the reason below.
|
|
// 1.2.0 — `registry` gained `registerExtension` and core gained extension slots
|
|
// (MODULE_API.md §3.7). The first change to window.__rg since 1.0.0, and an
|
|
// addition: a module that never fills a slot is unaffected. The server half is
|
|
// untouched and bumps anyway, for the reason below.
|
|
// 1.1.0 — the server's ctx gained activity.log, users.getById, site.baseUrl and
|
|
// the rate-limit factory (MODULE_API.md §2.3). Nothing on window.__rg changed,
|
|
// but the two halves state ONE version: a module declares a single coreApi range
|
|
// and is served one chunk, so a client that claimed 1.0.0 while the server
|
|
// answered 1.1.0 would be two answers to one question.
|
|
export const MODULE_API_VERSION = '1.3.0'
|