Skip to content

[lexical] Bug Fix: allow same mutation listener fn to be registered to multiple nodes#7654

Merged
ivailop7 merged 2 commits intofacebook:mainfrom
james-atticus:multi-class-mutation-listener
Jun 27, 2025
Merged

[lexical] Bug Fix: allow same mutation listener fn to be registered to multiple nodes#7654
ivailop7 merged 2 commits intofacebook:mainfrom
james-atticus:multi-class-mutation-listener

Conversation

@james-atticus
Copy link
Copy Markdown
Contributor

Description

registerMutationListener currently maps from the listener function to the corresponding node class. If you then call registerMutationListener with a different class, it overwrites the first. This also means that the cleanup function from the first class could end up removing the listener for the second class.

registerNodeTransform on the other hand already allows you to register the same listener function to multiple classes. This change brings the same behaviour to registerMutationListener.

Test plan

Added unit test, fails before change, passes after.

@vercel
Copy link
Copy Markdown

vercel bot commented Jun 27, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
lexical ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2025 5:24am
lexical-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2025 5:24am

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 27, 2025
@james-atticus james-atticus changed the title [lexical] Fix: allow same mutation listener fn to be registered to multiple nodes [lexical] Bug Fix: allow same mutation listener fn to be registered to multiple nodes Jun 27, 2025
@etrepum etrepum added the extended-tests Run extended e2e tests on a PR label Jun 27, 2025
etrepum
etrepum previously approved these changes Jun 27, 2025
Copy link
Copy Markdown
Collaborator

@etrepum etrepum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the right thing to do, honestly surprised it worked this way. I guess most use cases were defining this function with a closure or just not registering multiple classes.

).klass;
const mutations = this._listeners.mutation;
mutations.set(listener, klassToMutate);
if (!mutations.has(listener)) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small nit but if the same sort of klassSet variable approach is used here there could be a single get instead of has and then get. We don't need to check separately because undefined is not a valid value for the entry to have.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this?

    let klassSet = mutations.get(listener);
    if (klassSet === undefined) {
      klassSet = new Set();
      mutations.set(listener, klassSet);
    }
    klassSet.add(klassToMutate);

I'm happy either way. I went with the current approach to avoid let.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that using let is a lesser sin than having more runtime code (and a non-null type assertion). There's plenty of mutable variables in this codebase

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@ivailop7 ivailop7 added this pull request to the merge queue Jun 27, 2025
Merged via the queue into facebook:main with commit 2fdb674 Jun 27, 2025
45 checks passed
@etrepum etrepum mentioned this pull request Jul 3, 2025
fantactuka pushed a commit that referenced this pull request Aug 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. extended-tests Run extended e2e tests on a PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants