Rich text editor

This is a consolidation of issues #10/#316/#377/#593 and new work by @mitchellhamilton.

Modern CMSs have block-based editing experiences which provide structure to input data beyond just HTML or markdown, but which also allow for freedom in the way those blocks are pieced together.

Keystone 5 needs a block-based editing experience.

Note: For motivations, see this comment below

There are internal needs that will be met by this style of editor over, say, a markdown or html field type.

@mitchellhamilton has been making great progress on such an editor and will provide more details below 👇

See comments below for:

• How to handle KS5 native types as Blocks (similar to bold/link/etc)
• How to model Relationships
• How to store the data produced by the editor
• How to parse & render that data

TODO ^{in no particular order}

• GraphQL Types
  • Generate internal join tables based on the block types added
  • Generate input types for mutations
  • Blocks generate GraphQL input types to be added as child fields on the Content field type For example;

    {
      document
      relationshipUsersMention: relationshipUser(where: { type: 'mention' }) {
        username
      }
      relationshipUsersEmbed: relationshipUser(where: { type: 'embed' }) {
        username
        avatar
        bio
      }
    }
    

• Mutations
  • Client: Serialise Slate’s document data before sending to the server (see https://github.com/keystonejs/keystone-5/issues/616#issuecomment-458831325)
  • Server: Parse the serialised data on the server to perform relationship creates/connects
  • Server: Inject resolved create/connect ids into serialised document before saving to DB
• Queries
  • Client: Specify shape of data to return for complex blocks with a graphQL query
  • Server: Parse serialised document to extract related IDs
  • Server: Perform queries for the given IDs
  • Client: Allow client to mutate data before injection For example;

    query(gql`
      {
        document
        relationshipUsersMention: relationshipUser(where: { type: 'mention' }) {
          username
        }
        relationshipUsersEmbed: relationshipUser(where: { type: 'embed' }) {
          username
          avatar
          bio
        }
      }
    `).then(data => {
      return {
        ...data,
        relationshipUsers: data.relationshipUsersMention.concat(data.relationshipUsersEmbed),
      }
    });
    

    Which gets it back into the format the deserialisation lib is expecting.
  • Client: Inject resolved data into serialised document
  • Switch to graphql-type-json for the slate document (#685)
• CloudinaryImage block type
  • Move fields/types/Content/views/editor/blocks/image-container.js to fields/types/CloudinaryImage/views/block.js
  • Add support for rendering { data: { publicUrl: '...' } }
• Relationship block type
  • …
• Tests
• Documentation

[MadeByMike]

@jesstelford can we get a status update on the blocks\content editor?

This issue has become really long and hard to track. It looks like the outstanding issues are related to blocks only? I’d like to review this issue and close it.

If there is any outstanding work on the content field type I suggest we consolidate this into a single issue and close these as duplicates: #650, #685, #728. There are also some minor UI inconsistencies that need attention and it would be good to see this captured if we’re making a new issue.

If you don’t have any time for this soon book in a short discussion with me and I’ll see what I can do. I just need your context and history.

[jesstelford]

Yeah, close to that. It wont be as feature rich (to start) - we’ll just be exposing some basic formatting + relationships to other types for now. But ideally we’ll build it in such a way it can be used to generically describe any kind of “thing” that exists within the content 👍