Using merge w/ collab?

I’m trying to make something like a collaborative editor that also uses @codemirror/merge (specifically, unifiedMergeView). I’m currently rolling my own synchronisation logic using JSON, rather than the @codemirror/collab module. However, I feel like it’s not possible to get change to the original document that were made in a transaction, since the updateOriginalDoc StateEffect isn’t public.

(Also, originalDoc not being public makes it so you have to retrieve and set the original document separately, instead of being able to use EditorState.to/fromJSON.)

Am I right in saying this?

Also it seems like StateEffects don’t have a toJSON/fromJSON? Is there a recommended way of sending them between clients?

getOriginalDoc was already exported. originalDocChangeEffect had been implemented but not released yet. I’ve just tagged 6.5.0.

There’s no build-in way to serialize effects. You’ll have to query their type and do your own thing. Because they rely on local StateEffectType objects, deserializing them across environments in a generic way is awkward.

Right, i see that originalDocChangeEffect allows me to make changes to the original doc in a transaction, but with only those two functions I don’t see a way to retrieve the changes made in a transaction (e.g. from accepting/rejecting a hunk).

(also a bit of a tangent again, but is there a way to get the initial value of a StateField in the provide() function? I’m trying to have a set of extensions that are conditionally enabled based on the value of a state field, by having a compartment that is returned from provide() and changing using a transaction extender. But I can’t see any way of having the compartment have the right value initially if StateField.init() is used, or I’m using EditorState.fromJSON)

Ah, right. You can compare the old value of getOriginalDoc to the new one to see if the document changed, but you don’t get access to the changes themselves, which makes it hard to update other clients without recomputing the full diff. Is that the issue you’re running into?

No. The state configuration can’t directly depend on field/facet values. You’d have to set up some logic that reconfigures at the appropriate moment.

yep, pretty much

Would directly exporting the effect, as in this patch, help?