receive op data had split more times with not local？

[aeroyu]

i submit op like
[
{
"sd": "checkable-list-item",
"p": [
"blocks",
0,
"type",
0
]
},
{
"si": "unstyled",
"p": [
"blocks",
0,
"type",
0
]
}
]
and local receive op event op is the same with send data，
but with other client receive op，has split two time，[
{
"sd": "checkable-list-item",
"p": [
"blocks",
0,
"type",
0
]
}] and [{
"si": "unstyled",
"p": [
"blocks",
0,
"type",
0
]
}
]

how can i receive op normal

[alecgibson]

Could you please elaborate on your use case? Why is it important to have these delivered as a single object?

[aeroyu]

Could you please elaborate on your use case? Why is it important to have these delivered as a single object?

i use sharedb with draft js，when the op is split and setState，will not work，ex [ { "sd": "unstyled", "p": [ "blocks", 0, "type", 0 ] }, { "si": "checkable-list-item", "p": [ "blocks", 0, "type", 0 ] } ]
the first op （delete type unstyled） merge into local ，but it is not my expect，because ，draft js block type can not be empty，and will reset type to unstyled，after apply the second op , the type result is “checkable-list-itemunstyled”

[aeroyu]

Could you please elaborate on your use case? Why is it important to have these delivered as a single object?

i have solve it，i solution is set the uuid and op_size to op model，when receive by other side，i get uuid and op_size to merge the ops and do one setState，it work！any best solution？

[alecgibson]

Glad to hear you solved it. Honestly off the top of my head I'm not sure there's any (easy) way around it. If you're interested, here's the code that's responsible for that behaviour:

sharedb/lib/client/doc.js

Lines 584 to 620 in c711cfc

	// Iteratively apply multi-component remote operations and rollback ops
	// (source === false) for the default JSON0 OT type. It could use
	// type.shatter(), but since this code is so specific to use cases for the
	// JSON0 type and ShareDB explicitly bundles the default type, we might as
	// well write it this way and save needing to iterate through the op
	// components twice.
	//
	// Ideally, we would not need this extra complexity. However, it is
	// helpful for implementing bindings that update DOM nodes and other
	// stateful objects by translating op events directly into corresponding
	// mutations. Such bindings are most easily written as responding to
	// individual op components one at a time in order, and it is important
	// that the snapshot only include updates from the particular op component
	// at the time of emission. Eliminating this would require rethinking how
	// such external bindings are implemented.
	if (!source && this.type === types.defaultType && op.op.length > 1) {
	if (!this.applyStack) this.applyStack = [];
	var stackLength = this.applyStack.length;
	for (var i = 0; i < op.op.length; i++) {
	var component = op.op[i];
	var componentOp = {op: [component]};
	// Transform componentOp against any ops that have been submitted
	// sychronously inside of an op event handler since we began apply of
	// our operation
	for (var j = stackLength; j < this.applyStack.length; j++) {
	var transformErr = transformX(this.applyStack[j], componentOp);
	if (transformErr) return this._hardRollback(transformErr);
	}
	// Apply the individual op component
	this.emit('before op', componentOp.op, source, op.src);
	this.data = this.type.apply(this.data, componentOp.op);
	this.emit('op', componentOp.op, source, op.src);
	}
	// Pop whatever was submitted since we started applying this op
	this._popApplyStack(stackLength);
	return;
	}

You'll see it performs this check:

if (!source && this.type === types.defaultType && op.op.length > 1)

and then "shatters" the op.

So one potential way around this would be to register second json0 type, which isn't the default type, and use that, but it's pretty hacky.

You could also try switching to the json1 type, which seems to have more semantic operations (including replace).

The final thing — which I think is what you've landed on? — is to buffer incoming ops and batch them together.

Of course you could always raise a pull request to disable this behaviour using some sort of config flag!

[aeroyu]

Glad to hear you solved it. Honestly off the top of my head I'm not sure there's any (easy) way around it. If you're interested, here's the code that's responsible for that behaviour:

sharedb/lib/client/doc.js

Lines 584 to 620 in c711cfc

	// Iteratively apply multi-component remote operations and rollback ops
	// (source === false) for the default JSON0 OT type. It could use
	// type.shatter(), but since this code is so specific to use cases for the
	// JSON0 type and ShareDB explicitly bundles the default type, we might as
	// well write it this way and save needing to iterate through the op
	// components twice.
	//
	// Ideally, we would not need this extra complexity. However, it is
	// helpful for implementing bindings that update DOM nodes and other
	// stateful objects by translating op events directly into corresponding
	// mutations. Such bindings are most easily written as responding to
	// individual op components one at a time in order, and it is important
	// that the snapshot only include updates from the particular op component
	// at the time of emission. Eliminating this would require rethinking how
	// such external bindings are implemented.
	if (!source && this.type === types.defaultType && op.op.length > 1) {
	if (!this.applyStack) this.applyStack = [];
	var stackLength = this.applyStack.length;
	for (var i = 0; i < op.op.length; i++) {
	var component = op.op[i];
	var componentOp = {op: [component]};
	// Transform componentOp against any ops that have been submitted
	// sychronously inside of an op event handler since we began apply of
	// our operation
	for (var j = stackLength; j < this.applyStack.length; j++) {
	var transformErr = transformX(this.applyStack[j], componentOp);
	if (transformErr) return this._hardRollback(transformErr);
	}
	// Apply the individual op component
	this.emit('before op', componentOp.op, source, op.src);
	this.data = this.type.apply(this.data, componentOp.op);
	this.emit('op', componentOp.op, source, op.src);
	}
	// Pop whatever was submitted since we started applying this op
	this._popApplyStack(stackLength);
	return;
	}

You'll see it performs this check:

if (!source && this.type === types.defaultType && op.op.length > 1)

and then "shatters" the op.

So one potential way around this would be to register second json0 type, which isn't the default type, and use that, but it's pretty hacky.

You could also try switching to the json1 type, which seems to have more semantic operations (including replace).

The final thing — which I think is what you've landed on? — is to buffer incoming ops and batch them together.

Of course you could always raise a pull request to disable this behaviour using some sort of config flag!

thx

[alecgibson]

@aeroyu this should now be fixed in v1.5.0 — you can listen for the op batch event instead of op

[aeroyu]

thx ， great help to me