Rendering Standard Site documents

Overview

A publication body can arrive in many formats — Leaflet, Pckt, Offprint, and a long tail of third-party block and markdown formats. These packages parse all of them and render each block with your components. They ship no styles and no design system: the defaults are the barest semantic HTML, and every component is overridable.

All the format-specific work happens once, in a framework-agnostic core that normalizes every format into one block vocabulary. Each framework renderer is a thin walk over that shared tree, so the same mental model — one document input, one components map — transfers between frameworks.

Packages

Pick the package for your framework; all sit on the same core. Install instructions, the full props reference, and framework-specific usage examples live in each package's README on npm.

• @standard-reader/renderer-react — React (this is what Standard Reader itself uses).
• @standard-reader/renderer-vue — Vue 3.
• @standard-reader/renderer-solid — SolidJS.
• @standard-reader/renderer-svelte — Svelte 5.
• @standard-reader/renderer-lit — Lit / web components.
• @standard-reader/renderer-angular — Angular.

Customizing components

Every renderer takes one input for the document — the content payload of a site.standard.document — and an optional components map. The format is detected from the payload's $type. With no components prop, a document renders as unstyled semantic HTML.

The components map is a partial override — anything you omit uses the unstyled default. It comes in two categories:

Shared components render the block and inline vocabulary that every format has in common — paragraphs, headings, images, code, lists, tables, and the inline marks (bold, links, mentions, footnotes). Override one and it applies across every format.

Platform components render the blocks unique to one publishing platform — a Leaflet poll or signup, a Pckt gallery or note embed, an Offprint component. These are the interactive, often data-backed embeds; the headless defaults render nothing, so you supply your own to make them live.

The exact override mechanism is idiomatic per framework — a components object of functions in React, Vue and Solid, lit-html templates in Lit, snippets in Svelte, or <ng-template> refs in Angular — but the split and the vocabulary are the same everywhere. See each package's README on npm for the framework-specific shape and worked examples.

Resolving platform data

The platform components — and the inline mention and link components — hand you AT-URIs and DIDs to resolve to records and identities yourself. A hosted AT Protocol data service like microcosm works great for many of them: Slingshot for record and identity resolution, and Constellation for network-wide backlinks and interaction counts (poll tallies, reply counts, who-embedded-this).

The core, and new frameworks

You usually depend on a framework renderer, not the core directly. But @standard-reader/renderer-core is public: reach for it to inspect or transform a document without rendering it, or to build a renderer for a framework not listed above. A renderer is just a walk over its normalized tree — map each block type to your framework's primitive, and run text through the core's inline segmenter to render marks, links, mentions and footnote references. The existing renderers are the reference implementations; the API is documented in the @standard-reader/renderer-core README on npm.