React-Treeview: The Complete Guide to Building Tree Views in React

Hierarchical data is everywhere — file systems, org charts, nested categories, comment threads.
The problem isn’t representing that data; it’s rendering it sanely inside a React application
without writing a recursive nightmare from scratch. Enter
react-treeview —
a lightweight, no-drama React tree component that gets out of your way and lets you focus
on structure rather than implementation gymnastics.

This guide covers everything: installation, basic rendering, handling expandable tree nodes,
wiring up events, advanced customization, and an honest look at when you should consider
a different React tree component library altogether.
Whether you’re building a React directory tree, a settings panel,
or a hierarchical data explorer, you’ll leave here with working code and zero confusion.

What Is react-treeview and Why Should You Care?

react-treeview
is a minimal React component for rendering collapsible, nested tree structures.
It doesn’t try to be everything — no drag-and-drop, no virtualization, no 400KB bundle.
It renders a React nested tree from your data and hands control back to you.
That’s the pitch, and for a large category of use cases, it’s exactly the right tool.

The package follows a simple mental model: every node is either a leaf (no children) or a branch
(has children and can be collapsed/expanded). You control the collapsed state yourself via React’s
useState, which means full control without hidden magic.
This approach makes the component highly predictable — a quality underrated in the era of
heavily abstracted UI libraries.

From a practical standpoint, react-treeview shines when you need to visualize
hierarchical data in React without buying into a heavy component ecosystem.
It pairs naturally with REST APIs returning nested JSON, file system structures,
taxonomy trees, and any data model where parent-child relationships matter.
Small bundle, clear API, zero opinions on your styling beyond the base CSS — that’s the deal.

Installation and Project Setup

Getting react-treeview into your project takes about ninety seconds,
assuming you already have a React environment running.
If you’re starting fresh, create-react-app or Vite with the React template
both work cleanly. Open your terminal and run:

# npm
npm install react-treeview

# or yarn
yarn add react-treeview

# or pnpm
pnpm add react-treeview

After installation, you need to import both the component and its stylesheet.
The CSS import is easy to forget and causes the classic „why does my tree look broken“ moment —
don’t skip it. In your component file:

import TreeView from 'react-treeview';
import 'react-treeview/react-treeview.css';

That’s the entirety of the react-treeview setup.
No provider wrappers, no theme configuration, no peer dependency rabbit holes
(beyond React itself, which you obviously have).
The component is ready to receive your data and render a functional,
collapsible tree component immediately.
From here, the work shifts to shaping your data and wiring state.

Rendering Your First Tree: A Practical react-treeview Tutorial

Let’s build a real example. Suppose you have a directory-like structure —
a classic scenario for a React directory tree.
The data looks like this:

const treeData = [
  {
    label: 'src',
    children: [
      { label: 'components', children: [
        { label: 'Button.jsx' },
        { label: 'Modal.jsx' },
      ]},
      { label: 'utils', children: [
        { label: 'formatDate.js' },
        { label: 'api.js' },
      ]},
      { label: 'App.jsx' },
    ],
  },
  {
    label: 'public',
    children: [
      { label: 'index.html' },
      { label: 'favicon.ico' },
    ],
  },
];

Now build the component. The key insight is that react-treeview
doesn’t manage collapse state internally — you own it.
This is not a limitation; it’s the library respecting your architecture.
Use a state object keyed by node label (or better, a unique ID) to track
which branches are collapsed:

import React, { useState } from 'react';
import TreeView from 'react-treeview';
import 'react-treeview/react-treeview.css';

const treeData = [ /* ...data from above... */ ];

function TreeNode({ node }) {
  const [collapsed, setCollapsed] = useState(false);

  if (!node.children || node.children.length === 0) {
    // Leaf node — no toggle needed
    return <div className="tree-leaf">📄 {node.label}</div>;
  }

  const label = (
    <span
      className="node__label"
      onClick={() => setCollapsed(!collapsed)}
      style={{ cursor: 'pointer' }}
    >
      {collapsed ? '▶' : '▼'} 📁 {node.label}
    </span>
  );

  return (
    <TreeView
      nodeLabel={label}
      collapsed={collapsed}
      onClick={() => setCollapsed(!collapsed)}
    >
      {node.children.map((child, i) => (
        <TreeNode key={`${child.label}-${i}`} node={child} />
      ))}
    </TreeView>
  );
}

export default function App() {
  return (
    <div style={{ padding: '1rem', fontFamily: 'monospace' }}>
      <h2>Project Structure</h2>
      {treeData.map((node, i) => (
        <TreeNode key={`${node.label}-${i}`} node={node} />
      ))}
    </div>
  );
}

This pattern — a recursive TreeNode component that renders either a leaf or
a TreeView branch — is the idiomatic approach for
React expandable tree rendering with this library.
Each node manages its own collapsed state independently,
which means expanding one branch doesn’t affect siblings.
It’s clean, predictable, and easy to extend.

Handling Events and State at Scale

The simple per-node useState approach works perfectly for small trees.
Once your React hierarchical data grows — say, a 3-level taxonomy
with hundreds of nodes — you’ll want centralized state management.
The most pragmatic approach is lifting state into the parent component
and using a Map or plain object to track collapsed status by node ID:

const [collapsedMap, setCollapsedMap] = useState({});

const toggleNode = (id) => {
  setCollapsedMap(prev => ({
    ...prev,
    [id]: !prev[id],
  }));
};

Pass collapsed={collapsedMap[node.id] ?? false} and
onClick={() => toggleNode(node.id)} into each TreeView instance.
This gives you „expand all“ and „collapse all“ features for free —
just reset the map or populate it with true for all node IDs.
It’s also the right pattern when you need to programmatically expand a specific path,
such as highlighting the currently active route in a React nested tree sidebar.

For click events beyond toggling — selecting a node, triggering navigation,
loading async children — simply pass an additional callback.
Since TreeView renders whatever JSX you provide as the nodeLabel,
you have complete freedom: add badges, icons, context menus,
or inline edit fields directly inside the label.
The component doesn’t restrict its children in any meaningful way,
which is exactly why it integrates smoothly into real products.

Advanced Usage: Customization, Async Data, and Styling

Out of the box, react-treeview applies a minimal stylesheet that gives
indentation and basic visual hierarchy. Overriding it is trivial —
the library uses predictable class names (.tree-view, .tree-view_item,
.tree-view_children, .tree-view_children-collapsed)
that you can target directly in your CSS or override with CSS modules and Tailwind utilities.
No !important wrestling required.

Async children — loading subtrees on demand — is where things get interesting.
The pattern involves rendering a placeholder child when a branch is first expanded,
firing a fetch, then replacing the placeholder with real nodes once the data arrives.
Because you control the data and the collapsed state externally,
this is straightforward: track a loading flag per node,
show a spinner as the child, and swap it out on resolution.
This makes react-treeview viable even for large,
lazily-loaded hierarchies like file system explorers or database schema browsers.

One genuinely useful advanced pattern is keyboard navigation.
Attach onKeyDown handlers to your label elements to support
Arrow keys for traversal and Enter/Space for toggling.
Combined with tabIndex on each label,
this gives you a fully keyboard-accessible React tree component
without reaching for an accessibility library.
It’s the kind of thing most tree view tutorials skip,
and the kind of thing accessibility audits absolutely will not.

Alternatives and When to Choose Something Else

Honesty first: react-treeview is not the right tool for every job.
If you need drag-and-drop reordering, virtualization for tens of thousands of nodes,
built-in multi-select, or a heavily designed visual component that matches a design system,
you’re looking at the wrong library. The ecosystem has options.

• react-arborist — Feature-rich, supports virtualization and drag-and-drop. Best for large, interactive trees.
• @mui/x-tree-view — Material UI’s official tree component. Excellent if you’re already in the MUI ecosystem.
• rc-tree — Ant Design’s underlying tree engine. Powerful, with async loading and checkboxes built in.
• react-accessible-treeview — Prioritizes WAI-ARIA compliance. Best when accessibility is non-negotiable.

The pattern of choosing libraries should be: use the simplest thing that satisfies your requirements,
then upgrade when you hit its limits. react-treeview
earns its place precisely because most tree views in production apps
don’t need drag-and-drop or 10,000-node virtualization.
They need reliable expand/collapse, clean rendering of
React hierarchical data, and a small footprint.
That’s what this library delivers.

If you’re building a component library or a product with a strong design system,
factor in the customization ceiling.
react-treeview’s simplicity is a feature until it isn’t —
at that point, migrating to react-arborist or building a custom recursive
React tree component from scratch may be the cleaner long-term call.

Performance Considerations for Large Trees

React’s reconciliation handles moderate tree sizes without issue.
Where things slow down is when every node re-renders on any state change —
a common pitfall when collapse state is managed globally
without memoization. Wrap TreeNode in React.memo
and ensure your toggle callback is stable via useCallback.
This alone resolves most performance complaints with
React expandable trees in the 200–500 node range.

Beyond memoization, consider whether all nodes need to be in the DOM simultaneously.
For trees with dozens of top-level branches each containing dozens of children,
rendering collapsed subtrees as null instead of hiding them with CSS
significantly reduces DOM size and memory footprint.
The collapsed prop in react-treeview handles this
via CSS display toggling by default — you can override this behavior
by conditionally rendering children only when !collapsed,
unmounting the subtree entirely.

For genuinely large datasets (thousands of nodes),
none of the above is sufficient — you need a virtualized list.
At that point, react-arborist (built on top of
react-virtual) is the pragmatic choice.
But for the overwhelming majority of
react-treeview use cases encountered in real codebases,
memoization and selective rendering are more than adequate.

Quick Reference: react-treeview Props

The API surface is intentionally small. Here are the props you’ll actually use:

• nodeLabel (ReactNode, required) — The clickable label rendered for each branch node.
• collapsed (boolean) — Controls whether children are shown. Defaults to false.
• onClick (function) — Fires when the node label area is clicked.
• itemClassName (string) — Custom class applied to the item wrapper.
• treeViewClassName (string) — Custom class applied to the tree container.
• childrenClassName (string) — Custom class applied to the children wrapper.
• defaultCollapsed (boolean) — Initial collapsed state if you’re using uncontrolled mode.

If the props feel sparse, that’s intentional. Everything visual lives in your
nodeLabel JSX; everything behavioral lives in your state management.
The component is a structural shell, not a black box.
That design philosophy is either a relief or an inconvenience depending on what you were expecting.