Plugin applied classNames not being removed when plugins swapped

We recently just updated to the newer versions of prosemirror-view, and we’re running into a problem with swaping out plugins. We have two plugins that apply different classNames to the docView => outerDesc. The goal is when you swap plugins, it automatically removes a className, and adds the new className. Doing that currently, keeps both at the same time. It doesn’t purge the className the other plugin was applying, and instead keeps the old one and the className of the added plugin. By swapping I mean there are two changed lists of plugins such that:

List A = […, VerticalPlugin, …];

List B = […, HorizontalPlugin, …];

So the two plugins never exist at the same time, both have different classNames that need to be applied without the presence of the other classNames. I hope this makes sense.

Here is the code where it seems to be ignoring the plugin that was applying this className.


The reason why its not removing the className from the removed plugin, is because this function is passed noDeco, which does not contain the previous list of classes from the previous state.

I’m not sure if there was some critical change that is necessary to purge previous classNames applied through stuff like this:

But, If theres something i’m missing here, please let me know. Because, this used to work before.

I’m having trouble reproducing this. If I create the class-adding plugins like new Plugin({props: {attributes: {class: cls}}}), and use updateState to update to a state that has a new class added with reconfigure, I’m seeing the class update as expected.

What about when you remove that plugin with reconfigure? Or swap it with another plugin. Does it remove the class that was applied?

Yes, that’s what I tested, it works on my side.

You’re right, This is weird then. I’ll have to look at it again.

You did not, by any chance, mutate the plugin array that you gave to the editor when replacing the plugin, did you?

No, we did not mutate the array at all from the original. We are doing the equivalent of this:

The part of it that doesnt work is when the nodeViews are also changed. In both of our plugins, we are changing nodeViews, not like this but, using React and whatnot. We would at least try to reflect attributes from the node.attrs that we care about onto the nodes using react state.

Here is a full example of the problem:

Ah, that helped reproduce it (the issue only occurs when there’s also a change in node views). This patch should help.