Allow editor input component to read from and save to a Parent pub

[gabestein]

Motivation

• So we can understand whether we can use Travis's demo code as the baseline for an editor and iterate, or whether we need to rebuild it

Requirements

• Rich text editor input component, when rendered in a Form or default editor, reads from and renders value from existing field
• On auto-save or submit, in the case of the Form editor, or on clicking save, in the case of the default editor, the new contents of the rich text field are validated and saved
• Should attempt to use Travis's pattern for session saving such that if the editor does modify other fields or children/parents in the future, that data can be saved via auto-saving or submit on the Form, or clicking save in the default editor OR propose another pattern for doing this kind of multi-field/multi-pub saving

Acceptance Criteria

• On field save validation, should validate against prosemirror for this input component type — if too slow, can validate only against a top-level prosemirror structure
• Update the updatePub server action to accept more than just values — e.g. newly created pubs, added fields, etc. Should be stubbed out for now and still only save the directly edited field, but should be capable of handling creation/updating/deletion of fields on the same pub, whole new/old related pubs, and fields on new/old related pubs in the future. In the future, could be a series of other server actions, etc.

Open Question

• In a future universe where the editor can modify another field that is also present in the form, how do we avoid that conflict? Likely, the rich text editor's contents should take precedence. In theory, proper configuration should avoid this eventuality, but it may happen and so we'll want to make sure we have a way around it.

Non-/Stretch Goals

• Ability to create a child pub with a simple reference to the pub (e.g. PubId)
• Ability to create one type of related pub with a simple reference to the pub (e.g. pubId)
• Validation of "session" concept for saving, or other proposals for how to save
• Support for all the nodes, particularly ones requiring media uploads
• Support for checkpoints, or other types of versioning
• Support for multiple stylesheets
• Support for previewing/rendering

[gabestein]

@tefkah -- mind estimating when you get online tomorrow?

[tefkah]

I put 4 days, as I'm expecting to run into some unexpected issues integrating this into the codebase! Maybe everything is smooth sailing, but as we haven't really tried to do this yet, i'm expecting to run into something weird which may require some back and forth with travis.

[gabestein]

Thanks! I've updated priority in the board. I think this is the top one, especially given the risks!