import * as react from 'react';
import { d as ThemeState, L as Listener, a as SetThemeAction, S as SetThemeOptions, e as TransitionConfig } from './types-BK2-7cKa.js';

/**
 * Subset of `StoreOptions` that the host provider may legitimately change at
 * runtime. Storage backend, attribute, themes list, and target selector are
 * intentionally *not* updateable: they are baked into the inline anti-FOUC
 * script at SSR and changing them post-hydration would create a mismatch.
 *
 * `forcedTheme` is the headline use case — App Router users toggle it per
 * route group (e.g. always-dark marketing pages, always-light dashboards).
 */
interface UpdatableStoreOptions {
    forcedTheme?: string | null;
    followSystem?: boolean;
    value?: Record<string, string> | null;
    themeColor?: string | Record<string, string> | null;
    transition?: TransitionConfig;
    onChange?: (theme: string, resolvedTheme: string) => void;
    disableTransitionOnChange?: boolean | string;
    respectReducedMotion?: boolean;
}
interface ThemeStore {
    getState: () => ThemeState;
    /**
     * Stable seeded state for SSR / the hydration render. Pass to
     * `useSyncExternalStore`'s third argument so the server render reflects the
     * cookie-seeded theme rather than an empty placeholder.
     */
    getServerSnapshot: () => ThemeState;
    subscribe: (l: Listener) => () => void;
    setTheme: (theme: SetThemeAction, options?: SetThemeOptions) => void;
    /** Start side-effect subscriptions (system/storage). Idempotent. */
    mount: () => void;
    /** Tear down subscriptions. */
    unmount: () => void;
    /** Sync runtime-mutable provider props into the store. */
    update: (opts: UpdatableStoreOptions) => void;
}

/**
 * The React context that carries a {@link ThemeStore} down the tree.
 *
 * `null` means "no provider above me" — `useTheme()` treats that as the inert
 * state rather than throwing, so a component rendered outside a provider (an
 * `error.tsx` above the boundary, a portal, a parallel-route slot) degrades
 * instead of crashing.
 */
type ThemeContext = ReturnType<typeof createThemeContext>;
/**
 * Mint a fresh, independent theme context.
 *
 * Why this exists: every hook and component used to read one module-level
 * context singleton. That is fine for the common case — one `ThemeProvider` at
 * the root — but it made two independently-created typed theme APIs collide.
 * Calling `createThemes()` twice (say a `createThemes(['light','dark'])` for the
 * app shell and a `createThemes(['a','b','c'])` for an embedded widget) produced
 * two providers writing into, and two hook sets reading from, the *same*
 * context. Whichever provider was nearest in the tree won, silently, for both
 * APIs — so the widget's `useTheme()` could report the shell's themes.
 *
 * Each `createThemes()` call now gets its own context, so the two are properly
 * isolated and can even be nested.
 */
declare function createThemeContext(): react.Context<ThemeStore | null>;

export type { ThemeContext as T, ThemeStore as a };