ReactSnap stays intentionally narrow: it turns a React component or DOM node into exportable browser output. The architecture keeps that promise focused so the rendering layer can improve without pretending to be a full design editor.
Current rendering flow#
DOM node
-> choose strategy
-> clone / prepare subtree
-> html-in-canvas OR foreignObject path
-> draw to canvas
-> export Blob / string output
For raster output the current strategy model is:
autohtml-in-canvasforeign-object
Package boundaries#
@reactsnap/core#
The core package owns rendering primitives, strategy resolution, and browser-side output helpers such as renderToPng, renderToJpeg, renderToWebp, and supportsHtmlInCanvas().
@reactsnap/react#
The React package wraps the core renderer in useReactSnap(), which is the ergonomic entry point for export buttons inside normal React views.
@reactsnap/svg#
The SVG package exposes renderToSvg() and clarifies the current distinction between foreignObject output and future raster-style SVG modes.
@reactsnap/pdf#
The PDF package is still a scaffold. The public package exists so the API surface can stabilize, but the site should clearly say the real PDF backend is still upcoming.
Why this matters for the website#
The /reactsnap section on SniCap should not read like generic package docs. It should help developers understand where the renderer is mature, where it is experimental, and how those outputs connect to the broader SniCap workflow after capture.
Current product boundary#
ReactSnap does not try to become:
- a canvas editor
- a whiteboard
- a template marketplace
- a remote browser farm UI
That narrow boundary is part of the value. SniCap can own screenshot editing and delivery while ReactSnap owns the browser-side render/export layer.