added /dist

dist/modules/blocks/RenderBlocks.d.ts

@@ -0,0 +1,32 @@
+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;