import * as React from 'react';
import React__default from 'react';
import { N as NajmMode, b as NajmDesignConfig } from './design-types-CJYLgxmw.js';
import { b as NTablePaginationLabels, N as NajmTranslate } from './paginationLabels-dZLSNxfo.js';
import * as class_variance_authority_types from 'class-variance-authority/types';
import { VariantProps } from 'class-variance-authority';
import { N as NIconSource } from './NIcon-D73-C51g.js';

/**
 * Accessible names and visible copy for the toolbar above the rows.
 *
 * Every field is optional and falls back to English, matching
 * `NTablePaginationLabels`. The settings menu is the motivating case: its
 * headings and view-mode options are the only chrome in a localized table that
 * a catalog could not previously reach, because they are built inside the kit
 * rather than supplied per column.
 */
interface NTableToolbarLabels {
    /** Accessible name of the settings trigger. Defaults to `"Table settings"`. */
    settings?: string;
    /** Heading above the view-mode group. Defaults to `"View"`. */
    view?: string;
    /** Heading above the column-visibility list. Defaults to `"Columns"`. */
    columns?: string;
    /** Visible name of the table view mode. Defaults to `"Table"`. */
    modeTable?: string;
    /** Visible name of the cards view mode. Defaults to `"Cards"`. */
    modeCards?: string;
    /** Visible name of the JSON view mode. Defaults to `"JSON"`. */
    modeJson?: string;
    /** Visible name of the files view mode. Defaults to `"Files"`. */
    modeFiles?: string;
    /**
     * Accessible name of one view-mode option, given its visible name. Defaults
     * to `` `${mode} view` ``.
     *
     * It must contain the visible name — voice control matches on what is on
     * screen — so a translation reorders around the mode rather than replacing it.
     */
    modeOption?: (mode: string) => string;
    /** Accessible name and tooltip of the mobile filters trigger. Defaults to `"Filters"`. */
    filters?: string;
    /** Accessible name of the filter row. Defaults to `"Table filters"`. */
    filterRegion?: string;
    /** The option that clears a select filter. Defaults to `"All"`. */
    allOption?: string;
    /** Accessible name of the add control when `addButtonText` is empty. Defaults to `"Create"`. */
    create?: string;
}

/**
 * Defaults every `NTable` beneath the provider inherits.
 *
 * Localized copy is the motivating case: an application with more than a couple
 * of tables should not repeat the same label bundle at every render site, and
 * an application with more than one locale should not have to remember to.
 */
interface NTableDefaults {
    paginationLabels?: NTablePaginationLabels;
    toolbarLabels?: NTableToolbarLabels;
}
/**
 * Supply table defaults to everything below.
 *
 * `value` is passed straight through, so memoize it in the caller — an inline
 * object literal rebuilds on every render of the shell and re-renders every
 * table beneath it. Most label fields are functions, so `useMemo` on the
 * translator is usually the whole job.
 */
declare function NTableDefaultsProvider({ children, value, }: {
    children: React__default.ReactNode;
    value: NTableDefaults;
}): React__default.JSX.Element;
declare function useNTableDefaults(): NTableDefaults;
/**
 * Per-key merge for the toolbar copy, on the same terms as
 * `useResolvedPaginationLabels`.
 */
declare function useResolvedToolbarLabels(own: NTableToolbarLabels | undefined): NTableToolbarLabels;

declare const badgeVariants: (props?: {
    variant?: "secondary" | "destructive" | "default" | "outline" | "success" | "warning";
} & class_variance_authority_types.ClassProp) => string;
declare const badgeColorVariants: (props?: {
    color?: "neutral" | "primary" | "accent" | "secondary" | "destructive" | "success" | "warning" | "info";
    look?: "solid" | "outline" | "soft" | "dash";
    size?: "sm" | "md" | "lg";
    shape?: "default" | "square" | "pill";
} & class_variance_authority_types.ClassProp) => string;
type BadgeVariantProps = VariantProps<typeof badgeVariants>;
type BadgeColorVariantProps = VariantProps<typeof badgeColorVariants>;
type BadgeColor = NonNullable<BadgeColorVariantProps["color"]>;
type BadgeLook = NonNullable<BadgeColorVariantProps["look"]>;
type BadgeDisplayLook = BadgeLook | "minimal" | "text";
type BadgeSize = NonNullable<BadgeColorVariantProps["size"]>;
type BadgeShape = NonNullable<BadgeColorVariantProps["shape"]>;
type BadgeVariant = NonNullable<BadgeVariantProps["variant"]>;
type BadgeIcon = NIconSource;
type BadgeProps = React.ComponentProps<"span"> & {
    asChild?: boolean;
    variant?: BadgeVariantProps["variant"];
    status?: string;
    statusMap?: Record<string, BadgeColor>;
    label?: string;
    showIcon?: boolean;
    color?: BadgeColor;
    look?: BadgeDisplayLook;
    size?: BadgeSize;
    shape?: BadgeShape;
    icon?: BadgeIcon;
    iconMap?: Record<string, BadgeIcon>;
    iconPosition?: "left" | "right";
};
declare function Badge({ className, variant, status, statusMap, label, showIcon, color, look, size, shape, icon, iconMap, iconPosition, asChild, children, style, ...props }: BadgeProps): React.JSX.Element;
declare const NBadge: typeof Badge;
type NBadgeLook = BadgeDisplayLook;
type NBadgeProps = BadgeProps;

/**
 * Application-wide presentation policy for `<NBadge status="…" />`.
 *
 * This is the whole reason a project ends up with a `StatusBadge` wrapper: the
 * badge itself is already correct, but every call site has to repeat the same
 * look, the same shape, and the same translation lookup. Declared once on the
 * provider, none of that reaches a call site.
 *
 * What stays in the application: what it does *differently*. The packaged
 * vocabulary, its four-language labels, and the conventional `status.<token>`
 * catalog lookup already cover the common statuses, so `statusMap` and
 * `statusLabelKeys` are for the tokens and keys that are genuinely this
 * application’s own.
 */
interface NBadgeDefaults {
    look?: NBadgeLook;
    shape?: BadgeShape;
    size?: BadgeSize;
    showIcon?: boolean;
    /** Status token to badge color. Merged over the packaged vocabulary. */
    statusMap?: Record<string, BadgeColor>;
    /** Badge color to icon, used when `showIcon` is on. */
    iconMap?: Record<string, BadgeIcon>;
    /** Status token to finished label text. Wins over `statusLabelKeys`. */
    statusLabels?: Record<string, string>;
    /** Status token to catalog key, resolved through the provider's `t`. */
    statusLabelKeys?: Record<string, string>;
    /**
     * Catalog prefix for the conventional lookup. Defaults to `"status"`.
     *
     * Set it to `""` to switch the convention off entirely, for an application
     * whose catalog happens to hold an unrelated `status.*` branch.
     */
    statusKeyPrefix?: string;
}

/**
 * Optional literal labels, supplied as `feedbackDefaults.labels`. Each field
 * is independent: an application can localize one feedback label without
 * touching the others.
 *
 * `errorMessage` is the only key without a packaged fallback. A consumer that
 * supplies one opts a generic error state into rendering a body; absent that
 * opt-in, the no-provider behavior is unchanged.
 */
interface NFeedbackLabels {
    loadingLabel?: string;
    emptyTitle?: string;
    errorTitle?: string;
    errorMessage?: string;
    retryLabel?: string;
    forbiddenTitle?: string;
    forbiddenDescription?: string;
    notFoundTitle?: string;
    notFoundDescription?: string;
}
/**
 * Map from a feedback field to a translation catalog key. Resolved through the
 * provider's structural `t`. Optional per-field; a missing key falls through
 * to the literal default, then to packaged English.
 */
interface NFeedbackLabelKeys {
    loadingLabel?: string;
    emptyTitle?: string;
    errorTitle?: string;
    errorMessage?: string;
    retryLabel?: string;
    forbiddenTitle?: string;
    forbiddenDescription?: string;
    notFoundTitle?: string;
    notFoundDescription?: string;
}
/**
 * Provider-level defaults for the shared feedback components.
 *
 * Threaded through `NajmUIProvider.feedbackDefaults` and inherited by the
 * `next` and `app` adapters. No second adapter prop or translation source:
 * the same structural `t` every table and badge reads is what these labels
 * route through.
 */
interface NFeedbackDefaults {
    /**
     * Literal overrides. A field that is `undefined` here still resolves through
     * `labelKeys` and the packaged English fallback.
     */
    labels?: NFeedbackLabels;
    /**
     * Catalog keys resolved through the provider's `t`. Memoize the object: a
     * fresh identity on every render rebuilds the label bundle and re-renders
     * every feedback state beneath the provider.
     */
    labelKeys?: NFeedbackLabelKeys;
    /**
     * Catalog prefix for translated keys, read as `<prefix>.<field>` for every
     * field `labelKeys` does not name explicitly. Defaults to
     * `"common.feedback"`, so an application whose catalog follows the
     * convention supplies no `feedbackDefaults` at all.
     *
     * A prefix key the catalog does not answer falls through to packaged
     * English rather than rendering the key.
     */
    prefix?: string;
}
declare const DEFAULT_FEEDBACK_KEY_PREFIX = "common.feedback";
type DefaultFeedbackPrefix = typeof DEFAULT_FEEDBACK_KEY_PREFIX;
/**
 * The nine catalog keys the feedback states read under `Prefix`, matching the
 * `ToolbarKey` and `CardPaginationKey` conventions — same prefix, same
 * key-per-field naming.
 */
type FeedbackKey<Prefix extends string = DefaultFeedbackPrefix> = `${Prefix}.loadingLabel` | `${Prefix}.emptyTitle` | `${Prefix}.errorTitle` | `${Prefix}.errorMessage` | `${Prefix}.retryLabel` | `${Prefix}.forbiddenTitle` | `${Prefix}.forbiddenDescription` | `${Prefix}.notFoundTitle` | `${Prefix}.notFoundDescription`;

/**
 * Theme and time zone, the two preferences that outlive a render.
 *
 * Both are *uncontrolled*: the `initial*` props seed state the provider owns
 * from then on, and later changes to those props are ignored. That is the
 * shape the server hand-off wants — the page is rendered once against a cookie,
 * and every change after that originates here.
 *
 * Persistence is not this provider's business. It applies the change to the
 * document, then hands the new value to a callback the application supplies.
 * See `NajmNextUIProvider` in `najm-kit/next` for the cookie-endpoint wiring.
 */
interface NajmPreferencesContextValue {
    theme: NajmMode;
    setTheme: (theme: NajmMode) => Promise<void>;
    timeZone: string;
    setTimeZone: (timeZone: string) => Promise<void>;
}
declare const DEFAULT_TIME_ZONE = "UTC";
interface NajmPreferencesProviderProps {
    children: React.ReactNode;
    /** Seeds theme state; ignored after mount. Defaults to `"light"`. */
    initialTheme?: NajmMode;
    /** Seeds time zone state; ignored after mount. Defaults to `"UTC"`. */
    initialTimeZone?: string;
    /** Persist the new theme. Rejections propagate to the `setTheme` caller. */
    onThemeChange?: (theme: NajmMode) => void | Promise<void>;
    /** Persist the new time zone. Rejections propagate to `setTimeZone`. */
    onTimeZoneChange?: (timeZone: string) => void | Promise<void>;
    /**
     * Sanitize a time zone before it is stored.
     *
     * Defaults to an IANA check that falls back to `DEFAULT_TIME_ZONE`, which is
     * what every application wanted from the callback it used to have to supply.
     * Pass one to narrow further — a fixed set backing a picker, say.
     */
    normalizeTimeZone?: (value: string) => string;
}
/**
 * Standalone preferences, without the design and table layers.
 *
 * `NajmUIProvider` renders this internally, so most applications never name it.
 * It is exported for the case where something *above* the design layer needs to
 * read the theme — a runtime theme editor, typically, which owns the design
 * config and therefore has to sit above the provider consuming it. Hoisting
 * preferences out is then a reorder rather than a fork.
 */
declare function NajmPreferencesProvider({ children, initialTheme, initialTimeZone, onThemeChange, onTimeZoneChange, normalizeTimeZone, }: NajmPreferencesProviderProps): React.JSX.Element;
/**
 * Returns the context when one is mounted, or `null`.
 *
 * `NajmUIProvider` uses this to defer to an outer `NajmPreferencesProvider`
 * instead of shadowing it, so nesting the two is well-defined rather than
 * quietly producing two disagreeing themes.
 */
declare function useNajmPreferencesContext(): NajmPreferencesContextValue | null;
/** The live theme and a setter that persists through `onThemeChange`. */
declare function useNajmTheme(): Pick<NajmPreferencesContextValue, "theme" | "setTheme">;
/** The live time zone and a setter that persists through `onTimeZoneChange`. */
declare function useNajmTimeZone(): Pick<NajmPreferencesContextValue, "timeZone" | "setTimeZone">;

type NajmDirection = "ltr" | "rtl";
/**
 * The document's writing direction, kept in sync with the `dir` attribute.
 *
 * Radix reads direction from its own `DirectionProvider` and defaults to
 * `"ltr"`. It never consults the DOM, and it stamps that default onto every
 * portaled `Content` element — so in an application that sets
 * `<html dir="rtl">`, a dropdown or select popup renders LTR inside an
 * otherwise RTL page, and the logical padding and inset utilities on its items
 * resolve against the wrong side. Nothing bridged the two until this hook and
 * the `DirectionProvider` above it.
 *
 * Reading the attribute rather than a language preference is deliberate: `dir`
 * is what the browser itself lays out against, applications already set it, and
 * a kit that inferred direction from a locale list would disagree with the page
 * the moment an application supported a language the kit had not heard of.
 *
 * Server renders return `"ltr"` and the first client effect corrects it. That
 * is not a hydration risk for the popups, which mount only on open.
 */
declare function useDocumentDirection(override?: NajmDirection): NajmDirection;

interface NajmUIProviderProps extends Omit<NajmPreferencesProviderProps, "children"> {
    children: React.ReactNode;
    /**
     * The design config handed to `NajmDesignProvider`, owned by the application.
     *
     * Optional, and deliberately so: an application with no runtime theme editor
     * has nothing to put here, and requiring it was the only reason such an
     * application still had to author a provider file just to hold a constant.
     *
     * Prefer `initialDesign` for a theme editor. Passing `design` means the
     * application holds the draft state itself, which is the file this provider
     * exists to delete.
     */
    design?: NajmDesignConfig;
    /**
     * Seeds design state this provider owns from then on; ignored after mount.
     * A theme editor drives it through `useNajmDesignEditor`.
     */
    initialDesign?: NajmDesignConfig;
    /**
     * Forwarded to `NajmDesignProvider`, merged over a `min-h-full` default.
     *
     * The default is not decoration. `NajmThemeProvider` renders a real `div`
     * between the document body and the application, and a block box of
     * automatic height severs any `h-full` chain below it — every application
     * mounting this at the root was passing the same class back to repair that.
     * It is inert where it is not needed: a percentage `min-height` against an
     * auto-height parent imposes no constraint.
     *
     * Merged with `cn`, so a conflicting utility here still wins.
     */
    className?: string;
    /**
     * Translator for the pagination labels. Omit it and the packaged English
     * applies — the provider is still worth mounting for design and preferences.
     *
     * Memoize it. The labels are rebuilt whenever its identity changes, and
     * rebuilding them re-renders every table beneath.
     */
    t?: NajmTranslate;
    /**
     * The active language, for the packaged status-badge labels.
     *
     * Separate from `t` because those labels are the package's own, not the
     * application's catalog: `t` answers what the application calls a status,
     * this answers which language to fall back to when it calls it nothing.
     * `NajmKitProvider` supplies both from the i18n provider it mounts.
     */
    language?: string;
    /** Catalog prefix for the labels. Defaults to `"common.pagination"`. */
    paginationKeyPrefix?: string;
    /**
     * Catalog prefix for the table toolbar and settings menu. Defaults to
     * `"common.table"`.
     *
     * These labels are built inside the kit rather than supplied per column, so
     * this prefix is the only way a catalog reaches the view-mode options, the
     * column-visibility heading, and the filter controls' accessible names.
     */
    toolbarKeyPrefix?: string;
    /**
     * Writing direction for the Radix popups beneath — menus, selects, and the
     * rest of the portaled content.
     *
     * Omit it and the direction follows `<html dir>`, which is what an
     * application already sets and what the browser lays the page out against.
     * Radix defaults its own context to `"ltr"` and stamps that on every portaled
     * element, so without this bridge an RTL page gets LTR popups. Pass a value
     * only to pin one region against the document.
     */
    dir?: NajmDirection;
    /**
     * Per-key overrides layered over the translated labels. Memoize it, for the
     * same reason as `t`.
     */
    tableDefaults?: NTableDefaults;
    /**
     * Presentation policy for `<NBadge status="…" />`: the look, the shape, and
     * the map from the application's status tokens to its catalog keys.
     *
     * This is the prop that deletes a project's `StatusBadge` wrapper. Memoize it
     * for the same reason as `t`.
     */
    badgeDefaults?: NBadgeDefaults;
    /**
     * Defaults for the shared feedback state components — loading, empty, error,
     * forbidden, and not-found. Each label resolves through the provider's `t`
     * the same way pagination and badge labels do, so the same translator
     * reaches every state without a second bridge.
     *
     * Memoize the object: a fresh identity rebuilds the resolved bundle and
     * re-renders every feedback state beneath.
     */
    feedbackDefaults?: NFeedbackDefaults;
}
/**
 * The one provider a Najm application mounts for UI concerns.
 *
 * Composes three things that otherwise get copied between projects: theme and
 * time zone state with async persistence, a `NajmDesignProvider` fed the live
 * theme, and `NTable` pagination labels derived from the application's
 * translator.
 *
 * What it deliberately does not own: auth, react-query, and the translation
 * catalog. Those stay in the application — folding them in would make a UI
 * package depend on `najm-auth` and `@tanstack/react-query` and turn it into a
 * framework. Persistence is injected as callbacks so this entry imports
 * nothing from `next`; see `NajmNextUIProvider` in `najm-kit/next`.
 *
 * Rendering this under an existing `NajmPreferencesProvider` is supported: the
 * outer one wins and the preference props here are ignored. That is what lets
 * an application with a runtime theme editor hoist preferences above its
 * design context without forking this component.
 */
declare function NajmUIProvider({ children, design, initialDesign, className, t, language, paginationKeyPrefix, toolbarKeyPrefix, dir, tableDefaults, badgeDefaults, feedbackDefaults, initialTheme, initialTimeZone, onThemeChange, onTimeZoneChange, normalizeTimeZone, }: NajmUIProviderProps): React.JSX.Element;

export { useNajmPreferencesContext as A, type BadgeColor as B, useNajmTheme as C, DEFAULT_FEEDBACK_KEY_PREFIX as D, useNajmTimeZone as E, type FeedbackKey as F, useResolvedToolbarLabels as G, type NFeedbackDefaults as N, type NFeedbackLabelKeys as a, type NFeedbackLabels as b, type NajmUIProviderProps as c, type NTableToolbarLabels as d, type BadgeShape as e, Badge as f, type BadgeIcon as g, type BadgeLook as h, type BadgeProps as i, type BadgeSize as j, type BadgeVariant as k, DEFAULT_TIME_ZONE as l, NBadge as m, type NBadgeDefaults as n, type NBadgeLook as o, type NBadgeProps as p, type NTableDefaults as q, NTableDefaultsProvider as r, type NajmPreferencesContextValue as s, NajmPreferencesProvider as t, type NajmPreferencesProviderProps as u, NajmUIProvider as v, badgeColorVariants as w, badgeVariants as x, useDocumentDirection as y, useNTableDefaults as z };