Architecture

ObjectDocs is built on a strict Separation of Concerns philosophy, completely separating the presentation, configuration, and content layers.

Core Principles

1. Configuration as Code

Unlike traditional documentation sites where structure is hardcoded in React components, ObjectDocs treats documentation organization as data.

2. Localized Content Management

Each documentation directory is self-contained. If you want to add a new section, just create files in that directory and update the sibling meta.json. This makes multi-person collaboration in large teams less prone to conflicts.

Directory Structure

A standard ObjectDocs project structure looks like this:

.
├── content/               # [Data Layer] Raw Content
│   ├── docs.site.json     # Global settings (Nav, Logo, Branding)
│   └── docs/
│       ├── meta.json      # Directory structure & sorting control
│       └── index.mdx      # Documentation content
├── package.json
└── public/                # Static assets (images, etc.)

Data Flow

1. Build Time: @objectdocs/site reads all MDX and JSON files under content/.
2. Parsing: The Fumadocs engine parses metadata and builds the navigation tree.
3. Rendering: Next.js (App Router) renders content as React Server Components.
4. Interaction: Client components (like <Cards>, <Steps>) activate in the browser.

Why Design It This Way?

This architecture allows us to:

• Multi-Product Support: By switching different content directories, multiple product documentations can be supported within the same codebase.
• Low-Code Integration: Since content is separated from UI, we can more easily inject dynamic low-code component demos.