import { WixPatternsContainer } from './WixPatternsContainer';
import { TaskState } from './TaskState';
import { SetupWidgetData, SetupWidgetStep, SetupWidgetStepStatus } from '../model/setupWidget';
export interface SetupWidgetStateParams {
    readonly container: WixPatternsContainer;
    /** Consumer-supplied data resolver. The widget owns loading / error state. */
    readonly fetchData: () => Promise<SetupWidgetData>;
}
/**
 * State for the Setup widget, created via the `useSetupWidget` hook and passed
 * to the `SetupWidget` component (the same shape as `useCollection` →
 * `CollectionState`).
 *
 * Owns the async lifecycle via {@link TaskState}, seeds an observable copy of
 * the steps from the resolved {@link SetupWidgetData}, and exposes a public API to
 * read the steps and change a step's status.
 *
 * The consumer API is `steps`, `getStep`, `setStepStatus`, `refresh` and
 * `isRefreshing`. Underscore-prefixed members are internal to the
 * `@wix/patterns` rendering layer — not consumer API.
 *
 * Render-time concerns (how inline content is supplied, navigation handling)
 * stay in the cairo component — this class never imports from `@wix/patterns`,
 * preserving the upward dependency direction.
 */
export declare class SetupWidgetState {
    private readonly container;
    private readonly fetchData;
    /** @internal Read by the `SetupWidget` component for the page status mapping. */
    readonly _loadTask: TaskState<SetupWidgetData>;
    /** Mutable copy of the steps, seeded from `fetchData` and editable via the public API. */
    private seededSteps;
    private seededTitle?;
    /** The step the user explicitly expanded; `null` once explicitly collapsed. */
    private focusedStepId;
    /** Whether the user has interacted with inline expansion yet. */
    private userToggled;
    /** True while a `refresh()` is in flight (for an optional consumer indicator). */
    isRefreshing: boolean;
    /** The most recently issued `refresh()` fetch, for last-write-wins. */
    private latestRefresh?;
    constructor(params: SetupWidgetStateParams);
    init(): () => void;
    private load;
    /**
     * @internal Re-run the initial load after an error (shows the loading
     * skeleton again). Consumers receive this as the `retry` param of
     * `renderError`.
     */
    _retry(): void;
    /**
     * Re-fetch the data on demand and swap in the result — without flipping back
     * to the loading skeleton, so the current steps stay visible during the
     * refetch (mirrors `onDashboardWidgetDataChange` in dashboard-setup). Use this
     * to reflect status changes that happen outside the widget (a `navigate` step
     * finishing elsewhere, a real-time/server push). Discards local
     * `setStepStatus` edits in favour of the freshly fetched server truth. A
     * failed refresh keeps the current data (the error is reported, not surfaced).
     *
     * `refresh()` is not error recovery: it never touches the load task, so a
     * refresh after a failed initial load seeds data but leaves the error state
     * (and the component's error UI) up. Error recovery is {@link _retry} —
     * surfaced to consumers as the `retry` param of `renderError`.
     */
    refresh(): Promise<void>;
    private onError;
    private seedFromData;
    get steps(): SetupWidgetStep[];
    getStep(id: string): SetupWidgetStep | undefined;
    /** @internal */
    get _title(): string | null | undefined;
    /** @internal */
    get _isLoading(): boolean;
    /** @internal */
    get _isError(): boolean;
    /**
     * @internal Steps flattened to their leaves — an aggregated step (with
     * `steps`) is replaced by its sub-steps. Progress is measured over the
     * leaves so a group counts as its child steps, not as one row (matches
     * dashboard-setup).
     */
    get _leafSteps(): SetupWidgetStep[];
    /** @internal */
    get _completedCount(): number;
    /** @internal */
    get _totalCount(): number;
    /** @internal */
    get _progressPercentage(): number;
    /** @internal */
    get _isAllComplete(): boolean;
    /**
     * @internal The recommended next step — highlighted as "focused" and given
     * the primary CTA. Derived, never pinned by the data (matches
     * dashboard-setup's client-side focus): the first upcoming step, then the
     * first step that isn't already done or disabled.
     */
    get _primaryStepId(): string | null;
    /**
     * @internal The step whose inline content is currently expanded
     * (single-open). Until the user interacts, defaults to the primary step when
     * its content is inline — mirroring `isFocused && isExtensionStep` in
     * dashboard-setup.
     */
    get _expandedStepId(): string | null;
    /**
     * @internal The single focused (highlighted) step. Production keeps focus and
     * inline-expansion unified in one `focusedStepId`, so only ever one step is
     * highlighted; here `_primaryStepId` (recommended next) and `_expandedStepId`
     * (what the user toggled open) are separate, and can diverge once the user
     * opens a non-primary inline step. Collapsing them to a single id — the
     * expanded step when one is open, otherwise the primary — preserves the
     * single-focus invariant (avoids highlighting both the primary and the
     * expanded row).
     */
    get _focusedStepId(): string | null;
    /**
     * Change a step's status (e.g. mark it completed after the consumer flow
     * finishes). Works for top-level steps and for sub-steps of an aggregated
     * group, so a group's counter + the leaf progress stay in sync.
     */
    setStepStatus(id: string, status: SetupWidgetStepStatus): void;
    /** @internal Toggle a step's inline expansion (single-open). */
    _toggleStep(id: string): void;
}
//# sourceMappingURL=SetupWidgetState.d.ts.map