Proposal: a read-only Drawnix Viewer for AI-generated content

[pubuzhixing8]

Summary

As a focused first step for the Drawnix AI direction discussed in #256, I propose adding a lightweight read-only Drawnix component dedicated to displaying AI-generated content.

The component should render Drawnix data without exposing editing entry points. It would give AI agents a safe and predictable visual output surface before we introduce more complex AI editing workflows.

Motivation

AI integrations need a small component that can:

• render structured Drawnix output inside chat, MCP Apps, coding tools, documentation, and other products;
• preserve native mind maps, flowcharts, freehand strokes, images, and rich text as real Drawnix elements;
• avoid showing toolbars, context menus, creation shortcuts, text editing, or other irrelevant editing affordances;
• provide a stable rendering contract that future AI generation and editing capabilities can build on.

Drawnix already has useful foundations for this. The Plait board supports read-only mode, and the Mermaid/Markdown preview uses a read-only board today. The main Drawnix component currently fixes readonly to false, so the Viewer should reuse the existing renderer and plugins rather than create a second rendering implementation.

Proposed MVP

Introduce a DrawnixViewer component, either exported from @drawnix/drawnix or published as a small dedicated package.

<DrawnixViewer
  value={elements}
  viewport={viewport}
  theme={theme}
  fitToContent
/>

The MVP should:

• render the element families already supported by Drawnix;
• run the board in strict read-only mode;
• hide all editing UI and editing entry points;
• disable element creation, deletion, movement, resize, rotation, text editing, clipboard mutations, and editing hotkeys;
• optionally allow viewport-only interaction such as pan, zoom, and fit-to-content;
• support light and dark themes and responsive containers;
• fail gracefully when AI output contains invalid or unsupported elements;
• avoid mutating the input value;
• reuse the same rendering plugins and visual behavior as the full Drawnix editor.

Initial AI use cases

1. An MCP tool returns a Drawnix artifact that is rendered directly in the host UI.
2. A coding agent displays an editable-format architecture diagram without opening the full editor.
3. Documentation, issues, and pull requests embed a live Drawnix preview.
4. Users review an AI-generated diagram before a later workflow hands it to the full editor.

Non-goals for the first version

• AI model or chat integration inside Drawnix;
• editing AI-generated results;
• collaboration or persistence;
• account, storage, or sharing features;
• a separate rendering engine;
• image generation.

Acceptance criteria

• The Viewer exposes no editing entry point.
• Attempts to edit do not change the supplied Drawnix data.
• Mind maps, flowcharts, text, images, and freehand content render consistently with the editor.
• Pan, zoom, and fit-to-content behavior is explicitly configurable.
• Unit tests cover read-only behavior and input immutability.
• A small demo shows AI-generated Drawnix JSON rendered by the Viewer.

Open questions

1. Should this be DrawnixViewer in @drawnix/drawnix, or a separate @drawnix/viewer package?
2. Should the input accept only PlaitElement[], or the complete versioned .drawnix document?
3. Should pan and zoom be enabled by default, or should the default be fully static?
4. What validation and fallback UI should be used for partially invalid AI output?

If the direction is accepted, the implementation can stay intentionally small and become the first stable presentation surface for the broader Drawnix + AI roadmap.