@autobusal/providers 1.6.7 → 1.6.8

package/CHANGELOG.md

@@ -4,6 +4,31 @@ All notable changes to `@autobusal/providers` are documented here. This project
 adheres to [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.6.8] - 2026-07-31
+
+### Removed
+
+- **`Recaptcha/Recaptcha.tsx` and its `<Recaptcha>` wrapper around the
+  app in `Providers.tsx`.** This mounted `GoogleReCaptchaProvider`
+  (`react-google-recaptcha-v3`) as a persistent context provider inside
+  the same Suspense tree as `Styles`/`Notifications`/`Setup`; that
+  provider's script/badge injection is async and not remount-safe, and
+  any remount of it left the DOM in a state that could throw an
+  uncaught `removeChild`/`insertBefore` error on the next reconciliation
+  anywhere near the root - the actual root cause of the frozen-
+  navigation bug 1.6.6/1.6.7 worked around. `@autobusal/hooks` 1.3.1
+  moved reCAPTCHA to the same on-demand, no-provider pattern Turnstile
+  already used (`useRecaptcha`'s external API is unchanged), so nothing
+  needs this wrapper anymore - removing it removes the remount risk at
+  the root instead of continuing to recover from it. `useGetSettings()`
+  et al are otherwise unaffected: `Styles`/`Notifications`/`Setup` still
+  share the outer boundary exactly as before, just without `Recaptcha`
+  in the tree.
+- **`useRecoverFromDomCorruption()`'s global `removeChild`/`insertBefore`
+  listener**, added in 1.6.7 as a backstop specifically for the
+  `GoogleReCaptchaProvider` remount corruption above. With that provider
+  gone, its trigger no longer exists.
+
 ## [1.6.7] - 2026-07-31
 
 ### Added

package/Providers.tsx

@@ -1,5 +1,4 @@
-import { Suspense, useEffect } from 'react';
-import Recaptcha from './Recaptcha/Recaptcha';
+import { Suspense } from 'react';
 import Queries from './Queries/Queries';
 import Styles from './Styles/Styles';
 import Notifications from './Notifications/Notifications';
@@ -11,103 +10,39 @@ interface Props {
   children: JSX.Element
 }
 
-// Edited: Ferjolt Ozuni - Date: 2026-07-31
-// Defensive backstop for the removeChild corruption described below: even
-// with Setup's suspension isolated, GoogleReCaptchaProvider's script/badge
-// injection is inherently async (a script tag's onload race against React's
-// synchronous mount/cleanup), so a rare remount can still leave the DOM in a
-// state that throws on the next reconciliation - and that throw is NOT
-// render-phase, so no ErrorBoundary catches it. Left alone, this strands the
-// user on whatever was on screen with a URL that no longer matches it and no
-// working navigation (the exact "stuck, can't log out" symptom). A hard
-// reload of the current URL always recovers cleanly (proven: the router's
-// history.pushState already applied), so self-heal with one, guarded against
-// looping if the error turns out to be persistent rather than transient.
-const useRecoverFromDomCorruption = (): void => {
-  useEffect(() => {
-    const RECOVERY_KEY = 'autobusalDomRecoveryAt';
-
-    const onError = (event: ErrorEvent): void => {
-      const message = event.message || '';
-
-      if (!message.includes('removeChild') && !message.includes('insertBefore')) {
-        return;
-      }
-
-      const last = Number(sessionStorage.getItem(RECOVERY_KEY) || 0);
-
-      if (Date.now() - last < 10000) {
-        return;
-      }
-
-      sessionStorage.setItem(RECOVERY_KEY, String(Date.now()));
-      window.location.reload();
-    };
-
-    window.addEventListener('error', onError);
-
-    return () => window.removeEventListener('error', onError);
-  }, []);
-};
-
-const Providers = ({ type, loading, children }: Props): JSX.Element => {
-  useRecoverFromDomCorruption();
-
-  return (
-    // Styles and Setup both call useGetSettings() (a useSuspenseQuery) and
-    // sit ABOVE the inner <Suspense> below, so on a cold settings cache their
-    // suspension had no boundary to catch it and React threw error #426
-    // ("a component suspended while responding to synchronous input"). This
-    // outer boundary catches those two suspensions (showing `loading` during
-    // the initial settings fetch). The QueryClient in <Queries> is created
-    // at module scope, so remounting this subtree while suspended keeps the
-    // same client and cache - no refetch loop.
-    // Edited: Ferjolt Ozuni - Date: 2026-07-25
-    // Recaptcha moved INSIDE Queries: it now reads the label's runtime
-    // captcha settings via useGetSettings(), which needs the
-    // QueryClientProvider (and suspends into the outer boundary on a cold
-    // cache, like Styles/Setup).
-    // Edited: Ferjolt Ozuni - Date: 2026-07-31
-    // Bug: Setup also calls useGetMenu() (a SEPARATE useSuspenseQuery, its
-    // own cache key/promise) in its own render body, still inside this same
-    // outer boundary. On a cold menu cache, that suspends AFTER Recaptcha/
-    // Styles/Notifications above it have already committed - and a Suspense
-    // boundary re-suspending after its content is already committed hides/
-    // discards that whole committed subtree and mounts it again once ready.
-    // Recaptcha's GoogleReCaptchaProvider isn't remount-safe: its script/
-    // badge injection is async and outside React's DOM bookkeeping, so
-    // remounting it left a duplicate, half-torn-down
-    // <div class="grecaptcha-badge"> behind. That corrupted DOM state then
-    // threw an uncaught "Cannot read properties of null (reading
-    // 'removeChild')" the next time React reconciled anywhere near the root
-    // - which is every route change, since Recaptcha wraps the whole router
-    // - silently aborting the commit. The URL would update (the router's
-    // history.pushState already ran) but the page itself would never
-    // re-render, freezing navigation app-wide with no console-visible error
-    // (uncaught DOM exceptions like this don't hit the render-phase-only
-    // ErrorBoundary). Giving Setup its own inner boundary means its menu
-    // suspension can only hide/retry ITSELF, not the already-committed
-    // Recaptcha/Styles/Notifications above it - this closed off the
-    // deterministic trigger, and useRecoverFromDomCorruption() above is the
-    // backstop for whatever async-timing sliver still gets through.
-    <Suspense fallback={ loading }>
-      <Queries>
-        <Recaptcha>
-          <Styles>
-            <Notifications>
+const Providers = ({ type, loading, children }: Props): JSX.Element => (
+  // Styles and Setup both call useGetSettings() (a useSuspenseQuery) and sit
+  // ABOVE the inner <Suspense> below, so on a cold settings cache their
+  // suspension had no boundary to catch it and React threw error #426
+  // ("a component suspended while responding to synchronous input"). This
+  // outer boundary catches those two suspensions (showing `loading` during
+  // the initial settings fetch). The QueryClient in <Queries> is created at
+  // module scope, so remounting this subtree while suspended keeps the same
+  // client and cache - no refetch loop.
+  // Edited: Ferjolt Ozuni - Date: 2026-07-31
+  // Setup also calls useGetMenu() (a SEPARATE useSuspenseQuery, its own
+  // cache key/promise) in its own render body. Kept in its own inner
+  // <Suspense> rather than sharing the outer one: a cold menu cache
+  // suspending after Styles/Notifications above it have already committed
+  // would otherwise hide/discard that already-committed content and remount
+  // it once ready - harmless for Styles/Notifications themselves, but a
+  // needless remount of anything stateful sitting there is worth avoiding on
+  // principle.
+  <Suspense fallback={ loading }>
+    <Queries>
+      <Styles>
+        <Notifications>
+          <Suspense fallback={ loading }>
+            <Setup type={ type }>
               <Suspense fallback={ loading }>
-                <Setup type={ type }>
-                  <Suspense fallback={ loading }>
-                    { children }
-                  </Suspense>
-                </Setup>
+                { children }
               </Suspense>
-            </Notifications>
-          </Styles>
-        </Recaptcha>
-      </Queries>
-    </Suspense>
-  );
-};
-
-export default Providers;
+            </Setup>
+          </Suspense>
+        </Notifications>
+      </Styles>
+    </Queries>
+  </Suspense>
+);
+
+export default Providers;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobusal/providers",
-  "version": "1.6.7",
+  "version": "1.6.8",
   "author": "Ferjolt Ozuni",
   "type": "module",
   "main": "index.ts"

package/Recaptcha/Recaptcha.tsx

@@ -1,36 +0,0 @@
-import { GoogleReCaptchaProvider } from 'react-google-recaptcha-v3';
-import { useGetSettings } from '../services';
-
-interface Props {
-  children: JSX.Element
-}
-
-// Edited: Ferjolt Ozuni - Date: 2026-07-25
-// The captcha provider + site key are now the label's runtime settings
-// (/api/settings/get, managed at /admin/label?type=captcha) instead of the
-// build-time VITE_RECAPTCHA_KEY - which stays only as a fallback for labels
-// without a captcha config yet. The Google provider script is mounted ONLY
-// when reCAPTCHA is the active provider; Cloudflare Turnstile needs no
-// app-wide provider (its script is loaded on demand by useRecaptcha in
-// @autobusal/hooks). NB: this component now calls useGetSettings(), so it
-// must sit INSIDE <Queries> (see Providers.tsx).
-const Recaptcha = ({ children }: Props): JSX.Element => {
-  const { data } = useGetSettings();
-
-  const provider = data?.captcha?.provider
-    ?? (import.meta.env.VITE_RECAPTCHA_KEY ? 'recaptcha' : 'none');
-
-  const siteKey = data?.captcha?.site_key ?? import.meta.env.VITE_RECAPTCHA_KEY;
-
-  if (provider !== 'recaptcha' || !siteKey) {
-    return children;
-  }
-
-  return (
-    <GoogleReCaptchaProvider reCaptchaKey={ siteKey }>
-      { children }
-    </GoogleReCaptchaProvider>
-  );
-};
-
-export default Recaptcha;