Implement Scrubber for end-user data in thrown exceptions

[alexandercampbell]

Description
This PR implements a new Scrubber module within Slate that can optionally be used to scrub exception contents of end-user data. The API change is backwards-compatible and the default behavior is unchanged. The docs/api/scrubber.md file in the diff includes additional detail.

This PR also fixes a handful of exceptions which were not stringifying the objects that were being thrown. Before this change, they would have thrown messages of the form: Cannot apply a "merge_node" operation at path [1,2,3] to nodes of different interfaces: [object Object]. After this change, those exceptions include a properly stringified representation of the object in question. See also the discussion in Slack of those exceptions.

Issue
There is no corresponding Github issue. I'd be happy to create one if that's preferred.

Example
Here's an example of scrubbing the 'text' field of any entity that gets logged as part of an exception.

import { Scrubber } from 'slate'

Scrubber.setScrubber((key, value) => {
  if (key === 'text') return '... scrubbed ...'
  return value
})

Context

• The Scrubber module requires one global config var. This had to be done because many of the Slate functions do not take an Editor parameter (e.g,Node.fragment(node, path)).
• The scrubbing is done by simply passing the scrubber function as the second parameter to JSON.stringify when generating exception strings.
• I have written some documentation under docs/api for this new feature. Please let me know if I have missed some context on how those docs should be written or formatted.
• I have created a unit test to verify the behavior of the provided Scrubber.setScrubber function.
• See also the Slack discussion in #contributing from April 11 (and continuing through the 14th) for full discussion context.

Checks

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)
• You've added a changeset if changing functionality. (Add one with yarn changeset add.)

[changeset-bot]

🦋 Changeset detected

Latest commit: 7846ca4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
slate	Minor
slate-react	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cmditch]

We've tested this in our codebase as well

[TheSpyder]

While I appreciate the addition of a helper function, the way it's implemented as an object property it can't be tree shaken when unused.

I don't think you need the ScrubberInterface and this sub-object at all; if you unwrap it and just export const the three functions inside it should be an equivalent interface.

[cmditch]

We thought we'd keep in line with how other Slate modules look (e.g., Transforms.foo, Editor.bar) so we could get Scrubber.setScrubber. Also made documentation a bit easier as we could just add a "Scrubber" section to the docs.

But we're fine with exporting them at the root level too, so you get something like:

import { Editor, Transforms, Node, Element, setScrubber, textRandomizer, createEditor  } from 'slate'

[cmditch]

We could also keep it mostly as is and either remove textRandomizer (maybe just include it in the docs as an example of what one might do) or move it outside of the Scrubber interface.

[alexandercampbell]

Thanks for the feedback! I've updated the branch to remove textRandomizer from the code, since it was just a convenience function anyway. I've instead included it as an example in the docs/api/scrubber.md documentation page.

[TheSpyder]

I guess I'm used to using import * as Scrubber internally and forgot Slate was structured this way. As this is an internal API, however, it could still be used by integrators as import { Scrubber } from 'slate' with a change to how index.ts is structured.

Moving it to documentation is a good solution. Maybe I'll look at this later as a wider change to improve tree shaking within Slate.