Adds two new doc events: 'before op batch' and 'after op batch'

[danburzo]

We have recently upgraded from ShareJS to ShareDB following the migration guide. We've replaced after op with the op event, but we have found that op is called for each individual operation, as opposed to after op which had been called after an entire batch of operations.

The addition of two new events that get called at the start, and the end, of a batch of operations allows us perform the optimizations we were doing previously for when the client receives a batch of remote operations.

This pull request introduces these events:

• before op batch is called before any before op event in a batch
• after op batch is called after any op event in a batch

They currently receive no parameters, but we can change that if any parameters would be appropriate here.

Best regards!

[coveralls]

Coverage increased (+0.006%) to 95.855% when pulling 53b9109 on Evercoder:master into 7938f7f on share:master.

[coveralls]

Coverage increased (+0.007%) to 95.517% when pulling 60509ba on Evercoder:master into e45010c on share:master.

[danburzo]

Is there any chance we can get this merged soon? It's causing some issues for us that are hard to tackle without these events in place.

Thank you!

[danburzo]

We ended up publishing our fork in the interim.

[adelriosantiago]

I was looking exactly for this. the op event triggers several times individually. And each change is actually broadcast'ed to all users. Will this PR land master?

[alecgibson]

I'm not entirely sure I understand the motivation behind this change. What's the use case?

[danburzo]

When receiving a batch of events, it can be beneficial to be able to tell when the batch starts and ends, so that you may pause side-effects at the beginning of the batch, and only update and resume when you've finished incorporating all the (potentially hundreds of) individual ops.

In a previous version of sharedb, after op would trigger after the entire operation batch is finished, and following the suggestion from the upgrade guide to switch from after op to op incurred a significant performance penalty.

[alecgibson]

@danburzo sounds fairly reasonable to me. I'll see if I can discuss with other contributors tomorrow. My one reservation about it is that it would be an event that only ever has relevance to the default type, but json0 is something of a special case across all of sharedb, so I've certainly heard weirder things.

[alecgibson]

Had a discussion with @ericyhwang . In general, this should be fine. It is a bit weird that it'll only affect the default type, but this doesn't preclude us from extending to other types later, and JSON0 already gets slightly special treatment (eg projections).

Could you please:

• Rebase
• Change event names to: beforeMultiComponentOp and afterMultiComponentOp (we'll separately camel-case before op and after op — we somehow missed this in the v1 release)
• Only emit the events for these shattered JSON0 ops — you should just be able to remove the length check here, and then remove the new events you've outside that if block