@autobusal/providers 1.6.8 → 1.7.0

package/CHANGELOG.md

@@ -4,6 +4,41 @@ 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.7.0] - 2026-07-31
+
+### Added
+
+- **`LabelSettings.seo` / `SettingsData.seo`** (`types/settings.ts`): optional
+  homepage title/description/keywords override, admin-managed via the new
+  `@autobusal/admin-label` 1.9.0 SEO tab and persisted through obtapi's
+  `Labels\AdminController::seo()`. `SettingsData.seo` is the public-safe
+  subset exposed by `Settings\ViewController::get()` for `StaticHome.tsx`
+  to prefer over its i18n translation-template values when set.
+- **`CountryData.seo_title`/`seo_description`/`seo_keywords` and the same
+  three fields on `CityData`** (`types/locations.ts`): optional per-entity
+  override for a country/city landing page's meta tags, admin-managed
+  through the existing Countries/Cities admin forms and persisted via
+  obtapi's `Countries\AdminController`/`Cities\AdminController`.
+  `LocationCountry.tsx`/`LocationCity.tsx` prefer these over their i18n
+  translation-template + live-stats content when set.
+
+## [1.6.9] - 2026-07-31
+
+### Added (re-added)
+
+- **`useRecoverFromDomCorruption()`'s global `removeChild`/`insertBefore`
+  listener is back**, generalized. Removed in 1.6.8 as a backstop
+  specifically for `GoogleReCaptchaProvider`'s remount corruption, on the
+  assumption that removing that provider removed the trigger. It didn't:
+  `@autobusal/common` 1.8.3 fixed a second, independent cause
+  (`Meta.tsx`'s stale-tag cleanup racing React 19's own `<title>`/`<meta>`
+  hoisting), and the exact same uncaught error still reproduced
+  intermittently with BOTH fixes shipped - some remaining React/router
+  timing edge case neither touches. Reinstated as a permanent safety net
+  rather than a fix for one specific bug: whatever the next contributing
+  cause turns out to be, a reload of the current URL has recovered
+  cleanly in every reproduction so far.
+
 ## [1.6.8] - 2026-07-31
 
 ### Removed

package/Providers.tsx

@@ -1,4 +1,4 @@
-import { Suspense } from 'react';
+import { Suspense, useEffect } from 'react';
 import Queries from './Queries/Queries';
 import Styles from './Styles/Styles';
 import Notifications from './Notifications/Notifications';
@@ -10,39 +10,90 @@ interface Props {
   children: JSX.Element
 }
 
-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 }>
-                { children }
-              </Suspense>
-            </Setup>
-          </Suspense>
-        </Notifications>
-      </Styles>
-    </Queries>
-  </Suspense>
-);
+// Edited: Ferjolt Ozuni - Date: 2026-07-31
+// Permanent safety net, not a fix for one specific bug. Two real, separate
+// causes of a client-side navigation silently never landing were found and
+// fixed - GoogleReCaptchaProvider's remount corruption (removed entirely,
+// see this package's 1.6.6-1.6.8 and @autobusal/hooks 1.3.1) and Meta.tsx's
+// stale-tag cleanup racing React 19's own <title>/<meta> hoisting (see
+// @autobusal/common 1.8.3) - and the exact same uncaught "Cannot read
+// properties of null (reading 'removeChild')" still reproduced
+// intermittently with both gone: some remaining React/router timing edge
+// case neither fix touches. That class of error is thrown outside React's
+// render phase, so no ErrorBoundary catches it, and it silently aborts
+// whatever navigation was in flight - the URL updates (the router's
+// history.pushState already ran) but the page itself never re-renders, with
+// no visible error and no way to navigate out. A reload of the current URL
+// has recovered cleanly in every reproduction so far, so: watch for this
+// exact error signature anywhere in the app and self-heal with one reload,
+// cooldown-guarded so a genuinely persistent error can't loop. Logout.tsx/
+// LoginAs.tsx carry a second, more targeted watchdog (a plain timer, not
+// error-triggered) for the two pages users actually get stuck on during
+// impersonation - this one is the general backstop for everywhere else.
+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-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 }>
+                  { children }
+                </Suspense>
+              </Setup>
+            </Suspense>
+          </Notifications>
+        </Styles>
+      </Queries>
+    </Suspense>
+  );
+};
 
 export default Providers;

package/package.json

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

package/types/locations.ts

@@ -25,6 +25,14 @@ export interface CountryData {
   iso_code: string
   available?: number
   stats?: CountryStats
+
+  // Edited: Ferjolt Ozuni - Date: 2026-07-31
+  // Optional hand-written override for the public country page's title/
+  // description/keywords - see LocationCountry.tsx for the fallback-to-
+  // template logic when these are unset.
+  seo_title?: string
+  seo_description?: string
+  seo_keywords?: string
 }
 
 export interface CityStats {
@@ -62,6 +70,14 @@ export interface CityData {
   image?: string[]
   stats?: CityStats
   destinations?: CityDestination[]
+
+  // Edited: Ferjolt Ozuni - Date: 2026-07-31
+  // Optional hand-written override for the public city page's title/
+  // description/keywords - see LocationCity.tsx for the fallback-to-
+  // template logic when these are unset.
+  seo_title?: string
+  seo_description?: string
+  seo_keywords?: string
 }
 
 export interface StopData {

package/types/settings.ts

@@ -18,6 +18,16 @@ export interface SettingsData {
     telegram: { available: boolean, price: number }
   }
 
+  // Edited: Ferjolt Ozuni - Date: 2026-07-31
+  // Optional admin-managed override for the homepage's title/description/
+  // keywords (Labels\AdminController::seo()) - StaticHome.tsx prefers these
+  // over its i18n translation-template values when set.
+  seo?: {
+    title?: string
+    description?: string
+    keywords?: string
+  }
+
   preferences: {
     company: string
 
@@ -194,6 +204,15 @@ export interface LabelSettings {
     linkedin?: string
     trustpilot?: string
   }
+
+  // Edited: Ferjolt Ozuni - Date: 2026-07-31
+  // Admin-managed homepage SEO override (public seo? above is populated
+  // from this) - see Labels\AdminController::seo().
+  seo?: {
+    title?: string
+    description?: string
+    keywords?: string
+  }
 }
 
 // Edited: Ferjolt Ozuni - Date: 2026-07-18