Phase 2, PR 8 of docs/website/MODULE_SYSTEM.md 2.7 - the nav half PR 7 deferred, plus the two seams 1.4 and 1.5 asked for. withModuleNav (client/src/modules/nav.js) merges an installed module's rows into core's three navs BEFORE the admin-override merge, and that ordering is the design. applyNavOverrides and buildPublicNav are keyed by `to` and drop any key their base array does not declare, so rows appended after the merge would be unorderable, unrelabellable and unhideable in Admin - Navigation. Today's UO rows are all three of those things, so appending would make the extraction a visible regression for anyone who has ever edited their nav. Merging first means a module row is an ordinary row downstream: nothing in navOverrides.js, NavEditor.jsx or the layouts knows a module exists. MOD_PATHS is gone. Moderator visibility and the redirect that confines a moderator both derive from each row's own `roles`, in the new plain-JS lib/adminNav.js (plain so the DOM-less runner can reach it). Two rows move, both toward what the server already permitted: Dashboard, whose roles had always named moderator, and My Characters, which is ungated self-service. That also fixes a defect predating the module system. The redirect was a THIRD hardcoded list - three path prefixes against MOD_PATHS' five paths - and they disagreed about /admin/houses, so a moderator who clicked Houses in their own sidebar was bounced back to Moderation. The derived allow-list is computed from the BASE nav, never the override-merged one: an override is presentation and must not move an authorization boundary either way. The feature seam (modules/features.jsx + modules/featureGate.js) resolves a row's `feature` against the provider its OWN module registered, so the namespace comes from the registration and no string carries a parsed prefix. Core registers useShardFlags under the owner id `core` - the client twin of registries.registerCore() - so the ten shard-gated header rows already run through the seam and Phase 3 deletes a registration instead of rewriting SiteHeader. Every unknown fails open: no provider, a null answer while a fetch is in flight, or a junk return all show the link, because the server is the gate and hiding a page from someone entitled to it is the worse mistake. 933 server tests (unchanged - this PR is client-only), 160 client tests (+37). routes.manifest.json unchanged at 230 routes; the OpenAPI spec regenerates byte-identical. Re-ran the MODULE_API.md 7.7 browser smoke, since this is the seam that rule exists for. A throwaway module registering nav in all three areas and a provider granting one flag and withholding another: the row lands inside core's Moderation group rather than an appended block, the withheld row does not render, a moderator reaches both /admin/houses and the module's admin page, and an admin can relabel a module row and have it persist and apply. Zero CSP reports, zero console errors. Co-Authored-By: Claude <noreply@anthropic.com>
66 lines
2.9 KiB
JavaScript
66 lines
2.9 KiB
JavaScript
import { createContext, useContext, useMemo, useState } from 'react'
|
|
import { featureProviders } from './registry.js'
|
|
import { buildFeatureGate, OPEN_GATE } from './featureGate.js'
|
|
|
|
// The React half of the feature seam. The decision logic is featureGate.js,
|
|
// which is plain JS and therefore testable in a runner with no DOM; this file is
|
|
// wiring, the same split registry.js and shared.js already use.
|
|
//
|
|
// **Calling a hook per provider inside a loop is the point, and it is legal
|
|
// here.** The rules of hooks require the same hooks in the same order on every
|
|
// render of a component — not a statically known list. The provider list is
|
|
// fixed before the first render (registration happens while module chunks
|
|
// evaluate, and main.jsx does not mount until DOMContentLoaded), there is no
|
|
// unregistering, and the snapshot below freezes it per component instance
|
|
// anyway. So the loop's length cannot change between renders of this provider,
|
|
// which is the actual requirement.
|
|
//
|
|
// A provider hook returns a Set-like of the flags this viewer may see, or `null`
|
|
// while it is still fetching. Core knows nothing else about it: what a flag
|
|
// means, how it is fetched, and what it is gated on are all the module's.
|
|
|
|
const FeatureGateContext = createContext(OPEN_GATE)
|
|
|
|
export function ModuleFeaturesProvider({ children }) {
|
|
// Snapshotted once. useState's initialiser runs on the first render only, so
|
|
// even a provider that somehow registered late cannot change this instance's
|
|
// hook count mid-life — it would be ignored until the next mount, which is a
|
|
// far better failure than a crashed render.
|
|
const [providers] = useState(featureProviders)
|
|
|
|
// eslint-disable-next-line react-hooks/rules-of-hooks -- fixed-length list, see above
|
|
const values = providers.map((provider) => provider.hook())
|
|
|
|
const gate = useMemo(
|
|
() => {
|
|
const byOwner = new Map()
|
|
// First registration wins for a given owner: a module that registers two
|
|
// namespaces answers its own nav rows from the first, rather than from
|
|
// whichever happened to be stored last.
|
|
providers.forEach((provider, i) => {
|
|
if (!byOwner.has(provider.id)) byOwner.set(provider.id, values[i])
|
|
})
|
|
return buildFeatureGate(byOwner)
|
|
},
|
|
// One dependency per provider — a fixed-length list, for the same reason the
|
|
// hook loop above is fixed-length.
|
|
// eslint-disable-next-line react-hooks/exhaustive-deps
|
|
[providers, ...values],
|
|
)
|
|
|
|
return <FeatureGateContext.Provider value={gate}>{children}</FeatureGateContext.Provider>
|
|
}
|
|
|
|
/**
|
|
* The predicate to filter nav rows with: `(item) => boolean`, true when the row
|
|
* carries no `feature` or when its module says this viewer may see it.
|
|
*
|
|
* Outside a provider it is the open gate, so a component rendered in isolation
|
|
* (a test, a preview) shows its whole nav rather than none of it.
|
|
*/
|
|
export function useFeatureGate() {
|
|
return useContext(FeatureGateContext)
|
|
}
|
|
|
|
export default ModuleFeaturesProvider
|