Umbrella Issue: Handling Paste/Import of Unrecognized or Undesired Nodes

[kraisler]

Please consider this an umbrella issue for a larger problem that needs to be broken up into more manageable pieces. This problem spans copy and paste, WEB and mobile, and import and export to other non-Lexical formats like HTML.

Problem Use Case 1: I want to copy from one Lexical Editor instance and paste to another. The the other instance is not able to recognize some of the Nodes, likely because it has not registered those nodes.

Problem Use Case 2: I want to copy text containing lists and paste into an embedded image's caption. The destination should not support lists, and should mainly support plain text. However, bold, underline (BIUS) and links should come through. E.g. no lists, yes BIUS, yes links.

Problem Use Case 3: I want to copy a table from Quip and paste into Lexical. Well, some Lexical surfaces support tables and other's do not. The ones that do not attempt to convert the HTML to a Table node, but this table node is not registered.

Problem Use Case 4: I'm on iOS and I want to load a document that contains Nodes that are not registered as the client, because the client is older than the latest on WEB and thus the client is importing something that is newer. This is termed "forwards compatibility."

Problem Use Case 5: I'm on any Lexical client and I want to load some older content that uses Nodes that have been deprecated and possibly replaced. I want to upgrade. This is termed "backwards compatibility".

All uses cases are variations of Import and Export.
Requirements:

1. Replace unrecognized Nodes with something like an UnRegististeredNode that can display a friendly user message or image.
2. Convert HTML Nodes and when Nodes are not supported by the destination, downgrade the node to plain text or use the UnRegististeredNode strategy.
3. Copy and Paste to destinations not supporting certain nodes: Use the same pattern as defined for # 2 above.
4. Importing an older version: Have client side upgrade code that converts the deprecated Node to the newer Node or simply fallback to # 1.
5. Importing a version that is newer: Have client side import code that utilizes strategy # 1.

[acywatson]

Great write up, thanks for clarifying all of these cases. Lots to think through here.

Replace unrecognized Nodes with something like an UnRegististeredNode that can display a friendly user message or image.

Why not just fall back to HTML here, as we're currently doing?

Convert HTML Nodes and when Nodes are not supported by the destination, downgrade the node to plain text or use the UnRegististeredNode strategy.

I think this is basically what we're already doing - if we don't recognize a DOM node type, we just ignore it and process it's children. If it contains text, we'll process it as such. I would guess this probably needs some polish though.

[kraisler]

"I think this is basically what we're already doing - if we don't recognize a DOM node type, we just ignore it and process it's children. If it contains text, we'll process it as such. I would guess this probably needs some polish though."
This is OK, but when you provide a specific message that something that was pasted did not fully convert, you help the user out much more. Example: user pastes a ton of information. A small part of that was compatible and so was downgraded or eliminated. The fail case happens silently. This could be bad. A little warning might be useful.

Or, pasting a Table to places not supporting tables. Could the copied source supply a PDF side car of the table as an alternate. Could be extremely useful. This is fairly high traffic/highly desirable within the confines of the tables copy and paste.

Downgrading to plain text might be too lossy. Can we preserve some styling and discard other styling that is unwanted or unrecognized?