Firing events from inside append/filter/apply

So, there’s been some disagreement on this topic for me. We have some listeners outside the editor dom, and theres events being fired from within pluginState.apply, plugin.appendTransaction, and plugin.filterTransaction to these listeners outside of the editor during these cycles.

I’m personally viewing this as a problem, as its a potential hole to block the prosemirror lifecycle from a point that could potentially be unrecoverable.

Could you see this causing any problems @marijn ?

This is definitely not the recommended way to use the system—state apply functions are expected to be pure. A better place to fire events is in the dispatch handler, or in the code that created the transactions.

I should have also stated that we also do events on plugin.update and nodeView.updates. But, I’ve tried to encourage the developers I work with to do them as read only and not reflexively react to them back to prosemirror as the running paradigm for those.

Would those also be potentially the same problem, needing to be pure?

Plugin updates are imperative, you can feel free to fire off events there. Node view updates are more tricky—they are also not pure, but you can’t really reliably predict when they are going to happen (a node view might be redrawn or updated depending on how well the document update is handled by the reconciliation code), so it’s usually a good idea to make them self-contained islands that don’t directly interact with the outside world.

Thats more or less what I’ve found about the node views. That anything needed outside of a node view means that something is being done wrong. We do use some events to fire readonly to something else. Those events are usually display only, or updating some other presentation elsewhere. And they are tricky when you get into destroy, and create, at the same time.

The biggest point of contention is always where do the events go? Its because we have a legacy system we work out of and need to relate some data externally. After having dealt with many problems, This is also the consensus I came to based on my experience with areas for functionality within prosemirror.

This was informative, thanks @marijn.