@dynamic-labs/react-native-extension 4.92.4 → 4.93.1

package/src/components/WebView/webViewPhaseTimerCore/webViewPhaseTimerCore.d.ts

@@ -1,123 +0,0 @@
-import { Core } from '@dynamic-labs/client';
-/**
- * Per-attempt lifecycle event recorded by the phase-timer core.
- *
- * - `load_start` — native bridge fired `onLoadStart` (resets per-attempt
- *   state so timings reflect the current attempt)
- * - `load` — native bridge fired `onLoad` (HTML byte stream received)
- * - `load_end` — native bridge fired `onLoadEnd` (page finished
- *   rendering)
- * - `native_error` — native bridge raised an `onLoadError`; increments a
- *   counter that persists across reloads
- * - `os_kill` — host detected an OS-level WebView kill (e.g. backgrounded
- *   for too long); also a cumulative counter
- */
-export type WebViewPhaseEvent = 'load' | 'load_end' | 'load_start' | 'native_error' | 'os_kill';
-export type PerAttemptTimings = {
-    htmlLoadStartedAt: number | null;
-    htmlLoadedAt: number | null;
-    manifestReceivedAt: number | null;
-    onLoadEndAt: number | null;
-    sdkReadyAt: number | null;
-};
-export type CumulativeCounters = {
-    nativeErrorCount: number;
-    osKillCount: number;
-};
-export type PhaseDurations = {
-    htmlLoadMs: number | null;
-    manifestReceivedMs: number | null;
-    onLoadToOnLoadEndMs: number | null;
-    sdkReadyMs: number | null;
-};
-/**
- * Derive cross-phase durations from raw timestamps. The four durations
- * are what end up in the failure / success log meta:
- *
- * - `htmlLoadMs` — `onLoadStart` to `onLoad`; native HTML fetch
- * - `onLoadToOnLoadEndMs` — `onLoad` to `onLoadEnd`; native render/parse
- * - `manifestReceivedMs` — `onLoadEnd` to first `manifest` request from
- *   the webview JS; "JS bundle is alive" signal
- * - `sdkReadyMs` — `onLoadEnd` to first `sdkHasLoaded` event from the
- *   webview JS; "SDK fully bootstrapped" signal
- */
-export declare const computePhaseDurations: (timings: PerAttemptTimings) => PhaseDurations;
-export type WebViewPhaseTimerCore = {
-    /** Detach the message-transport subscription. */
-    dispose: () => void;
-    getCounters: () => CumulativeCounters;
-    getTimings: () => PerAttemptTimings;
-    recordEvent: (event: WebViewPhaseEvent) => void;
-};
-/**
- * Path-agnostic shape of the `webview.load_succeeded` instrumentation
- * log meta. Both the React `<WebView>` and the embedded native WebView
- * paths emit this exact surface so the two log streams can be queried
- * together in Datadog without per-path field translation.
- *
- * The failure meta (`WebViewFailedToLoadErrorMeta`) is this shape plus
- * a `phase` discriminator — see `buildSuccessMeta` callers.
- */
-export type WebViewLoadSuccessMeta = {
-    hadClearState: boolean;
-    htmlLoadMs: number | null;
-    loadingTimeoutMs: number;
-    manifestReceivedMs: number | null;
-    nativeErrorCount: number;
-    onLoadToOnLoadEndMs: number | null;
-    osKillCount: number;
-    recoveryTimeoutMs: number;
-    retryCount: number;
-    sdkReadyMs: number | null;
-    webviewUrl: string;
-};
-type BuildSuccessMetaArgs = {
-    /**
-     * Snapshot source for raw timings + cumulative counters. Typically a
-     * live {@link WebViewPhaseTimerCore} instance, but the type only
-     * requires `getTimings` / `getCounters` so callers can fall back to
-     * empty values if the core hasn't been created yet.
-     */
-    core: Pick<WebViewPhaseTimerCore, 'getCounters' | 'getTimings'>;
-    /**
-     * Whether the current attempt was kicked off by the React
-     * `<WebView>`'s clear-state recovery flow. Embedded path is always
-     * `false`.
-     */
-    hadClearState: boolean;
-    loadingTimeoutMs: number;
-    recoveryTimeoutMs: number;
-    /**
-     * Number of times the React `<WebView>` re-mounted via the `?retry=`
-     * URL query param. Embedded path is always `0`.
-     */
-    retryCount: number;
-    webviewUrl: string;
-};
-/**
- * Build the success-shape meta from a {@link WebViewPhaseTimerCore}
- * snapshot plus the path-specific fields. Both call sites call this
- * with their own context (RN reads `hadClearState` / `retryCount` from
- * the URL; embedded passes constants) so the success-log payload stays
- * identical across the two paths.
- */
-export declare const buildSuccessMeta: ({ core, hadClearState, loadingTimeoutMs, recoveryTimeoutMs, retryCount, webviewUrl, }: BuildSuccessMetaArgs) => WebViewLoadSuccessMeta;
-/**
- * Shared state machine driving WebView load-phase instrumentation.
- *
- * Both the React `<WebView>` (RN bridge) and the native embedded WebView
- * (native bridge) feed lifecycle events into this core and produce
- * matching meta from the same timings + counters. Each path layers its
- * own path-specific fields (`hadClearState`, `retryCount`, etc.) on top
- * of the raw state this core exposes via `getTimings()` / `getCounters()`.
- *
- * The core owns the `core.messageTransport` subscription that captures
- * the two webview-originated signals bracketing SDK bootstrap
- * (`manifest` once the JS bundle is alive; `sdkHasLoadedEventName`
- * once the SDK is fully ready). Native bridge lifecycle events come in
- * via `recordEvent` instead.
- */
-export declare const createWebViewPhaseTimerCore: ({ core, }: {
-    core: Core;
-}) => WebViewPhaseTimerCore;
-export {};