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>
32 lines
1.8 KiB
JavaScript
32 lines
1.8 KiB
JavaScript
// The module API version — the single number a module's `coreApi` range is
|
|
// checked against (docs/website/MODULE_API.md §1.1).
|
|
//
|
|
// Bump minor when a member is ADDED to ctx or a new register* call appears;
|
|
// major when one is removed, its signature changes, or its behaviour changes
|
|
// without a signature change. A core-internal refactor behind an unchanged
|
|
// member is not a bump.
|
|
//
|
|
// Deliberately separate from PROTOCOL_VERSION (which versions the shard wire and
|
|
// has nothing to say about a website module) and from any module's own version.
|
|
|
|
// 1.3.0 — three CLIENT additions from Phase 3 slice 3: a nav item may carry an
|
|
// `icon`, core declares a `player.invite.accepted` slot, and `window.__rg.api`
|
|
// gained `BASE` (which §3.5 always specified and shared.js never published).
|
|
// Nothing on the server changed; this file bumps for the reason below.
|
|
//
|
|
// 1.2.0 — the CLIENT registry gained `registerExtension` and core gained client
|
|
// extension slots (MODULE_API.md §3.7): the twin of this half's declareSlot /
|
|
// registerExtension, for module content inside a core *page* rather than under a
|
|
// core route prefix. Nothing on the server changed, and this file bumps anyway —
|
|
// the two halves state ONE version, because a module declares a single `coreApi`
|
|
// range and is served one chunk (client/src/modules/version.js).
|
|
//
|
|
// 1.1.0 — `ctx` gained `activity.log`, `users.getById` and `site.baseUrl`, each
|
|
// because module-uo's extraction needed it and none of them could be vendored:
|
|
// an admin action a module performs belongs in core's one audit log, the
|
|
// extension slot needs the user its prefix names, and §2.7 forbids a module
|
|
// reading core's `APP_BASE_URL` for itself. Additions only, so minor.
|
|
const MODULE_API_VERSION = '1.3.0'
|
|
|
|
module.exports = { MODULE_API_VERSION }
|