import { Ref } from 'react';
export type RenderProp = React.ReactElement<React.PropsWithChildren<{
    className?: string;
    style?: React.CSSProperties;
    ref?: Ref<unknown>;
}>>;
export type RenderWithPropsOptions = {
    render?: RenderProp;
    children?: React.ReactNode;
    props: Record<string, unknown>;
    fallbackElement?: keyof React.JSX.IntrinsicElements;
};
/**
 * Unwraps a `render` element that arrives wrapped in a lazy node.
 *
 * An element a server component passes to a client one, such as
 * `render={<Link href="/x" />}`, can reach server rendering in development as a
 * lazy reference instead of an element. `isValidElement` rejects it there, so
 * the server takes a fallback branch while the browser, which gets the plain
 * element, takes the real one, and the two disagree at hydration.
 *
 * `Children.toArray` unwraps lazy nodes the way React does when it renders one:
 * a pending payload throws its thenable and suspends, and a rejected one throws
 * its error, so both behave as they would have without this. Base UI's
 * `useRender` uses the same workaround. Delete it once
 * https://github.com/facebook/react/issues/32392 is fixed.
 */
export declare const resolveRender: <T>(render: T) => T;
/**
 * Utility function to handle render prop logic with prop merging, className merging, and style merging.
 * This abstracts the common pattern of cloning elements with merged props.
 *
 * Event handlers present on both sides are chained rather than overwritten —
 * see {@link chainEventHandlers} — and refs are composed, since `cloneElement`
 * would otherwise replace the render element's ref with ours. Both match what
 * `@radix-ui/react-slot` provides upstream. Everything else follows
 * `cloneElement`: `props` wins over the render element's own, with `className`
 * concatenated and `style` merged.
 */
export declare const renderWithProps: ({ render, children, props, fallbackElement, }: RenderWithPropsOptions) => React.ReactElement;
//# sourceMappingURL=render.d.ts.map