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 (
visibilitychange→host.background/host.foreground) - Capability handler registration via
useBridgeCapabilitywith 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.Lifecycle event forwarding
The host forwards browser visibility changes as bridge events so the journey can pause / resume internal timers:pagehide and pageshow events for back/forward cache transitions — wire those too if your journey state depends on it.
Journey state routing
MultipleuseBridgeHostEvent subscriptions in a single component route inbound lifecycle events into a React state machine:
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 auseRef for the active responder:
Two patterns side by side
- Document capture uses
useBridgeCapabilitywith a declaredcamera.documententry in the provider’scapabilitiesprop — the standard two-step pattern. - Device info uses
host.registerCustomCapabilityviauseBridgeHost— the one-call pattern. Both declaration and registration happen in a single call after the host attaches.
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
- Install
@gbg/go-bridge-weband@gbg/go-bridge-web-react. - Add the code above to your React project (e.g., as
src/App.tsx). - Update the
JOURNEYSconfig to point at your real journey URLs. - Add appropriate CSP
frame-srcandiframe allowfor the journey origin. - Run your dev server (Vite, Next.js, etc.).
- 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.