wtclaude
22fd8c5da7
Phase 4. `/rust` is the server list and the module's landing page (D12);
`/rust/servers/:id` is one server with four tabs — feed, leaderboard, who is
on, wipes (D13). Everything selectable lives in the URL, so any view of the
page is a link. The feed and the presence list poll every twenty seconds while
the tab is visible and not at all when it is not (D14); the leaderboard and the
wipe list load once. `site.footer.status` is filled with a live server and
player count (D15).
Nothing on these pages calls a game server. Every field comes from this
module's own tables, which is what the phase criterion is about: the site
renders the last thing each server said while every server is off.
Walking that criterion in a browser against a live rig found four defects, two
of them already shipped in phase 3:
* An unreachable refresh called `putState` — the whole-row write — with two
fields, so a host that rebooted lost its hostname, map, size, seed and wipe
id. The list then read "Offline" with nothing beside it, which is not "here
is what we know" but "we have never heard of it". `markUnreachable` now
moves three columns and mentions no others.
* "Last reported" read `updated_at`, which a FAILED poll writes too — so an
offline server claimed it had reported just now, every thirty seconds, for
as long as it stayed down. `last_seen_at` is the new column, moved only by a
frame that arrived.
* Feed rows showed a bare time of day, so three events from six weeks ago all
read as this afternoon once the feed was filtered to a past wipe.
* `/rust/servers/typo` rendered core's ErrorState under its own heading and
read "No such server / Something went wrong", sending a reader who mistyped
a URL looking for an outage.
Also: a detail route (`GET …/servers/:id`), because it is the only route under
that path that can say a server does not exist — the other four answer an empty
list for an id nobody configured, and each of those is a good answer to its own
question.
`useAsync` cannot poll: it blanks its data on every dependency change, so a
twenty-second refresh built on it would clear the killfeed and re-fill it four
times a minute. `hooks/usePolled.js` is the module's own, invisible when it
succeeds and keeping the rows when it fails.
The client test fake was *nearly* core — it prefixed routes without stripping
the trailing separator, so the first module to register an index route failed
the nav check for a link that works in a browser. It now copies core's line
character for character.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
106 lines
5.9 KiB
JavaScript
106 lines
5.9 KiB
JavaScript
// ── The client entry point ────────────────────────────────────────────────
|
|
//
|
|
// Core serves `dist/entry.js` from this module's directory and injects it into
|
|
// its own HTML as a same-origin `<script type="module" src>` before `</body>`.
|
|
// This file registers what the module has; core renders it. Normative:
|
|
// MODULE_API.md §3.3.
|
|
//
|
|
// **Registration is synchronous and happens at evaluation time.** Module scripts
|
|
// are deferred, so this runs after core's bundle — which is where `window.__rg`
|
|
// is published — and before core's first render. There is no subscription and no
|
|
// late registration: a module that registered asynchronously would register after
|
|
// the route table had been read, and the symptom is a page that redirects home
|
|
// with nothing logged anywhere.
|
|
//
|
|
// So everything below is a plain top-level call and every page is a STATIC
|
|
// import. Lazy-loading the routes is the natural instinct for a chunk that grows,
|
|
// and it is the one thing this seam cannot have.
|
|
|
|
import { registry, coreApiVersion } from './core.js'
|
|
|
|
import Servers from './routes/public/Servers.jsx'
|
|
import ServerDetail from './routes/public/ServerDetail.jsx'
|
|
import FooterStatus from './components/FooterStatus.jsx'
|
|
|
|
// The module id, exactly as `module.json` spells it. Core keys the registry by it
|
|
// and prefixes every route path with it.
|
|
const ID = 'rust'
|
|
|
|
// ── Routes ────────────────────────────────────────────────────────────────
|
|
//
|
|
// Paths are relative to the module's namespace and core prefixes them. Whatever
|
|
// is written here, a public route lands at `/<id>/<path>`, an admin route at
|
|
// `/admin/<id>/<path>` and a player route at `/player/<id>/<path>`. A module
|
|
// cannot write the segment its routes hang under, which is the point: two modules
|
|
// installed side by side cannot collide, and an operator can see from a URL which
|
|
// module served it.
|
|
//
|
|
// So the list below is at `/rust` and the detail page at `/rust/servers/:id`.
|
|
//
|
|
// **Note what is NOT here: an auth wrapper.** `gate: { roles: [...] }` is
|
|
// available and core applies it as its own `RoleGate`; supplying your own is not
|
|
// possible, because the sidebar and the route table have to agree about who may
|
|
// see what, and they only do if one thing decides.
|
|
//
|
|
// R8's landing page is the server list, and `/rust/servers/:id` hangs beneath it.
|
|
//
|
|
// **The list is registered with an EMPTY path**, which core renders as the
|
|
// module's namespace root: `/rust`. The prefixing code strips the separator it
|
|
// would otherwise leave behind (`registry.js`: `${id}/${path}` with trailing
|
|
// slashes trimmed), so a module can own its own root without being able to spell
|
|
// its way out of it. Phase 1 served this page at `/rust/servers` and left `/rust`
|
|
// to core's CMS catch-all; the org lead settled it at `/rust` in phase 4, so the
|
|
// address an operator links to is the module's name.
|
|
//
|
|
// React Router ranks a static segment above a dynamic one, so `/rust` wins
|
|
// against core's `/:slug` CMS route without depending on registration order.
|
|
registry.registerRoutes(ID, {
|
|
public: [
|
|
{ path: '', element: <Servers /> },
|
|
{ path: 'servers/:id', element: <ServerDetail /> },
|
|
],
|
|
})
|
|
|
|
// ── Nav ───────────────────────────────────────────────────────────────────
|
|
//
|
|
// A registered row is an ORDINARY row from here on. It interleaves into core's
|
|
// own navigation, and an operator can reorder it, relabel it or hide it from the
|
|
// admin nav editor exactly as they can core's — because the interleave happens
|
|
// before the override merge, and the override layer is keyed by `to`.
|
|
//
|
|
// Three fields worth knowing before you need them:
|
|
//
|
|
// • `order` places the row among core's, which are keyed by their index. A row
|
|
// with NO order appends after them, rather than defaulting to 0 — otherwise
|
|
// "I didn't ask for a position" would mean "put me first".
|
|
// • `group` (admin sidebar) names an existing core group; an unknown name
|
|
// appends a new group at the end rather than dropping the row.
|
|
// • `icon` is a component, and core supplies no fallback. Public header rows
|
|
// carry no icons, so there is none here — but an admin or player row without
|
|
// one is the only row in its sidebar with no glyph, which reads as breakage.
|
|
registry.registerNav(ID, {
|
|
area: 'public',
|
|
items: [{ label: 'Servers', to: '/rust' }],
|
|
})
|
|
|
|
// ── Extension slots ───────────────────────────────────────────────────────
|
|
//
|
|
// Core declares a slot, only core may declare one, and at most one module may
|
|
// fill it (§3.7). `site.footer.status` is the status-ish spot in core's footer
|
|
// info row: core owns the position and passes `linkStyle`; the label, the
|
|
// destination, the data and whether anything renders at all are the module's.
|
|
//
|
|
// It is a CLIENT slot and cannot be named in `module.json`'s `extensions` —
|
|
// that array is validated against the SERVER registry, and naming a client slot
|
|
// there fails the load outright with `unknown extension slot`. Phase 1 found
|
|
// that the hard way; the two halves of R13 are declared in different places on
|
|
// purpose.
|
|
registry.registerExtension(ID, 'site.footer.status', FooterStatus)
|
|
|
|
// `module.json`'s `coreApi` range was checked by the loader before this file was
|
|
// ever served, so there is nothing to re-check here. Log it anyway: a mismatch
|
|
// between the core that validated the manifest and the core that published this
|
|
// global is otherwise invisible from the browser, which is where the client half
|
|
// actually fails.
|
|
console.info(`[${ID}] registered against core API ${coreApiVersion}`)
|