react-inspector

react-inspector brings the look and behavior of Chrome DevTools’ inspector panels directly into a React application. It ships three composable components — <ObjectInspector> for tree views of arbitrary JavaScript values (a glorified, expandable JSON.stringify), <TableInspector> for console.table-style tabular views, and <DOMInspector> for inspecting live DOM nodes — plus a top-level <Inspector> shorthand that picks the right one automatically based on the data passed in.

Under the hood, every inspector is built on a shared TreeView/TreeNode primitive that tracks expanded-path state via React context, so expansion state survives node unmount/remount (useful for live-updating props/state views during hot reloading). Rendering is customizable through a nodeRenderer prop, and appearance is themeable via a theme prop that accepts either a preset (chromeLight, chromeDark) or a fully custom theme object.

The library has no runtime dependencies beyond is-dom and lists react only as a peer dependency, making it lightweight to add to an existing app. It’s best known as the object/state inspector embedded inside Storybook (the project now lives under the storybookjs GitHub org), but works standalone in any React 18/19 app for building custom debugging panels, log viewers, or admin/data-explorer UIs.

What You Get

• <ObjectInspector> — an expandable tree view of any JS value, functionally equivalent to a foldable JSON.stringify(data, null, 2), with path-based persistent expansion state
• <TableInspector> — a console.table-equivalent grid view for arrays and objects, with configurable columns
• <DOMInspector> — inspects live DOM nodes the way Chrome DevTools’ Elements panel does
• <Inspector> shorthand that auto-selects the right inspector based on whether the data is a table flag or a DOM node
• Built-in chromeLight / chromeDark themes plus a fully custom theme object API
• A nodeRenderer override prop for fully custom per-node rendering

Common Use Cases

• Embedding a live props/state inspector inside a component for debugging during development
• Building custom devtools panels or browser extensions that need DevTools-style object trees
• Rendering structured API responses or logs in an internal admin tool
• Powering Storybook’s own object/state inspection addon

Under The Hood

Architecture The library is organized around a single shared tree-rendering primitive: src/tree-view/TreeView.tsx renders a recursive ConnectedTreeNode that reads/writes per-path expansion state through ExpandedPathsContext (React context + useState), so expanded state is keyed by a JSONPath-like string (pathUtils.ts) rather than by component identity — this is what lets expansion survive remounts during hot reloading. ObjectInspector, TableInspector, and DOMInspector (in their own src/object-inspector, src/table-inspector, src/dom-inspector directories) each supply TreeView with a dataIterator generator function and a nodeRenderer, rather than reimplementing traversal themselves — ObjectInspector’s iterator in particular handles arrays, Symbol.iterator-based iterables, and non-enumerable/__proto__ properties as distinct cases. The top-level <Inspector> in src/index.tsx is a thin dispatcher that picks TableInspector or DOMInspector (via an is-dom check) or falls back to ObjectInspector. Theming is layered on separately via a themeAcceptor higher-order component and a useStyles hook reading from src/styles/themes, decoupling visual styling from the tree logic.

Tech Stack Written in TypeScript (~64% of source, the remainder JavaScript in spec files), targeting React 18/19 as a peer dependency only — the package itself has effectively zero runtime dependencies (is-dom is the sole hard dependency). Built with tsup into dual CJS/ESM output (dist/index.cjs / dist/index.js) with generated .d.ts types. Development tooling is Storybook 9 (used both for local component development and as the published demo/docs site via Chromatic), Vitest + @testing-library/react + happy-dom for tests, and Yarn 4 (Berry) as the package manager. Releases are automated via the auto tool.

Code Quality Unit tests exist for the core pieces — ObjectInspector, ObjectName, ObjectValue, and the pathUtils/getHeaders helper modules all have .spec.jsx files with accompanying Jest/Vitest snapshot fixtures (__snapshots__/), giving reasonable coverage of the traversal and rendering logic even though the top-level TreeView, DOMInspector, and theming code are not directly tested. ESLint (flat config, typescript-eslint + eslint-plugin-prettier + eslint-plugin-storybook) and Prettier are wired up and enforced, and GitHub Actions runs a dedicated unit-test workflow on push. Type safety is present but not strict — many internal props are typed any (with @typescript-eslint/no-explicit-any explicitly disabled in the lint config as legacy debt), so the public API surface has partial rather than end-to-end type coverage.

What Makes It Unique Rather than a generic “pretty-print JSON” component, it specifically mirrors Chrome DevTools’ three distinct inspection surfaces (object tree, table, DOM elements) with matching visual conventions and behavior, and does so with a path-keyed expansion model that survives component remounts — a detail that matters for hot-reload-driven debugging workflows and is why it was adopted as Storybook’s own state/props inspector rather than each consumer rolling a bespoke debug view.