# Manifest

A custom view declares its required data sources in `custom_blocks.json` at the project root. Notion uses the manifest to know what semantic keys the block expects, what shape each property should be, and what to show when an admin is configuring the block.

```json
{
  "version": 1,
  "dataSources": {
    "tasks": {
      "name": "Tasks",
      "description": "The collection of tasks to render",
      "properties": {
        "title": { "name": "Title", "type": "title" },
        "dueDate": { "name": "Due date", "type": "date" }
      }
    }
  }
}
```

`initCustomBlock()` fetches `custom_blocks.json` and forwards it with `ready`. The `notionCustomBlock()` Vite plugin from `ncblock/vite` serves it in dev and emits it into `dist/` on build. If the file is missing, the SDK sends `ready` with `status: "success"` and `manifest: null`, which means the block has no declared data requirements. If the file is unavailable for another reason or invalid, the SDK sends `ready` with `status: "error"` and an `error` payload, and hosts should reject init by echoing the sandbox-reported error code back.

## Vite plugin

```ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { notionCustomBlock } from "ncblock/vite";

export default defineConfig({
  plugins: [react(), notionCustomBlock()],
});
```

In dev, the plugin serves `custom_blocks.json` from the project root so HMR + the SDK handshake see the same file. On `vite build`, it emits `custom_blocks.json` into `dist/` as a separate asset alongside the bundled HTML and JS.

## Types

- `CustomBlockManifest` — the parsed shape of `custom_blocks.json`.
- `ManifestDataSource` — a single entry in `dataSources` (name, description, properties).
- `ManifestProperty` — a single property declaration inside a `ManifestDataSource`.
- `ManifestIcon` — the icon variant accepted on a `ManifestDataSource`.