Who is using it

[adityareddy-dev]

If you have react-inp-blame on an app, even just in dev, I'd like to hear about it. A line is enough: what the app is, which React and framework, and whether the blame it gave you was right.

The wrong ones are more useful to me than the right ones though. If it named the wrong component or called a handler a render, open an issue with the report (the "Wrong or missing blame" form asks for it) and link it here.

I'll keep a list of named users in the README once there are some, only with your say-so.

[morteza-front-end]

Attribution accuracy on hydration-blocking and selectively-hydrated routes (0.25.0, Next 15.5 dev) — waiting blame leaves the concurrent culprit unnamed
Testing react-inp-blame@0.25.0 on Next.js 15.5 (dev build, React 19, StrictMode, Chromium, install() from instrumentation-client.ts with a pathname gate, overlay: true, debugGlobal: true) against two synthetic routes: a monolith page that blocks the main thread ~2 s inside a useState initializer while hydrating 8,000 state-bound cells, and a selectively-hydrated route where a Suspense/isolated action hydrates fast while a next/dynamic grid blocks ~320 ms on its own chunk.

On the monolith route the hydration-time click (9.1–9.7 s latency, 3.8 s input delay, 7/7 runs) is blamed exactly as it should be: kind: "hydration", name "the page", detail: "at least 5000 components, the rest not walked", confidence: "inferred", with the verdict splitting the 3,780 ms pre-handler wait from the 5,029 ms hydration render, and post-hydration cell clicks correctly name MetricCell or report measured painting time — zero false handler or component blames across 27 reports.

The gap I'd like to flag is on the selective route: taps that land while the unrelated Suspense subtree hydrates get blame: {"kind":"waiting","name":null,"detail":null,"ms":394,"confidence":"measured"} and a verdict ending "the main thread was busy with something else" — true, but the Long Animation Frames the report already joins carry the culprit (the hydration script and its dynamic-import invoker), so a waiting-kind blame that named the concurrent long task's invoker/source would turn an honest dead-end into an actionable answer on exactly the route shape (isolated hydration boundaries) where this library is most valuable.

Minor related observation: the pointerdown-entry reports of a gesture carry target: null while the click entry of the same gesture names the button. Environment: react-inp-blame 0.25.0, next 15.5.26, react/react-dom 19.0.0, Chrome (headless, real mouse input), development build. Full JSON.stringify(report) payloads available on request.

[adityareddy-dev]

Thanks for running this, the monolith numbers are good to see.

I rebuilt your selective route on 15.5.26 and React 19.0.0, a button in its own Suspense boundary and a next/dynamic grid whose render blocks 320 ms as its boundary hydrates, and got your waiting with a null name on all 28 taps that landed in it over 7 runs. Problem is the long animation frames over those waits list no scripts at all under webpack's dev build, so there's nothing in them to name. If yours was plain next dev, that's webpack on 15. Under next dev --turbopack the same page names the wait MessagePort.onmessage, React's own scheduler task. That's true, it doesn't say which boundary though. The commits can't say it either, cause in my run each tap's own update restarted the grid's render and none of those renders committed.

So for 1.0 it goes in the known limits, next to the one on webpack's dev frames. After 1.0 I'll have the wait say why it has no name. Naming the boundary React was hydrating is a bigger job for later.

The pointerdown target I couldn't reproduce on the selective route, every report I got was the click with the button on it. Could you send one of those pointerdown payloads and one of the waiting ones? And is it on an app of yours, or just the synthetic routes so far? If it's an app, are you ok being named as a user in the README?

[adityareddy-dev]

Thanks for this, the selective route case is exactly where I want the blame to do better. You're right that the LoAF join already has the culprit, when the verdict ends at waiting the overlapping frame's script attribution is sitting right there, so a waiting blame can carry the long task's invoker and sourceURL as the name with measured confidence, and for a next/dynamic chunk the invoker is a usable proxy for which boundary was hydrating. That's the plan for 0.26, waiting stops being a dead end when the frame knows who it was.

The pointerdown target null while click names the button is a real gap too, I'll chase it with the entries from your runs.

Yes to the full payloads, and if the two synthetic routes can be shared as a repo they'd become regression fixtures more or less as-is. Either here or an issue works.