@mohasinac/appkit 4.35.3 → 4.35.4

package/dist/features/products/hooks/useProducts.js

@@ -3,6 +3,8 @@ import { useEffect } from "react";
 import { useQuery } from "@tanstack/react-query";
 import { apiClient } from "../../../http";
 import { useToast } from "../../../ui";
+import { useOptionalSession } from "../../../react/contexts/SessionContext";
+import { isAdminUser, isTesterUser } from "../../auth/role-predicates";
 import { PRODUCT_ENDPOINTS } from "../../../constants/api-endpoints";
 export function useProducts(params = {}, opts) {
     const { showToast } = useToast();
@@ -73,11 +75,46 @@ export function useProducts(params = {}, opts) {
             sp.set(key, value);
     }
     const qs = sp.toString();
+    /*
+     * 🛑 A TESTER MUST REFETCH; EVERYONE ELSE MUST KEEP THE CACHED SSR PAINT.
+     *
+     * Sandbox rows are correctly hidden from the public. But the SSR listing views
+     * pass no `viewer` to `listPublicProducts`, so the server-rendered grid is the
+     * anonymous one for EVERY visitor — and with `initialData` + `staleTime:
+     * Infinity` the client never refetches, so a signed-in tester saw a catalogue
+     * with no sandbox fixtures in it, on every listing page. The items were
+     * reachable by direct URL, which is what made it look like a data problem
+     * rather than a visibility one.
+     *
+     * The fix is NOT to read the session in those SSR views. `getServerSessionUser`
+     * is a dynamic API, and calling it there would make every public listing page
+     * per-request — no caching, a billed invocation per visitor, and every
+     * `revalidate` silently overridden. That is Root Cause #82, and paying it for a
+     * testing affordance would be a poor trade.
+     *
+     * `/api/products` ALREADY resolves the session and passes `viewer`. So the only
+     * thing missing was a reason for the client to ask again: the query key now
+     * carries the viewer class, giving testers their own cache entry, and their
+     * `staleTime` is not frozen. Anonymous visitors keep the cached SSR data
+     * untouched and issue no extra request.
+     *
+     * `useOptionalSession` rather than `useAuth()` on purpose — `useSession`
+     * THROWS outside a provider, and making a public appkit hook require one would
+     * be a breaking contract change (Root Cause #20). Absent provider degrades to
+     * "not a tester", which is the fail-closed answer.
+     */
+    const session = useOptionalSession();
+    const viewer = session?.user;
+    const canSeeTestData = isTesterUser(viewer) || isAdminUser(viewer);
     const query = useQuery({
-        queryKey: ["products", qs],
+        queryKey: ["products", qs, canSeeTestData ? "with-test-data" : "public"],
         queryFn: () => apiClient.get(`${PRODUCT_ENDPOINTS.LIST}${qs ? `?${qs}` : ""}`),
-        initialData: opts?.initialData,
-        staleTime: opts?.staleTime ?? (opts?.initialData != null ? Infinity : 0),
+        // The SSR paint is the anonymous view, so it is only a valid starting point
+        // for an anonymous viewer. Handing it to a tester would show them the very
+        // rows this refetch exists to reveal.
+        initialData: canSeeTestData ? undefined : opts?.initialData,
+        staleTime: opts?.staleTime ??
+            (!canSeeTestData && opts?.initialData != null ? Infinity : 0),
         enabled: opts?.enabled,
     });
     const warning = query.data?.warning;

package/dist/react/contexts/SessionContext.d.ts

@@ -95,6 +95,19 @@ export interface SessionProviderProps {
 }
 export declare function SessionProvider({ children, initialUser, endpoints: endpointOverrides, onSignOutInvalidate, signOutInvalidationKeys, }: SessionProviderProps): React.JSX.Element;
 export declare function useSession(): SessionContextValue;
+/**
+ * The session if a provider is mounted, `null` if not — never throws.
+ *
+ * `useSession` throwing is right for a component that genuinely cannot work
+ * signed-out. It is wrong for library code that merely wants to ADJUST for the
+ * viewer, because requiring a provider there turns an optional refinement into a
+ * breaking contract change for every consumer (Root Cause #20).
+ *
+ * Use this only where "no provider" has a sensible, fail-closed answer — e.g.
+ * `useProducts`, which treats an absent session as "not a tester" and keeps the
+ * public cached view.
+ */
+export declare function useOptionalSession(): SessionContextValue | null;
 export declare function useAuth(): {
     user: SessionUser | null;
     loading: boolean;

package/dist/react/contexts/SessionContext.js

@@ -394,6 +394,21 @@ export function useSession() {
     }
     return context;
 }
+/**
+ * The session if a provider is mounted, `null` if not — never throws.
+ *
+ * `useSession` throwing is right for a component that genuinely cannot work
+ * signed-out. It is wrong for library code that merely wants to ADJUST for the
+ * viewer, because requiring a provider there turns an optional refinement into a
+ * breaking contract change for every consumer (Root Cause #20).
+ *
+ * Use this only where "no provider" has a sensible, fail-closed answer — e.g.
+ * `useProducts`, which treats an absent session as "not a tester" and keeps the
+ * public cached view.
+ */
+export function useOptionalSession() {
+    return useContext(SessionContext) ?? null;
+}
 export function useAuth() {
     const { user, loading, refreshUser } = useSession();
     return { user, loading, refreshUser };

package/dist/ui/components/ImageLightbox.js

@@ -83,7 +83,26 @@ export function ImageLightbox({ images, activeIndex, onClose, onNavigate, showTh
         adjustZoom(e.deltaY < 0 ? ZOOM_STEP : -ZOOM_STEP);
     }, [adjustZoom]);
     const handleKeyDown = useCallback((e) => {
+        /*
+         * Escape unwinds ONE level: fullscreen first, the lightbox second.
+         *
+         * Unconditionally calling `onClose()` meant Escape in fullscreen tore the
+         * whole lightbox down while the browser was natively exiting fullscreen at
+         * the same moment — the user asked to leave fullscreen and lost the image
+         * they were looking at. The Exit-fullscreen BUTTON behaved correctly, which
+         * is what made this read as a keyboard quirk rather than a bug.
+         *
+         * Exiting explicitly rather than relying on the browser's own handling: the
+         * `fullscreenchange` listener above is what clears `isFullscreen`, so going
+         * through the same path keeps the button label and this state in agreement
+         * whichever way the user leaves.
+         */
         if (e.key === "Escape") {
+            if (isFullscreen) {
+                const doc = document;
+                (document.exitFullscreen?.() ?? doc.webkitExitFullscreen?.())?.catch?.(() => { });
+                return;
+            }
             onClose();
             return;
         }
@@ -112,7 +131,11 @@ export function ImageLightbox({ images, activeIndex, onClose, onNavigate, showTh
             setRotation(0);
             return;
         }
-    }, [onClose, navigate, adjustZoom]);
+    }, 
+    // `isFullscreen` is a real dependency now — Escape branches on it, and a
+    // stale closure would send the user back to the pre-fix behaviour exactly
+    // when they are in fullscreen.
+    [onClose, navigate, adjustZoom, isFullscreen]);
     // Focus overlay on open for keyboard to work
     useEffect(() => {
         if (isOpen)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohasinac/appkit",
-  "version": "4.35.3",
+  "version": "4.35.4",
   "license": "MIT",
   "publishConfig": {
     "access": "public"