What it is
Every product that shows documents rebuilds the same UI: folder navigation, breadcrumbs, a list or grid of files, search, sort, selection, view and download actions.
The existing options are either full file managers — they own storage, upload and delete, and expect a backend contract — or headless tree primitives that leave you building all the chrome.
Document Explorer sits in the middle and does one thing:
ANY DATA → MAPPER → NORMALIZED MODEL → EXPLORER UI → EVENTS<DocumentExplorer data={documents} />What it does not do
No storage. No upload, delete, rename, move or copy. No S3, Drive or SharePoint integration. No auth. No backend. No PDF or Office viewer.
You already have the data and you already know what "download" means in your app. The library renders the explorer and tells you what the user did.
Three levels of API
Start with one line and go as deep as you need.
// Level 1 — it just works
<DocumentExplorer data={documents} />
// Level 2 — common configuration
<DocumentExplorer data={documents} view="grid" search selection />
// Level 3 — rebuild the UI
<DocumentExplorer
data={raw}
mapper={mapper}
columns={columns}
renderers={{ file: (f) => <MyCard file={f} /> }}
actions={actions}
/>Advanced customization goes through four grouped objects — mapper, columns, renderers and actions — rather than a hundred separate props.
How React and Angular stay identical
All behaviour lives in @document-explorer/core, a framework-free package with zero runtime dependencies. React subscribes with useSyncExternalStore; Angular republishes the same store as a signal.
Neither reimplements navigation, filtering, sorting, selection — or even the keyboard shortcuts, which come from createKeyboardNavigator() in core.
The Angular test suite is a deliberate mirror of the React one: the same assertions, in the same order, against the same fixture. A divergence between them is a bug in core, not in a renderer.
Next: Quickstart — a complete working explorer, start to finish, in about five minutes.