The piece that makes the above practical: a small sample-data module that everything can depend on and that depends on nothing.
One module, no dependencies, containing realistic instances of your model types — a few users, a few items, an empty case, a case with unreasonably long text, an error. Feature modules depend on it in previews and in tests.
Why it is worth its own module rather than scattering fixtures around: it stops sample data from being defined next to the real data layer, which is how a preview ends up dragging the networking module in through the back door. It also means the sample data is shared, so everyone previews against the same awkward cases and somebody's long-name bug gets caught by someone else's screen.
Two practical notes:
Do not ship it. Keep it out of release builds so it does not add size, and so nobody accidentally uses a fixture in production code.
Include the ugly cases deliberately. The value is in previewing the states that break layouts. Sample data that is all short, tidy strings gives you previews that always look fine and an app that does not.
Once this exists, the fix in the previous answer becomes about ten minutes per screen instead of a refactor, which is what makes it actually happen.