Is it possible to remove GhostElement's if the CreateNodeOperationHandler fails?

[jmenzies12]

Hey there,

We really like the ghost element feature. However due to having an external source model, our CreateNodeOperationHandler can fail if the external source model is in an invalid state when the user tries to add a new node (I.e. a Langium DSL with syntax errors), because of this the ghost element sticks around until the user does something else (such as moves a node around).

Is there any way to make sure that the ghost element is removed when the CreateNodeOperationHandler fails?

I noticed that the GhostElement only exists on the client side, so I cannot remove it from the diagram model on the server. Perhaps an action sent from the server when CreateNodeOperationHandler fails, that triggers a handler on the client side to clean up the GhostElement?

[martin-fleck-at]

Hi @jmenzies12,

Good catch! I'd argue that this is actually a bug that was introduced when we tried to improve the UX by not discarding the ghost element until we receive the successful creation to avoid flicker. The ghost element is kept as a feedback on the client-side that is re-applied after every update and removed once we call its cleanup actions. However, to improve UX we only discard the feedback so that it is no longer re-applied after the next update happening due to the creation but do not explicitly remove it. If we were to dispose the feedback, we would immediately remove the ghost element but that leads to flickering since the ghost is removed (creating an empty area) and it might be some time until the element is actually created in that position.

Since the ghost element template is fully created on the client side, it is not easily possible to remove it from the server side was we do not have enough information about the element we want to remove (e.g., element id). So for now you can only provide your custom node creation tool and remove the flickering UX improvement to ensure that the ghost element is properly removed. I'll create an issue to track this and hopefully we'll have a fix for that soon. Ideally we can handle that only on the client-side, alternatively we may need to send some additional information to the server as part of the creation operation arguments.

[jmenzies12]

Hey @martin-fleck-at

Yep that makes complete sense, I'll try the workaround for the time being.

Thanks for your help

[jmenzies12]

Just a heads up. We ran into an additional problem with this, if the user keeps trying to repeatedly create nodes and the creation keeps failing, the editor can become frozen. This looks to be due to duplicate ID's from the ghost nodes that are not cleaned up.

The workaround does at least resolve this issue in the meantime.