// ── 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}`)