share / sharedb / 1474

97%

master: 97%

push

travis-ci

Add batch op events

This change adds two events:

 - `before op batch` - fired once before any set of ops is applied.
 - `op batch` - fired once after any set of ops is applied. This may
   follow multiple `op` events if the op had multiple `json0` components

This is a non-breaking change that should allow clients to process ops
in their entirety.

There has already been some discussion around this:

 - https://github.com/share/sharedb/pull/129
 - https://github.com/share/sharedb/issues/396

This is a much simpler approach than the existing pull request. Here we
try not to change existing behaviour, and only add new, non-breaking
events.

Motivation for such an event would include clients applying some form of
validation logic, which doesn't make sense if an op is shattered.

For example, consider a client that wants to ensure a field
`mustBePresent` is always populated:

```js
doc.on('op', () => {
  if (!doc.data.mustBePresent) throw new Error('invalid');
});

remoteDoc.submitOp([
  {p: ['mustBePresent', 0], sd: 'existing value'},
  {p: ['mustBePresent', 0], si: 'new value'},
]);
```

In the above example, the submitted op is clearly attempting to perform
a replacement. However, the receiving `doc` only receives this
replacement in parts, so it looks like the document reaches an invalid
state, when actually the submitted op is perfectly valid.

In this case we `throw`, but we could have also attempted to populate
with a default value, which could interfere with the desired value.

This change fixes the above issue, because now we can just listen for
the `op batch` event, and consider the document once all the components
of a given op have been applied.

1428 of 1650 branches covered (86.55%)

3 of 3 new or added lines in 1 file covered. (100.0%)

3100 of 3184 relevant lines covered (97.36%)

548.77 hits per line