feat(hooks): generalise security-level family + audit catch + reactivity test

Build on the useIsModerator landing (532cb28c) along three axes:

1. Family. Extract `useHasSecurityLevel(min)` as the primitive,
   backed by a fresh `useUserSecurityLevel()` raw-level reader. The
   six SecurityLevel constants (1..9) deserve named wrappers so the
   "show this only to X-and-up" pattern doesn't get re-derived ad-hoc
   each time: shipped `useIsModerator` / `useIsPlayerSupport` /
   `useIsCommunity` / `useIsAdmin` as one-line shims. Also added
   `useIsAmbassador()` as a sibling — not derived from security level,
   reads the boolean field on the snapshot directly.

2. Audit. The 532cb28c migration covered 6 React-render reads but
   missed 5 more discovered by a follow-up grep:
   - FurniEditorView (top-level `const isMod`)
   - InfoStandWidgetFurniView (inline JSX, mod-only build-tools button)
   - NavigatorRoomInfoView (3 reads in hasPermission(): isModerator
     and securityLevel >= COMMUNITY for the staff-pick gate. The
     userId read stays imperative — userId doesn't flip at runtime in
     practice, no reactivity gain.)
   - AvatarInfoWidgetPetView (inside useMemo with [roomSession] deps;
     migrated and isModerator added to the deps so a runtime
     promote/demote re-derives canPickUp without remount)
   - FurnitureMannequinView (inside useEffect; same treatment — added
     isModerator to the deps so the mode re-resolves on flip)

   The remaining ~17 reads (CanManipulateFurniture,
   AvatarInfoUtilities.populate*, useChatInputActions,
   useFurnitureDimmerWidget / useFurniturePlaylistEditorWidget /
   useFurnitureStickieWidget canModify checks, useCatalog admin
   filter, useNavigator door-mode guard) are click-time / event-time
   imperative — they read at the moment a user action fires, so a
   reactive value would be cached at hook execution and stale by the
   time the action runs. Leaving them on the synchronous manager read
   is correct.

3. Test. Added four cases pinning the contract:
   - useUserSecurityLevel returns the raw level.
   - useHasSecurityLevel does `>=` against the threshold.
   - Named wrappers map to the right constants (MODERATOR=5,
     COMMUNITY=7, ADMINISTRATOR=8).
   - **Reactive flip** — mutate the snapshot, dispatch the
     SESSION_DATA_UPDATED event on the mock dispatcher, assert the
     hook re-derives. Locks in the whole point of the snapshot
     pattern (a static read would pass cases 1-3 but fail case 4).

Mock changes:
- Added SecurityLevel class (mirrors the renderer enum 0..9) so the
  family wrappers resolve to actual numbers in jsdom — without it
  `useIsModerator()` would call `useHasSecurityLevel(undefined)` and
  the test would silently pass false-positives.

Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test
213/213 (209 baseline + 4 new family/reactivity cases).
This commit is contained in:
simoleo89
2026-05-19 18:18:20 +02:00
parent 532cb28ca7
commit c11a6c4699
8 changed files with 182 additions and 28 deletions
+30 -10
View File
@@ -124,18 +124,38 @@ export const useIsUserIgnored = (name: string): boolean =>
};
/**
* Reactive equivalent of `GetSessionDataManager().isModerator`. Derives
* from `useUserDataSnapshot().securityLevel` so any future
* promote/demote that flips the SESSION_DATA_UPDATED event re-renders
* the consumer without an F5. Mirrors the renderer-side getter at
* `SessionDataManager.ts:684` (`securityLevel >= SecurityLevel.MODERATOR`).
* Reactive raw security level from the user snapshot. Use this when
* you need the numeric level (e.g. to compare against a threshold not
* covered by the named wrappers below); for the common case of "is
* the user at least <X>?", prefer the matching `useIsXxx` predicate.
*/
export const useIsModerator = (): boolean =>
{
const userData = useUserDataSnapshot();
export const useUserSecurityLevel = (): number => useUserDataSnapshot().securityLevel;
return userData.securityLevel >= SecurityLevel.MODERATOR;
};
/**
* Reactive predicate: does the current user's security level satisfy
* `>= minLevel`? Mirrors the renderer-side comparison used by
* `SessionDataManager.isModerator` (and its peers) and propagates the
* SESSION_DATA_UPDATED invalidation, so a runtime promote/demote
* re-renders the consumer.
*
* The named wrappers below (`useIsModerator`, `useIsAdmin`, …) are
* one-line shims over this primitive — use them in widget bodies for
* readability; reach for `useHasSecurityLevel(level)` directly only
* when the threshold is dynamic or not covered by a named wrapper.
*/
export const useHasSecurityLevel = (minLevel: number): boolean =>
useUserSecurityLevel() >= minLevel;
export const useIsModerator = (): boolean => useHasSecurityLevel(SecurityLevel.MODERATOR);
export const useIsPlayerSupport = (): boolean => useHasSecurityLevel(SecurityLevel.PLAYER_SUPPORT);
export const useIsCommunity = (): boolean => useHasSecurityLevel(SecurityLevel.COMMUNITY);
export const useIsAdmin = (): boolean => useHasSecurityLevel(SecurityLevel.ADMINISTRATOR);
/**
* Reactive ambassador flag. Not derived from security level — it's a
* separate boolean on the snapshot.
*/
export const useIsAmbassador = (): boolean => useUserDataSnapshot().isAmbassador;
export const useGroupBadgesSnapshot = (): ReadonlyMap<number, string> =>
useExternalSnapshot(