react-json-inspector

react-json-inspector renders any JSON-serializable value as an interactive, collapsible tree inside a React application. Each key/value pair is rendered as a recursive Leaf node with its own expand/collapse state, a flat keypath breadcrumb, and type-aware value formatting for strings, numbers, booleans, arrays, and objects.

Built-in incremental search lets users type a query and see only the matching branches, with matched substrings highlighted inline. The component exposes hooks for custom click handlers, custom label/value renderers, and programmatic control over which nodes start expanded, making it a drop-in debugging or data-exploration widget for admin panels, API explorers, and dev tools.

What You Get

• An <Inspector data={...} /> component that recursively renders objects and arrays as expandable tree nodes
• Built-in incremental search with configurable debounce and case-sensitivity, plus inline match highlighting
• Per-node keypath breadcrumbs and a getOriginal lens for resolving a node’s original (pre-filter) value by path
• Customization hooks: onClick, interactiveLabel (custom editable labels/values), isExpanded (initial expand predicate), and a pluggable search component
• A plain CSS stylesheet (json-inspector.css) with BEM-style class names that’s easy to override or theme

Common Use Cases

• Embedding a JSON viewer in an internal admin tool or CMS to inspect stored records
• Building an API explorer or Swagger-like UI that lets users drill into response payloads
• Adding an in-app debugging panel for inspecting Redux/store state or request/response bodies
• Rendering configuration or feature-flag objects in a searchable form for support/ops tooling

Under The Hood

Architecture The library is a single React component tree: the top-level Inspector (in json-inspector.js) owns search state and a memoized filterer, and delegates rendering to a recursive Leaf component (lib/leaf.js) that renders itself as a tree node and instantiates a child Leaf for every key when expanded. Cross-cutting concerns are split into small, single-purpose modules under lib/ — filterer.js does substring search with a per-query result cache keyed by shrinking subqueries, lens.js resolves a dotted keypath back to a value in the original (unfiltered) data for the “show original” feature, highlighter.js renders matched substrings, and type.js/is-primitive.js provide the type discrimination used throughout. There’s no external state store or routing — the whole component tree is self-contained and driven entirely by props and local component state, so the “core abstraction” that everything else depends on is the recursive Leaf render loop.

Tech Stack The component is authored against the legacy create-react-class API (pre-ES6-class, pre-hooks React) with prop-types for runtime prop validation and react/react-dom ^15 as peer/dev dependencies, meaning it predates React’s Hooks and Suspense-era APIs but still runs under modern React via the compatibility shims most projects already have. Small utility dependencies (debounce, md5-o-matic for stable node keys, object-assign as an Object.assign polyfill) keep the runtime footprint minimal. The dev/build toolchain uses browserify/watchify for bundling the example app and mocha + chai + enzyme for testing — there’s no bundler config for the library itself, since it ships as plain CommonJS source (json-inspector.js is the main entry).

Code Quality A single spec file (test/json-inspector-spec.js) uses Enzyme’s shallow rendering to assert on class names, root-node expansion, and child-node counts against a large fixture dataset (example/data.json) — real but narrow coverage; there’s no test for the search/filter behavior itself, no CI workflow file in the repo, and no TypeScript or .d.ts types, so type safety relies entirely on prop-types runtime checks. An .eslintrc enforces consistent style (single quotes, semicolons, brace style) but most rules are set to warning level rather than error. Naming is consistent and each lib/ module has a narrow, clearly-named responsibility, which keeps the codebase easy to follow despite the sparse test suite.

API Design The public surface is a single component with a well-documented, flat prop API (data, search, onClick, validateQuery, isExpanded, filterOptions, interactiveLabel, etc.) that’s thoroughly described in the README, so getting a working tree view running takes one import and one required prop. It doesn’t attempt to be a general data-grid or table library — it’s narrowly scoped to “show me this JSON and let me search it,” which keeps the API small, but the reliance on the legacy createReactClass factory and callback-style extension points (rather than render props or hooks) feels dated next to newer JSON-viewer components built with modern React patterns.