Discussion data for community UIs
The Forum Post Generator creates fake discussion threads — question-style titles, body text, categories, vote and view counts, and nested replies. It is meant for prototyping community platforms and forum interfaces so you can build thread lists, detail pages and reply trees against realistic data before any backend exists.
How it works
You choose how many threads to create and a per-thread reply cap. For each thread the generator assembles a question-style title from verb and topic phrase pools, picks a category and author, and builds a two-to-four-sentence body from a pool of natural-sounding forum sentences. It then draws a random reply count between zero and your cap and builds that many reply objects, each with its own author, body and upvote tally. Upvotes, view counts and a low-probability pinned flag round out each thread, and a creation timestamp is placed within the last ninety days of a fixed base date.
A seeded pseudo-random source keeps a given configuration stable between renders while Regenerate advances the seed. The output is one object with a threads array; each thread carries its replies inline, so the structure mirrors a thread-with-replies API response and the replyCount field always matches the replies array length.
What the output looks like
Each thread object follows this shape:
{
"id": "thread-001",
"title": "How do I set up automated backups in the cloud?",
"category": "Infrastructure",
"author": "dev_marcus",
"body": "I've been trying to get a reliable backup schedule running...",
"upvotes": 42,
"views": 318,
"replyCount": 3,
"pinned": false,
"createdAt": "2024-09-12T14:23:00Z",
"replies": [
{
"id": "reply-001",
"author": "sysadmin_leo",
"body": "You'll want to look at scheduled jobs combined with...",
"upvotes": 17
}
]
}The replyCount always equals replies.length, which is a common API convention that most forum frontends expect and rely on for rendering the reply count badge without reading the full array.
Which UI states you can test
Because the generated data is varied and realistic, a single batch exercises several states at once:
| State | How the data covers it |
|---|---|
| Empty replies | Some threads get zero replies when cap is above zero |
| Pinned threads | Roughly one in ten threads has pinned: true |
| High engagement | Upvote and view counts vary widely so you can test sorting |
| Chronological ordering | ISO 8601 timestamps span the past ninety days |
| Paginated list | Raise thread count to fill multiple pages |
Practical tips
- Empty state testing. Set the reply cap to zero to generate a clean list of unanswered threads, ideal for testing an empty-state or a “no replies yet” placeholder.
- Pagination and scroll. Raise the thread count to twenty or thirty to stress-test pagination controls, virtual lists, and infinite-scroll logic on the forum index.
- Pinned thread UI. The
pinnedflag appears automatically on roughly one thread in ten, so you can build and verify pinned-thread highlighting without hand-editing any fixture. - Stable fixtures. Copy the JSON once, paste it into a static fixture file, and it will always produce the same data — useful for snapshot tests and design reviews where you need the same threads every time.