Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

A/B Testing Comments Block for React Aria

Two comment boxes you can try, the composer above the thread or at its foot, with typed users and replies per variant and a z-test verdict that flips when you post.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Try the two layouts an experiment compares, with this test panel for React with React Aria. A compact header names the question. The frame has two cells on shared hairlines: variant A puts the composer above a short thread, variant B puts it at the foot, and each is a small live composer with a Field, a Textarea and a Post button that says what is wrong in a held line (empty, or too few words). Under them, a result band shows users, replies and reply rate for each variant, with a Progress bar, and a verdict from a two-proportion z-test: "B ahead by 24%, likely real" when the score passes 1.96, or "Too early to call". Every reply you post counts in its variant, so the verdict can flip. The one primary, Ship B, is a Shine Button that stays unavailable until B is clearly ahead and then only sets a local line. It is built from Field, Textarea, Progress, Shine Button, Button, Avatar, Badge and Guides, with a CSS entrance only. For product teams reviewing a comment box experiment.

FAQ

How do I use my own numbers?

Edit VARIANTS: each has its users, the replies it has before anyone posts, a note and the two comments in its thread. zOf pools the two rates and divides the difference by the standard error; NEEDED is 1.96, the score for 95% two-sided. Replace both with your analytics query, and keep the test on the server if the numbers are large.

Why does one reply flip the verdict?

The demo numbers are tuned so B starts just under the line (about 1.90 against 1.96) and one extra reply in B crosses it. That is the point of the block: you see how the verdict depends on counts. A real experiment should fix its sample size in advance and not stop the moment the score passes the line.

What does Ship B do?

Nothing leaves the page. While the verdict is not reached, the button stays in place and answers "Not yet" when pressed. Once B is ahead, it sets a local line saying B is the default. Posting again resets that line, because the numbers changed. Start over puts every number back.

What stays local?

Your posts, the tallies they change, the verdict and the shipped line. To make it real, record which variant each visitor saw, count a reply against that variant on the server, compute the test from stored counts and have Ship B change a feature flag.

Is it accessible?

Each variant's thread is a labelled scroll region, each composer has a hidden label naming its variant, and problems are announced through the field. Counts and the verdict are text, the bars are decoration, and a polite status line reports every post with the new verdict.

How does it look on a phone?

The two variants stack, A then B, each keeping its own composer. The result figures sit in three columns per variant, and the verdict and buttons stack at full width.