ReactPage: a React content editor that avoids contenteditable

What ReactPage solves, and who it is aimed at

The README opens with a warning that the project is looking for maintainers, and then states the motivation plainly: ReactPage is for developers who are "fed up with the limitations of contenteditable". That sentence is the whole pitch. Instead of letting the browser mutate a DOM subtree and then trying to serialize whatever came out, ReactPage stores the page as structured data and renders it through React components you control.

The audience follows from that. ReactPage is not a CMS with an admin login and a database. It is a library you mount inside an application you already own. The README's "In the wild" list shows the shape of a real deployment: GuestBell uses it as a CMS for hotel landing pages, Veloplus uses it for content pages and the landing page, Bike2School uses it for content editing. In each case the host application supplies persistence, authentication and routing; ReactPage supplies the editing surface.

That means the decision to adopt it is really a decision about your content model. If your pages are a sequence of typed blocks (a text block, an image block, a spacer, a layout row), ReactPage matches that model directly. If your content is free-form HTML pasted from elsewhere, you will spend time converting it into blocks.

How ReactPage represents a page: blocks, plugins and a renderer

The repository is a Yarn workspace monorepo. The root package.json declares workspaces for packages/editor, packages/plugins/content/*, packages/plugins/layout/*, packages/react-admin and examples. That layout tells you most of the architecture before you read any source: there is one core editor package, and everything that can appear inside a page is a separate plugin package.

Plugins are split into two families. Content plugins cover leaf material. Layout plugins cover containers that hold other cells. The examples directory mirrors this, with examples/plugins and examples/sampleContents sitting alongside examples/pages and examples/components, so the sample application is itself a demonstration of how plugins and stored content are kept apart.

Because the editor is a React component tree rather than a contenteditable region, the value it produces is data. You pass that data back in to render the page, and the same plugin components are used for both editing and display. The practical consequence is that the editor and the published page cannot drift apart in markup: there is one implementation per block type. The cost is that every block type you want has to exist as a plugin, either one shipped in packages/plugins or one you write.

The README does not describe the serialization format in detail, so treat the shape of the stored value as something to confirm against the docs and the sampleContents directory before you commit to a database schema.

Installing @react-page/editor and mounting a first editor

The README gives two install commands, one for Yarn and one for npm. Both install the core editor package; plugins are separate packages under the same scope.

yarn add @react-page/editor

npm install --save @react-page/editor

There is also a beta channel, which the README describes as possibly containing unstable features. The command is the same with a dist-tag appended:

yarn add @react-page/editor@beta

The demo site at https://react-page.github.io/ tracks the stable channel, and a beta demo is published at https://react-page.github.io/beta. Those two URLs are the fastest way to see what the editor looks like before you install anything.

What the README does not give is a minimal mounting snippet. There is no code block showing the component name, the props for initial content, or an onChange handler. The place to look is the documentation at https://react-page.github.io/docs and the working example under examples/, which is a Next.js application (examples/next.config.js, examples/pages, examples/components). Read the example before writing your own integration, because the plugin registration step is where most of the setup lives and the README is silent on it.

One thing the README does state clearly is the release rhythm. The three most recent releases are v5.4.4 in April 2023, v5.4.5 in November 2024, and v5.4.6 in July 2026. The last push to the default branch was on 2026-07-28. Gaps of a year or more between releases are normal here, so pin the version you install and read UPGRADE.md before moving between them.

The plugin wiring is the real integration cost

Installing @react-page/editor gets you the shell. It does not get you a text block, an image block, or a layout row. Those live in packages/plugins/content/* and packages/plugins/layout/*, each published separately, and the editor needs to be told which ones exist.

This is a deliberate design choice, and it cuts both ways. On the plus side, your bundle only contains the block types you registered, and you can write your own plugin for anything domain-specific without forking the editor. On the minus side, a first integration is not a five-minute job. You have to decide your block set, install each plugin package, register it, and then verify that the stored content round-trips through the renderer.

The repository helps here in one specific way: examples/ is a complete application, not a snippet. It has its own package.json, its own plugins directory and its own sampleContents directory. If you clone the repo and run the example, you get a working editor with a known-good plugin set, which is a better starting point than assembling packages from the docs alone. The README does not document a scaffolding command, so expect to copy from the example rather than generate a project.

Where ReactPage is the wrong tool

The maintainer notice at the top of the README is the first limitation, and it is not a small one. The project states it is looking for maintainers and links to issue 1329. The last push was on 2026-07-28 and the previous release before that was in November 2024. Whatever you build on ReactPage, you should assume you may end up maintaining your fork of the parts you depend on.

Second, ReactPage is not a CMS. There is no persistence layer, no user model, no revision history, no media library in the README or the repository layout. If you want an editor that comes with storage and an admin UI, ReactPage is the wrong layer and you will be building the rest yourself.

Third, the contenteditable avoidance is a trade-off, not a free win. Rich inline formatting inside a single block is exactly the kind of thing contenteditable handles natively and a block model handles awkwardly. If your authors expect a word-processor experience inside one paragraph, with arbitrary nested spans, ReactPage's block boundaries will feel restrictive. The editor is at its best when content is genuinely block-shaped.

Fourth, there is a react-admin package in the workspace (packages/react-admin). Its presence suggests an integration path with react-admin, but the README does not describe it, so do not plan around it without reading the package itself.

ReactPage compared with a plain React content component

The nearest alternative is not another editor library. It is what most React teams do first: render content with their own React components, and let authors edit it through a form, a Markdown file, or a headless CMS API. That approach has no editing surface at all in the browser, which is fine when the people writing content are developers or comfortable with Markdown.

The difference in approach is where the structure lives. With plain React components, structure lives in your code: a page is a component, and adding a section means editing a file. With ReactPage, structure lives in data: a page is a stored value describing an ordered set of blocks, and adding a section is a click in the editor. ReactPage therefore only pays for itself when non-developers need to compose pages and the page layout is genuinely variable.

If your pages all follow one fixed template, the component approach is less machinery for the same result. If your pages are assembled per customer or per campaign, the data model is the point, and ReactPage gives you that model along with an editing UI. Note that the two are not exclusive: ReactPage renders through React components, so a page built in the editor and a page written by hand can coexist in the same application.

Licence, versioning and upgrade cost

ReactPage is MIT-licensed. The root package.json carries "license": "MIT", and the repository has a LICENSE file at the top level. MIT is permissive: you can use it in commercial and closed-source products. This is a description of the licence text, not legal advice, and the plugins under packages/plugins/content/* and packages/plugins/layout/* are published as separate packages, so check each package's own metadata rather than assuming the root declaration covers everything you install.

The author field in the root package.json is "ORY GmbH", and the README notes the library was formerly known as ORY Editor, originally created by @aeneasr and @ory. That history matters when you search for answers: older documentation and issues may use the ORY Editor name.

Upgrade cost is the part to plan for. Releases are infrequent (2023, 2024, then 2026 for the three most recent), and the repository ships a dedicated UPGRADE.md at the top level. A file with that name exists because breaking changes have accumulated between versions. Pin an exact version in your lockfile, read UPGRADE.md for every version you cross, and check whether the plugins you registered have kept pace with the editor package, since they version independently.

Editorial conclusion

ReactPage fits teams that already run React and need a block-based editor embedded in their own application, with full control over the plugin set and the stored JSON. It does not fit anyone who wants a hosted CMS, a drop-in page builder with batteries included, or a project that cannot absorb the plugin wiring and the maintainer question raised in the README. Before committing, check the packages/plugins directory for the content and layout plugins you actually need, confirm the React version your app runs against the peer expectations in packages/editor, and read UPGRADE.md for the migration notes attached to the release you are installing.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-page/react-page on GitHub
4. README
5. Releases