Hydration mismatch in PlateStatic due to dynamic data-slate-id/data-block-id attributes

[janhesters]

Description

When rendering a static Slate editor via PlateStatic in an SSR-enabled React Router v7 app, React logs a hydration mismatch warning. On the server, PlateStatic emits data-slate-id and data-block-id attributes with randomly generated values; on the client those IDs differ, so React won’t patch up the DOM.

Expected output

No hydration warnings. The server-rendered HTML and client-rendered HTML should have matching attributes (or omit random IDs during SSR).

Actual output

React issues a hydration mismatch error because the server’s data-slate-id/data-block-id values differ from the client’s newly generated ones.

Reproduction URL

No response

Reproduction steps

1. Create a new React Router app: npx create-react-router@latest my-react-router-app
2. Create a page like:

   import { createSlateEditor, PlateStatic } from 'platejs';
   import { BaseEditorKit } from '~/components/editor/editor-base-kit';

   const editor = createSlateEditor({
     plugins: BaseEditorKit,
     value: [
       { type: 'h1', children: [{ text: 'Server-Rendered Title' }] },
       { type: 'p', children: [{ text: 'This content is rendered statically.' }] },
     ],
   });

   export default function MyStaticPage() {
     return <PlateStatic editor={editor} />;
   }

3. Start the SSR server (npm run dev).
4. Open the page in a browser console.
5. Observe the hydration mismatch warning.

Plate version

49.0.9

Slate React version

0.117.1

Screenshots

Logs

A tree hydrated but some attributes of the server rendered HTML didn't match the client properties. ...  
  <h1
    data-slate-node="element"
    data-slate-inline={undefined}
-   data-block-id="WMGHiR37Hu"
+   data-block-id="nvhMKq722k"
    ref={null}
    data-slate-type="h1"
-   data-slate-id="WMGHiR37Hu"
+   data-slate-id="nvhMKq722k"
    className="slate-h1 ..."
    style={{position:"relative"}}
  >
  ...

Browsers / Environment

Browser: Brave 1.79.126 (arm64, Chromium 137.0.7151.119)
OS: macOS 15.5 (24F74)
Mode: Private window, no extensions active

[dosubot[bot]]

Hi @janhesters! I'm Dosu and I’m helping the plate team.

This hydration mismatch happens because PlateStatic (and the node-id plugin) generates random IDs for data-slate-id and data-block-id on both server and client, but they aren't synchronized, so React sees different attributes and warns about it. There’s no built-in way in Plate 49.0.9 to disable or synchronize these IDs for SSR—this is a known limitation right now.

Possible workarounds: you can inject stable IDs into your document model before rendering on both server and client, or fork/patch the node-id plugin to skip or stabilize these attributes during SSR. Another option is to strip these attributes from the server-rendered HTML, but that may break some features if you need them client-side.

There was a PR introducing editor.uid and some SSR hydration support, but it doesn’t fully solve the random node ID issue for static rendering yet see PR. The attributes are not set directly in PlateStatic, but come from plugins and node properties see code.

If you need deterministic SSR hydration, you’ll need to implement one of the above workarounds for now.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[janhesters]

Possible workarounds: you can inject stable IDs into your document model before rendering on both server and client, or fork/patch the node-id plugin to skip or stabilize these attributes during SSR. Another option is to strip these attributes from the server-rendered HTML, but that may break some features if you need them client-side.

Can you describe how to do these workarounds?

Also, there is no way to tag @dosu.

[zbeyens]

Here is the new helper we've added recently.

[dosubot[bot]]

Here's how you can approach each workaround:

1. Inject stable IDs into your document model:
Use Plate's normalizeNodeId function with a deterministic idCreator (like a hash or counter) to assign the same IDs on both server and client. Example:

import { normalizeNodeId } from '@udecode/plate-node-id';

// Example: simple counter-based idCreator
let counter = 1;
const idCreator = () => (counter++).toString();

const stableValue = normalizeNodeId(yourValue, { idCreator });
// Pass stableValue to your editor on both server and client

This ensures the IDs are always the same, preventing hydration mismatches. See NodeIdPlugin source and tests.

2. Patch or configure the node-id plugin:
You don't need to fork—just configure the plugin with your deterministic idCreator as above. If you want to skip IDs entirely during SSR, you can set idCreator to return undefined or filter out all nodes, but this may break features that rely on IDs.

3. Strip attributes from server-rendered HTML:
You can remove data-slate-id and data-block-id from the HTML string before sending it to the client (e.g., with a regex or DOM parser). Example:

html = html.replace(/ data-slate-id="[^"]*"/g, '').replace(/ data-block-id="[^"]*"/g, '');

Be aware: some Plate features may rely on these IDs for selection, editing, or plugins, so stripping them could break interactivity if you later hydrate the editor.

Tradeoffs:
Stable IDs are safest for hydration. Skipping or stripping IDs may break features that depend on them. If you only need static, read-only rendering, stripping is usually fine.

Let me know if you want a more detailed code sample for your setup!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[janhesters]

@zbeyens @dosu

Thank you, but even with normalizeNodeId this error occurs.

import { createSlateEditor, normalizeNodeId, PlateStatic } from 'platejs';

import { BaseEditorKit } from '~/components/editor/editor-base-kit';

const editor = createSlateEditor({
  plugins: BaseEditorKit,
  value: normalizeNodeId([
    { type: 'h1', children: [{ text: 'Server-Rendered Title' }] },
    { type: 'p', children: [{ text: 'This content is rendered statically.' }] },
  ]),
});

// Render statically
export default function MyStaticPage() {
  return <PlateStatic editor={editor} />;
}

I also tried it like this:

import { createId } from '@paralleldrive/cuid2';
import { createSlateEditor, normalizeNodeId, PlateStatic } from 'platejs';

import { BaseEditorKit } from '~/components/editor/editor-base-kit';

// Render statically
export default function MyStaticPage() {
  const editor = createSlateEditor({
    plugins: BaseEditorKit,
    value: normalizeNodeId(
      [
        { type: 'h1', children: [{ text: 'Server-Rendered Title' }] },
        {
          type: 'p',
          children: [{ text: 'This content is rendered statically.' }],
        },
      ],
      { idCreator: createId },
    ),
  });
  return <PlateStatic editor={editor} />;
}

[dosubot[bot]]

The hydration mismatch still happens because, even after using normalizeNodeId, the NodeIdPlugin may re-normalize or assign new IDs at runtime—especially if its normalizeInitialValue option is not disabled. By default, the plugin checks for missing IDs and can mutate your value on mount, which leads to different IDs on server and client and causes React hydration errors see code.

To fix this, you need to:

1. Pre-normalize your value with a deterministic idCreator (like a hash or counter) on both server and client.
2. Configure the NodeIdPlugin to NOT mutate IDs at runtime by setting normalizeInitialValue: null (not just false). This disables all automatic ID normalization on mount.
3. Make sure you use the exact same normalized value on both server and client.

Example:

import { createSlateEditor, normalizeNodeId, PlateStatic } from 'platejs';
import { NodeIdPlugin } from '@udecode/plate-node-id';
import { BaseEditorKit } from '~/components/editor/editor-base-kit';

// Deterministic idCreator (example: simple counter)
let counter = 1;
const idCreator = () => (counter++).toString();

const value = normalizeNodeId(
  [
    { type: 'h1', children: [{ text: 'Server-Rendered Title' }] },
    { type: 'p', children: [{ text: 'This content is rendered statically.' }] },
  ],
  { idCreator }
);

const plugins = [
  ...BaseEditorKit,
  NodeIdPlugin.configure({ normalizeInitialValue: null, idCreator }),
];

const editor = createSlateEditor({
  plugins,
  value,
});

export default function MyStaticPage() {
  return <PlateStatic editor={editor} />;
}

If you only need static, read-only output, you can also strip data-slate-id and data-block-id from the HTML string after rendering, but this may break features if you later hydrate the editor.

Best practice: always pre-normalize with a deterministic idCreator and disable runtime normalization in the plugin for SSR hydration see details.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[janhesters]

@dosu

This works:

import { createSlateEditor, normalizeNodeId, PlateStatic } from 'platejs';

import { BaseEditorKit } from '~/components/editor/editor-base-kit';

export default function MyStaticPage() {
  // 1) reset counter on *every* render (so server & client both start at 0)
  let counter = 0;
  const idCreator = () => String(counter++);

  // 2) your raw value
  const rawValue = [
    { type: 'h1', children: [{ text: 'Server-Rendered Title' }] },
    { type: 'p', children: [{ text: 'This content is rendered statically.' }] },
  ];

  // 3) stamp in deterministic IDs
  const valueWithIds = normalizeNodeId(rawValue, { idCreator });

  const editor = createSlateEditor({
    plugins: BaseEditorKit,
    value: valueWithIds,
  });

  return <PlateStatic editor={editor} />;
}

[dosubot[bot]]

Yes, that's the right approach—using a deterministic idCreator (like a counter reset on every render) with normalizeNodeId ensures the IDs are identical on both server and client, so React hydration works without warnings. Plate doesn't have built-in SSR-safe ID generation, so this manual step is needed for static rendering scenarios reference.

One thing to watch out for: this method works as long as your document structure is stable and always serialized the same way. If your content is dynamic, collaborative, or can be reordered, a simple counter might not be robust enough—ID clashes or mismatches could happen if the structure changes between SSR and client boot. For static or predictable docs, though, this is the recommended pattern.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[dosubot[bot]]

Perfect! Resetting the counter on every render and using a deterministic idCreator with normalizeNodeId guarantees the same IDs on both server and client, so React hydration works without warnings. This is the best way to handle SSR with PlateStatic right now—just make sure any ID logic is fully deterministic and always runs the same way on both sides. There’s no official Plate doc for this pattern yet, but your approach is spot on. Let me know if you run into any other SSR edge cases!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}