/**
 * Composing props from several sources.
 *
 * Forwarding a component's leftover props onto its root element is plain JS —
 * `const { color, ...rest } = ctx.props` then `<button {...rest} />`. What
 * plain JS cannot do is *combine* two sources: a JSX spread is lowered by the
 * compiler into a single object literal before the runtime sees anything, so
 * `<button {...rest} {...bag} />` lets later keys clobber earlier ones. If the
 * consumer and the component both set `class`, one is lost; same for
 * `onClick`; and `onClick` vs `onclick` land in the same DOM listener slot.
 *
 * No runtime change can recover what the compiler already discarded, which is
 * why this one function exists.
 */
/** A source of props: an object, a thunk returning one, or nothing. */
export type MergeSource = Record<string, any> | (() => Record<string, any>) | null | undefined;
/**
 * Merge several prop sources into one.
 *
 * Ordinary keys follow **exact JS spread semantics**: the last source with the
 * key as an own key wins, including when its value is an explicit `undefined`.
 * This replaces a `{...a, ...b}` spread, so it must behave like one — it is
 * deliberately *not* a defaults helper (destructuring with defaults already
 * covers that).
 *
 * Four kinds of key are combined rather than overwritten:
 *
 * - **`class` / `className`** — concatenated in argument order, non-empty
 *   values only, emitted as `class`.
 * - **`style`** — merged left-to-right into an object; string sources are
 *   parsed first. An object beats a string downstream: `patchProp` diffs it
 *   per property and handles custom properties, and SSR stringifies it.
 * - **`on*` handlers** — chained in source order, and grouped by the event
 *   they resolve to, so `onClick` and `onclick` become **one** entry under the
 *   first spelling seen. Two keys can then never reach the same invoker slot.
 * - **`ref`** — chained into one ref that feeds every source's ref.
 *
 * Chaining cannot express *swallow*: a component that gates a consumer handler
 * (dropping `onClick` while disabled) must keep destructuring it out and
 * calling it itself.
 *
 * @example Hoist the call into setup — see the note on identity below.
 * ```tsx
 * const merged = mergeProps(
 *     () => { const { variant: _v, ...rest } = ctx.props; return rest; },
 *     () => ({ class: 'btn', onClick: onActivate })
 * );
 * return () => <button {...merged}>{slots.default?.()}</button>;
 * ```
 *
 * The returned object resolves on read, so thunk sources stay reactive: a
 * render that spreads it reads through to `ctx.props` and tracks as usual.
 * Calling `mergeProps` **once in setup** also keeps the derived `ref` and
 * chained handlers identity-stable across renders — rebuilding them per render
 * hands the renderer a fresh function every time, which makes it tear down and
 * re-apply refs for no reason.
 */
export declare function mergeProps(...sources: MergeSource[]): Record<string, any>;
//# sourceMappingURL=props.d.ts.map