Patterns for testing components using Lexical

[doytch]

Hey folks, I've been building out an editor using Lexical for the past couple of days and one thing I'm still quite hazy on is testing.

I've created a new component - let's call it RichTextEditor - that renders a LexicalComposer along with a custom EmailAddressPlugin. Said plugin has a decorator EmailAddressNode which tokenizes the email strings like so:

Nothing super fancy, think the tokenizing in most email clients' composer's "To" fields.

I'd like to be able to write some tests to verify the functionality from the user's perspective. Eg, select the textarea, press keyboard keys, verify the DOM.

I'm using Remix + Vitest + RTL and quickly ran into issues where it seems like something's not being picked up properly.

  test("should trigger `onChange` when it is typed into", async () => {
    const spy = vi.fn((nodes) => console.log(nodes));
    const { user } = render(<RichTextEditor onChange={spy} />);

    const textbox = screen.getAllByRole("textbox")[0];

    await user.click(textbox);
    await user.keyboard("foo");
    
    screen.debug(); // this doesn't include "foo"
    
    await screen.findByText("foo"); // this fails
  });

The output of screen.debug() (an RTL helper) included the following:

    <div
      class="h-40 rounded-lg border-border-light p-4 text-body2 leading-[30px] shadow-xs outline-none transition focus:shadow-focus \""
      contenteditable="true"
      data-lexical-editor="true"
      id="rich-text-editor-ce"
      role="textbox"
      spellcheck="true"
      style="user-select: text; white-space: pre-wrap; word-break: break-word;"
    >
      <p>
        <br />
      </p>
    </div>
    <div
      class="pointer-events-none relative -top-[154px] left-4 text-body2 text-text-secondary"
      data-test-id="rich-text-editor-placeholder"
    >
      Enter some text...
    </div>

That output (the p and br especially) suggests to me that the contenteditable is being focused but the keyboard events aren't being registered properly. If I snoop a bit using the OnChangePlugin, then I can see the onChange is firing four times but there isn't anything in the SerializedEditorState besides that p and br either.

Question 1: Before I keep digging more into this, is this a known issue with jsdom or other headless engines (happy-dom?)? I noticed that the project uses Cypress and I'm wondering whether that's because the tests I want to write are simply not possible with headless unit tests like I'm using.

Question 2: If I am up a creek writing these kinds of unit tests, what's the suggested way of testing custom nodes and plugins? I know there are a bunch of unit tests in the codebase for the builtin nodes/plugins but given the 0.x.y nature of the project I'm wary about drawing toooo many conclusions (especially after I went down an inert rabbit hole before reading a PR deprecating it 😅). Are there any exemplars I could pattern my tests off of? If it doesn't exist yet, I'd love to take this as an opportunity to build a "So you want to test your custom node/plugin?" doc.

[alocay]

I am also running into issues like these when testing components that involve lexical. Some guidance here would be appreciated.

[alvarogfn]

I am also experiencing this problem.

When I tried to test the type event:

  const contentEditable = screen.getByRole('textbox')
  await user.click(contentEditable)
  await user.type(contentEditable, 'test')
  screen.debug(contentEditable)

or with keyboard events:

  const contentEditable = screen.getByRole('textbox')
  await user.click(contentEditable)
  await user.keyboard('test')
  screen.debug(contentEditable)

The result of the debug function was:

 <div
    contenteditable="true"
    data-lexical-editor="true"
    role="textbox"
    spellcheck="true"
    style="user-select: text; white-space: pre-wrap; word-break: break-word;"
  >
    <p>
      <br />
    </p>
  </div>

I tried adding an event listener to the contentEditable to see what was going on under the hood.

  contentEditable.addEventListener('input', () => {
    console.log(contentEditable.textContent)
  })

I noticed that the console log is called on every keypress, but nothing is generated inside the contentEditable.

[ivailop7]

I'm not sure if this question is targeting headless only, but I've been using playwright for point and click testing without any issues, but for an editor instance that has UI. I haven't seen the repo using Cypress, maybe I started looking at the code at a much later stage. Have a go with Playwright.

[aidenywl]

Facing this as well, tried userEvent.type and userEvent.keyboard and they do not seem to register in react testing-library.

I console logged in the onChange and can verify that onChange is called on each keypress, and nothing is generated inside contentEditable. This is still happening on 0.11.1, making it difficult to write unit tests.

Currently circumventing this with playwright tests, though being able to write unit tests would be nice :/

[aidenywl]

Opened an issue for this here: #4595

@doytch I'm using your description here, it's really detailed!

[enbanil]

Try await in front of render.

// change the text
const textBox = await screen.getByRole('textbox');
await textBox.focus();
await user.click(textBox);
await user.keyboard('23');

[giokallis]

Is there anything new about the above?

[denisbilchenko]

I was able to resolve the issue above by using user-event + fireEvent

const editor = await screen.findByRole('textbox', { name: 'Content' });

await user.click(editor);
await user.tab();
fireEvent.input(editor, { data: 'test' });

after using await user.tab(); the real editor area became focusable and fireEvent.input did a trick.

[oleksandr-danylchenko]

Unfortunately, it doesn't work for me:

"@lexical/react": "^0.30.0",
"jest-environment-jsdom": "^30.2.0",
"jest": "^30.2.0",

The contenteditable input remains empty.

[tvongaza]

We've been using the experimental playwright component testing system after too many issues with JS DOM. It has been fairly seamless to use. As these run in actual browsers we haven't had to jump through any JS Dom hoops. Playwright has been extremely consistent without the usual integration test flakeyness.

All of the lexical playground specs are written for playwright and we have gotten most of them converted over (with some minor tweaks) to the playwright component testing system fairly easily. Then layered in our own specs for our customizations.

https://playwright.dev/docs/test-components

[rossmeredith]

Hey, is any of your playwright testing open source?

[levensta]

JSDOM still doesn't support contenteditable jsdom/jsdom#1670