Long-content / overflow stress images

A frontend engineer needs this when checking a layout holds up. The card or list already works on the happy path. You want to see what happens with pathologically long strings, huge numbers, and empty values, without editing the source and without committing that hostile data as the default.

This is one run, on purpose, before or during the PR that fixes the overflow. The person doing it already owns the component. They should not leave the long strings in the default data file.

The job is one PNG at the component’s normal size, for pasting into the PR that fixes the overflow. You wrap the real card or list in an artboard. You pass stress.json as --data for one run. Nothing about the source changes. The stress values apply to the run only.

Give Lerret a React component under .lerret/ and a data file. export writes a PNG. Same component, hostile data, one flag.

The component is any real card or list component wrapped in an artboard. There is no second stress component. The artboard is the same one you already export. The data is what gets hostile.

Data is a stress.json with pathologically long strings, huge numbers, and empty values, passed as --data for one run. This is the first of the four bulk patterns: re-run export with a different --data file. Same component, new values, new image. --data applies to every artboard in the run and is never written back into .lerret/, so the stress file cannot become the committed default. There is no batch product, no queue, no orchestrator.

The image is a PNG at the component’s normal size, for pasting into the PR that fixes the overflow.

Same component, hostile data, one flag. Nothing about the source changes, so the stress run cannot accidentally get committed as the default. A design file with a long-string frame is a second layout someone has to keep in sync. You use Lerret because the overflow picture is a run, and the source stays clean.

npx @lerret/cli@latest export --data stress.json

Start a project with npx create-lerret@latest. More in the use cases index.