Editor State from Headless Lexical and React Lexical slightly differs

[buondevid]

Hi guys

We are facing a gnarly problem with our implementation of Lexical and React Hook Form.

Introduction

We have had normal inputs with html inside, and we are trying to implement Lexical to replace them. In our DB I store the html string, then the frontend fetches this html string, uses a headless Lexical to convert the html to a Lexical Editor State, and then use that calculated Editor State to initialize our Form, and by consequence Lexical as well. This is of course an adapter logic just for the migration; as soon as the user saves the Lexical again, we'll store directly the json stringified Editor State and not the html string as we used to have before.

This is the htmlToEditorStateHeadless function by the way, using the same nodes and config as our React Lexical editor:

/**
 * Convert an HTML string into a stringified Lexical EditorState using a headless editor.
 * Returns an empty string if the produced state has no text content.
 */
export function htmlToEditorStateHeadless(html: string, options: Options = {}): string {
  const content = html.trim?.();
  if (!content) return '';

  const { nodes = NODES, namespace = NAMESPACE } = options;

  try {
    const editor = createHeadlessEditor({ namespace, onError, nodes });

    editor.update(
      () => {
        const parser = new DOMParser();
        const dom = parser.parseFromString(content, 'text/html');
        const nodesFromDom = $generateNodesFromDOM(editor, dom);
        $getRoot().clear();
        $getRoot().select();
        $insertNodes(nodesFromDom);
      },
      {
        discrete: true,
      },
    );

    const editorState = editor.getEditorState();

    let isEmpty = false;
    editorState.read(() => {
      isEmpty = $isRootTextContentEmpty(false, true);
    });
    if (isEmpty) return '';

    return JSON.stringify(editorState);
  } catch (err) {
    onError(err);
    return '';
  }
}

Problem

The problem we are facing is that, as soon as the user touches the Lexical editor, the RHF goes dirty. I checked the diff between the initialization Lexical state and the new one after touching it, and it seems that the difference appears here

There is textFormat: 3 that appears twice in the modified version. This only happens on html strings that have some kind of rich texts inside, like bold, italic, etc..

Improvement attempt

First I was wondering why just the mere clicking on the Lexical Editor would trigger a change, then I found out that the OnChange plugin has a property called ignoreSelectionChange. This fixed the fact that the change would happen on merely clicking in the editor but it didn't fix the underlying problem.

In fact, now if I add a letter to the Editor and delete it right after, the underlying Editor State results modified and, by consequence, the form is dirty. In this case, I'd expect the state to be equal to initialization, which is not.

---

Any suggestions on what could cause the problem, or what could we do better to avoid this problem or achieve our migration? Thank you 🙏

[etrepum]

This looks like an artifact from how the editor does reconciliation of textFormat. Basically the format and style of the last dirty TextNode in an Element is stored on that element so that when a new TextNode is created it will use that same format and style.

I haven't seen any evidence that this happens just by clicking or selection changes though, it should only happen when nodes are dirty which requires some sort of input (like the example you gave of typing and then deleting a character).

It should be safe to strip or ignore textFormat and textStyle from your serialization when performing equality checks, these are more of a computed property related to the editing state like the selection than actual document metadata (at least with any nodes that ship with Lexical, third party nodes could use arbitrary properties to mean arbitrary things). Nodes that have meaningful style and format properties store them with other names (e.g. format and style). Might be worth filing an issue to see if we need to serialize those properties to JSON at all, my guess is that we don't.

[buondevid]

Thank you for the help! I'm wondering why doesn't creating the Lexical state with my headless function doesn't output the same? I'd expect them to be equal since they use the same configs... isn't there a way to force the headless package to output the same cached styling output? In that way my form wouldn't get dirty because they would be the same for the same content in the Editor

[etrepum]

The state from the headless editor is the same as the state from an interactive editor. It’s the edits that are changing it.

[buondevid]

I understand, however triggering a change in the headless Lexical and then extracting the editor state doesn't seem to yield the same editor state as the React Lexical after adding and deleting a char.

This is what I tried in the headless to try to achieve an editor state with a cached text format property as you mentioned:

Do you suggest we really just strip those properties when comparing for equality? There is now way I can achieve parity of Lexical Editor States for same content if an edit has happened on the React Lexical one (to which the content went back to be the initial one)?

It doesn't look super clean to strip some props from the Editor State 🥲. It works though, but I'm wondering if maybe we shouldn't open an issue to fix this inconsistency somehow, so that others in the future don't have to "magically" strip some properties manually from the Editor State, with (I guess) no guarantee that these props eventually won't be used for something actually important that stripping will break one day. Also I don't have to strip the property if the Editor State comes directly from the React Lexical; only for the fields that we are migrating the first time, so it would be a tricky/weird conditional logic imo.

I think you are in better position than me to understand what the issue is, but to me the main problem is: why editors with exactly the same content, produce slightly different JSON outputs, and should we fix it so that they align?

[etrepum]

You may need to attach a root element to the headless editor to get the exact same result since this happens during reconciliation.

I did say in the first reply that it may be worth filing an issue.

[buondevid]

thank you for your help, opened an issue here

btw, not sure what you meant to attach a root to the headless editor, when I tried this I got the error:

[buondevid]

My issue was solved by this Lexical improvement #7971.