Command stack change event should be more detailed.

Is your feature request related to a problem? Please describe.

Using the modeler in an environment with it’s own implementation of editor features can be quite frustrating. There is no convenient way to tell what the commandStack did, only that it did something unknown. An example of such an environment is VS Code or atom. Such an environment needs context to function correctly.

Describe the solution you’d like

The commandStack should emit more detailed events, like commandStack.pushed, commandStack.undid & commandStack.redid. Or it could just be added as event data to the commandStack.changed event. Additionally, the executed/reverted commands in that logical unit and their context should be included.

Every commandStack.changed event has an additional property trigger that is either undo, redo, execute or clear. This allows integrators to distinguish the different change events, i.e. to manage dirty state externally.

Describe alternatives you’ve considered

Overwriting the commandStack module is also an approach I could look into, but plugins shouldn’t change core functionality due to compatibility issues. However other than that it would be a very reasonable approach.

I could use the commandStack.execute event and a timer to aggregate all commands with the same id, but it would be great to be able to undo immediately, not after timer.

I could just check the internal data of the commandStack module to determine what exactly changed, but this is unreasonable considering I would be practically implementing my own commandstack in the process, just way more hacky.

[PabloDons]

Happy to!

[nikku]

I appreciate your persistence on this one. I also have to admit, that I did not fully understand why you need that feature.

I’ve built a few desktop like apps around diagram-js based editors and did not see the use-case for more detailed events yet. A trick I employed is to checkout the command stacks stackIndex after each elements.changed event. If the index is lower, I know an undo happened, if it is higher a do or redo happened.

Combining that knowledge with the last saved diagram, i.e. remembering stackIndex after every save allows me to reliably dirty check.

To move this issue forward (and increase a likelyhood of the related PR being merged), maybe you can provide us with a simple mock up (i.e. codesandbox) that shows how you plan to accomplish your dirty check with the API update you propose.

---

Correction: CommandStack._stackIdx is the stack index. I’m happy to make that one public API, i.e. expose it via CommandStack#getStackIndex if you find it useful.