feat(src): pasting clause uses new uuid - I88

[irmerk]

Issue #88

Create new uuid for a clause that was copy/pasted
Handle html on a copy/paste and abstract out clause paste logic to Cicero-UI

Changes

• On a paste event, we take the Document on the event and make it mutable in order to change the clauseid to a uuid and revert everything to immutable
• On a paste event, we handle html type in the paste effect

Flags

• NOTE: This functionality may need to be moved to @accordproject/cicero-ui to abstract out clause template specific logic.
  • This could take the form of replicating the logic in cicero-ui, passing it down, and running props.onPaste if it has been passed down
    • This has the issue of onPaste requiring PluginManager and FromHTML from markdown-editor, which means they will need to be imported into cicero-ui only for them to be passed down into markdown-editor from which they came from originally
  • Another form this could take is a higher order function, where the clause specific logic is passed down and used in onPaste if it exists and then carries on to the rest of the plugin process.
  • if (transfer.type !== 'html') return undefined; may need to be adjusted with next() or something similar? Unsure what next() really does here.
• Slate uses IMMUTABLE.js, so we need to augment multiple layers to be mutable in order to then change the clauseid and then augment everything back to immutable.
• Further work is needed in the redux store of TSv2, showcased here where the new uuid's placed onto the clauses are not represented in the store, and moreover the extra pasted clause does not appear at all.

DOM:

Store:

Related Issues

• TSv2 Issue 85
• Cicero UI Issue 134

[dselman]

Yes, the clause specific logic should be in Cicero-ui not here. I think we can register multiple onPaste handlers on the underlying slate editor, they are chained by the call to next() I believe. We also need to test what happens on paste of html that contains an existing clause div.

[dselman]

Please move any logic specific to clauses into cicero-ui.

[irmerk]

Yes, the clause specific logic should be in Cicero-ui not here. I think we can register multiple onPaste handlers on the underlying slate editor, they are chained by the call to next() I believe. We also need to test what happens on paste of html that contains an existing clause div.

Not sure I understand how to go about this. This is the direction I am currently going in:

markdown-editor inside SlateAsInputEditor:

const SlateAsInputEditor = React.forwardRef((props, ref) => {
  /**
   * Destructure props for efficiency
   */
  const {
    onChange, plugins, value, lockText, onPaste
  } = props;

...

const onPasteHandler = (event, editor, next) => {
    const pluginManager = new PluginManager(props.plugins);

    if (isEditable(editor, 'paste')) {
      const transfer = getEventTransfer(event);
      const mutableFragment = transfer.fragment.asMutable();
      const mutableNodes = mutableFragment.nodes.asMutable();
      const pastedMutableNodes = onPaste(mutableNodes);

      mutableFragment.nodes = pastedMutableNodes.asImmutable();
      transfer.fragment = mutableFragment.asImmutable();
      editor.insertFragment(transfer.fragment);

      if (transfer.type !== 'html') return undefined;

      const fromHtml = new FromHTML(pluginManager);
      const { document } = fromHtml.convert(editor, transfer.html);
      editor.insertFragment(document);
      return undefined;
    }

    return false;
  };

cicero-ui in ClausePlugin:

const onPaste = (nodes) => {
   // nodes is a Class, and errors when trying to run map on the following line
    nodes.map((node) => {
      if (isHeadingClause(node)) {
        const mutableNode = node.asMutable();
        const mutableDataMap = mutableNode.data.asMutable();
        const mutableAttributesMap = mutableDataMap.get('attributes');

        mutableAttributesMap.clauseid = uuidv4(); // unique identifier for a clause instance

        mutableDataMap.set('attributes', mutableAttributesMap);
        mutableNode.data = mutableDataMap.asImmutable();
        return mutableNode;
      }
      return node;
    });
  };

[irmerk]

Further issues should consider:

• Handling different transfer.type situations

  • Editor instance (Slate) to another editor instance (Slate)
  • Raw HTML (Chrome to VSCode to Chrome)
  • Editor instance (Slate) to Google Docs and back (recognize <clause> formatting)

• Ensure onPaste handlers are not doubling up work for any transfer.type cases

  • @accordproject/cicero-ui/src/plugins/ClausePlugin
  • @accordproject/markdown-editor/src/SlateAsInputEditor

• What fragment.type results when copying pasting from one editor to another instance of an editor?

  • fragment as a transfer.type is a Slate DOM block fragment, not HTML anymore, so copying and pasting from the same editor into itself should be a fragment
  • However, copying pasting from one editor to another instance of an editor may result in HTML or fragment, needs experimentation

• Preserve formatting, if H1 in HTML, we should be preserving the formatting

  • Slate has a mechanism for mapping from HTML tags to Slate blocks here