33 lines
1.5 KiB
TypeScript
33 lines
1.5 KiB
TypeScript
import type { BlockComponentMap, BlockData, EnhanceProps } from './types.js';
|
|
export type RenderBlocksProps = {
|
|
/** Block data array from a Payload document (e.g. page.layout). */
|
|
blocks: BlockData[] | null | undefined;
|
|
/** Client-provided map of blockType → component. */
|
|
components: BlockComponentMap;
|
|
/**
|
|
* Optional client hook to inject block-specific props (nav anchors, etc.).
|
|
* Keeps the engine generic — the plugin knows no concrete block types.
|
|
*/
|
|
enhanceProps?: EnhanceProps;
|
|
};
|
|
/**
|
|
* Generic, server-side block renderer.
|
|
*
|
|
* Iterates a document's blocks and renders each via the client's component
|
|
* map. Unknown blocks are skipped (null), never thrown. Block-specific logic is
|
|
* delegated to the client's optional `enhanceProps` — the plugin itself is
|
|
* block-agnostic.
|
|
*
|
|
* The client owns components and block schemas (they pass `components` and
|
|
* define blocks in their config); the plugin owns only the iteration and
|
|
* wiring. No wrapper markup is added — spacing/layout belong to the client's
|
|
* components.
|
|
*
|
|
* Nested blocks: a block that needs to render child blocks should render its
|
|
* own <RenderBlocks> and import the registry itself, rather than receiving the
|
|
* component map as a prop. Passing the map as a prop breaks React Server
|
|
* Components — functions (client components) can't cross the server→client
|
|
* boundary via props.
|
|
*/
|
|
export declare function RenderBlocks({ blocks, components, enhanceProps }: RenderBlocksProps): import("react/jsx-runtime").JSX.Element | null;
|