Roadmap for custom document nodes (block/inline) and editor extensibility

[xdarkleonx]

First of all, thank you for building this library. I think this is currently one of the most promising native rich text editors for React Native.

I'm evaluating it as the foundation for a long-term project (React Native + Web), where the editor will be used not only for formatted text, but also for rich structured content similar to Notion, Telegram, or modern social platforms.

Before committing to this library, I'd like to better understand its long-term architecture and roadmap regarding extensibility.

Custom document nodes

Are there any plans to support custom document nodes in the future?

For example, instead of only built-in elements like images, links and mentions, it would be extremely useful to define application-specific nodes such as:

• Exercise
• Workout
• Food
• Product
• Recipe
• Poll
• Embedded Post
• Custom Card

Some questions

1. Custom node registration

Is there (or will there be) a way to register custom document node types, not just custom HTML tags?

Something conceptually similar to:

registerNode({
  type: "exercise",
  kind: "block", // or "inline"

  parse(element) { ... },

  serialize(node) { ... },

  render(props) { ... },
});

In other words, extending the editor's document model instead of only working with HTML.

---

2. Inserting custom nodes

Would it be possible to insert such nodes through the editor API?

For example:

editor.insertNode({
  type: "exercise",
  id: "123",
});

instead of inserting HTML manually.

---

3. Atomic / void nodes

Are atomic (non-editable) nodes planned?

For example:

┌────────────────────────┐
│ Bench Press            │
│ Chest                  │
│ ★★★★☆                  │
└────────────────────────┘

The cursor should never be placed inside the card.
The whole card should behave as a single editable object (similar to image nodes in many editors).

---

4. Serialization

How would custom nodes be serialized/deserialized?

Would they become custom HTML elements?

Example:

<exercise
  id="123"
  muscle="chest"
/>

Or is another serialization format planned internally?

---

5. Rendering

Would custom nodes be able to provide their own renderer that works consistently across:

• Android
• iOS
• Web

Ideally something similar to:

registerNode({
  type: "exercise",

  renderAndroid() {},

  renderIOS() {},

  renderWeb() {},
});

or even a shared React renderer if possible.

---

6. Roadmap

Is editor extensibility something already planned, or is the current focus intentionally limited to rich text features only?

I'm asking because this feature would make react-native-enriched-html an excellent foundation for building editors similar to Notion, Telegram, or other block-based editors in React Native.

Thank you!

[MrTONYCHAN]

Based on the currently documented surface, I would not assume that arbitrary application-defined block/inline nodes are supported yet. Custom HTML parsing/rendering is not equivalent to extending the editor’s internal document schema: a real node API also needs selection semantics, cursor movement, copy/paste, undo/redo, serialization, collaboration mapping, and platform-native rendering.

For a long-term Notion-style product, the minimum capability I would want confirmed before committing is something like:

• registered node type plus schema/attributes;
• block vs inline and atomic/void behavior;
• insert/update/delete commands;
• parse + serialize hooks;
• React Native and web renderer hooks;
• defined selection/clipboard/undo behavior.

If those contracts are not on the roadmap, embedding custom cards as opaque HTML may work for display but will become fragile for editing and round-tripping. I would prototype one atomic block (for example exercise{id}) first and test insertion, deletion with Backspace, selection across it, paste, undo/redo and HTML round-trip on both native and web. That experiment will tell you whether the existing extension points are sufficient or whether you need an editor with an explicitly extensible schema/fork.