You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #18 surfaces the names of changed props/state/hooks in profiling output (e.g. props: onClick, className), but not their actual values. Knowing that className changed is useful, but knowing it changed from "btn" to "btn active" would be far more actionable for debugging.
The React DevTools profiling protocol only sends key names — values are not included by design (to keep profiling lightweight).
During profiling, call inspectElement() after each commit for every component that changed. Store snapshots and diff consecutive ones to reconstruct before/after values.
Pro: Uses existing infrastructure — inspectElement already works over the DevTools WebSocket protocol
Con: inspectElement is async over WebSocket. Calling it for every changed component after every commit adds significant overhead and could slow profiling on busy apps
Con: "Before" values are approximated (previous snapshot), not true pre-commit values
Let the user specify components to watch during profiling (e.g. profile-watch @c5). Only snapshot those specific components after each commit, reducing overhead.
Pro: Practical performance trade-off — overhead scales with watched components, not total tree size
Pro: User explicitly opts in, so the cost is expected
Con: Requires knowing which components to watch upfront (could combine with a post-hoc "inspect the top offenders" step)
Option C: Direct fiber access (fragile, precise)
Inject custom code into the page that reads fiber.memoizedProps / fiber.pendingProps during onCommitFiberRoot to capture true before/after values at commit time.
Pro: Would give true before/after values with no async overhead
Con: Very fragile — fiber internals are not a public API and break across React versions
Con: Requires forking or monkey-patching React DevTools backend code
Problem
Issue #18 surfaces the names of changed props/state/hooks in profiling output (e.g.
props: onClick, className), but not their actual values. Knowing thatclassNamechanged is useful, but knowing it changed from"btn"to"btn active"would be far more actionable for debugging.The React DevTools profiling protocol only sends key names — values are not included by design (to keep profiling lightweight).
Possible approaches
Option A: Snapshot-based diffing (heavy, comprehensive)
During profiling, call
inspectElement()after each commit for every component that changed. Store snapshots and diff consecutive ones to reconstruct before/after values.inspectElementalready works over the DevTools WebSocket protocolinspectElementis async over WebSocket. Calling it for every changed component after every commit adds significant overhead and could slow profiling on busy appsOption B: Targeted watch mode (practical middle ground)
Let the user specify components to watch during profiling (e.g.
profile-watch @c5). Only snapshot those specific components after each commit, reducing overhead.Option C: Direct fiber access (fragile, precise)
Inject custom code into the page that reads
fiber.memoizedProps/fiber.pendingPropsduringonCommitFiberRootto capture true before/after values at commit time.Context
devtools-bridge.ts)inspectElement()can already fetch full props/state/hooks on demand (devtools-bridge.ts:103-126)recordChangeDescriptions: truewhich only enables key name tracking (devtools-bridge.ts:131)