How noteloom fits into any React app: lightweight, compatible, fully customizable

"Lightweight" and "customizable" get thrown around a lot in editor marketing. Here's what those words actually mean for noteloom, with the real npm install and the real CSS.

Compatible by design

noteloom's peer dependencies are react and react-dom — nothing else. It works with React 18 and 19, doesn't pin its own copy of either, and doesn't bring a state management library that could collide with whatever your app already uses (Redux, Zustand, plain context, anything).

npm install noteloom react react-dom

That's the entire install. No separate schema package, no ProseMirror or Yjs to configure first — createBlockRegistry(), registerBuiltInBlocks(), wrap it in EditorProvider, and you have a working editor.

Lightweight in practice, not just in package.json

"Zero dependencies" covers install size, but the lighter-weight design shows up at runtime too:

• Every block subscribes only to its own data via useSyncExternalStore — editing one paragraph in a 500-block document re-renders just that block, not a virtual-DOM diff over the whole page.
• The document model is a flat map of blocks and runs, not a deep tree — no recursive schema validation on every keystroke.
• There's a regression test in the package itself guarding large-document performance, not just a claim.

Fully customizable, at two different levels

The default theme reads every color, radius, and font from --noteloom-* CSS custom properties — override any of them in your own stylesheet, no build step, no config file:

:root {
  --noteloom-accent: #16a34a;   /* swap the accent color */
  --noteloom-radius-md: 4px;    /* sharper corners */
  --noteloom-font: 'Inter', sans-serif;
}

Want a completely custom look instead of overriding the default? Pass theme="none" to EditorProvider and nothing gets injected — you style every .be-* class yourself, the same route this site's own editor takes. And beyond CSS, the block registry itself is fully open: register your own block and inline types alongside — or instead of — the built-in ones, with the exact same API the built-ins use internally.

What this adds up to

None of these three properties are independent marketing bullet points — they come from the same underlying decision: keep the document model flat and the dependency list short, and customization and performance follow naturally from that, instead of needing to be bolted on afterward.

The easiest editor to customize is the one that never fought you on the default in the first place.

Try the retheming yourself in the live demo below, or read the full Theming guide and Custom blocks guide for everything shown here.