Skip to main content
A production-style integration demonstrating pre-launch capability validation, lifecycle event forwarding, error state handling, completion routing, and graceful degradation for environment-sensitive features.

What this example demonstrates

  • Pre-launch capability detection with explicit user warning when requirements aren’t met
  • Journey state machine (loading → active → completed / failed / error)
  • Lifecycle event forwarding (visibilitychangehost.background / host.foreground)
  • Capability handler registration via useBridgeCapability with busy guards
  • Custom capability registration for non-camera actions
  • Delegate-based event routing (journey lifecycle → React state)
  • Graceful degradation when capabilities are unavailable

Complete source

The full source below is a single React file demonstrating pre-launch capability validation, journey state routing, lifecycle event forwarding, and busy-guarded capture handlers. Section markers are omitted — read straight through, or use the architecture diagram after the code to navigate.

Architecture overview

Key patterns demonstrated

Four patterns are worth calling out — they’re the load-bearing pieces that turn the raw code above into a production-shaped integration.

Pre-launch capability validation

Before opening the journey iframe, the launcher checks whether all required capabilities are supported. If anything is missing, the user sees a warning with an explicit “Continue anyway” / “Cancel” choice.
This prevents users from starting journeys that will fail at a missing capability mid-flow.

Lifecycle event forwarding

The host forwards browser visibility changes as bridge events so the journey can pause / resume internal timers:
Browsers also fire pagehide and pageshow events for back/forward cache transitions — wire those too if your journey state depends on it.

Journey state routing

Multiple useBridgeHostEvent subscriptions in a single component route inbound lifecycle events into a React state machine:
This pattern keeps the journey iframe hidden during loading, visible during the active phase, and replaced with a completion overlay once the journey ends.

Busy guard for capture handlers

The web SDK doesn’t enforce single-flight on raw handlers (unlike iOS/Android typed slots). The example implements it explicitly using a useRef for the active responder:
Also cancel any in-flight responder on unmount — otherwise the journey can be left waiting if the user navigates away mid-capture.

Two patterns side by side

  • Document capture uses useBridgeCapability with a declared camera.document entry in the provider’s capabilities prop — the standard two-step pattern.
  • Device info uses host.registerCustomCapability via useBridgeHost — the one-call pattern. Both declaration and registration happen in a single call after the host attaches.
Choose based on whether the capability is known at provider construction time (two-step) or added dynamically (one-call).

Graceful degradation

detectCapabilities runs once at mount. If the browser doesn’t support getUserMedia or navigator.permissions, the launcher shows a warning before launching journeys that need camera capture. The journey itself sees supported: false on camera.document and can choose to skip the step or fall back to a JS-side implementation.

Running this example

  1. Install @gbg/go-bridge-web and @gbg/go-bridge-web-react.
  2. Add the code above to your React project (e.g., as src/App.tsx).
  3. Update the JOURNEYS config to point at your real journey URLs.
  4. Add appropriate CSP frame-src and iframe allow for the journey origin.
  5. Run your dev server (Vite, Next.js, etc.).
  6. Open the page — pick a journey from the launcher and walk through the flow.

Next steps

  • Capability Handling — Deep dive on declaring, registering, and dynamic capabilities.
  • Security — Origin allowlist, CSP, and production hardening.
  • API Reference — Complete type reference.
  • Tutorial — Build a full app with backend token exchange.