Importing content into the Rich Text field about contentful-cli HOT 4 CLOSED

Ok, thanks, I appreciate you taking the time to clarify this for me - I just wanted to make sure I hadn't missed anything obvious (as I'm clearly coming in to contact with HTML structured tree data a lot later than you guys).

from contentful-cli.

Hey @openbook,

We're currently working on a markdown-to-rich-text app, also. Until that's ready I can share some code snippets that demonstrate how we use remark-parse that might be useful to you.

Basically all the content for the rich text field is in the children of the result of processor.parse(). You have to iterate through each child and manually construct the rich text nodes according to the rich text schema.

Unfortunately a comprehensive rich text schema isn't quite public (beta feature :) ). From our community slack yesterday, the rich text PM wrote:

this is information that we have in some private repos but we are discussing on what is the best way to offer them to the public (documentation, or in the NPM readmes).

For now, to help you get moving, the list in the https://www.contentful.com/developers/docs/concepts/rich-text/ page is almost accurate: Add EMBDEDDED_ASSET to the list of blocks and you’re done

The other thing I can suggest is to create a rich text field manually in the Contentful web app, query for it using our APIs/SDKs, and examine the result, the way you've already done.

Here's a snippet from our forthcoming markdown-to-rich-text project (will be made public soon):

'use strict';
var unified = require('unified')
var markdown = require('remark-parse')

[...]

const nodeToSlate = (node) => {
  const nodeType = nodeTypeFor(node)
  const nodeContent = nodesToSlate(node.children)
  let nodeValue = node.value
  const nodeData = dataFor(node)

  if (nodeType === 'text') {
    let marks = []
    if (node.type !== 'text') {
      nodeValue = node.content ? node.content[0].value : node.value
      marks.push({
        type: markTypeFor(node),
        object: 'mark',
        data: {}
      })
    }
    return {
      nodeType: nodeType,
      value: nodeValue,
      marks: marks
    }
  } else {
    return {
      nodeType: nodeType,
      content: nodeContent,
      data: nodeData
    }
  }
}

const nodesToSlate = (nodes) => {
  if (!nodes) return []

  return nodes.map((node) => {
    return nodeToSlate(node)
  }).filter(Boolean)
}

const treeToSlate = (tree) => {
  return {
    nodeType: 'document',
    content: nodesToSlate(tree.children)
  }
}

module.exports = function (md) {
  const processor = unified().use(markdown, { commonmark: true })
  const tree = processor.parse(md)

  return {
    tree,
    slate: treeToSlate(tree)
  };
}

This is slightly out of date, but hopefully it demonstrates what I described above. We first create the 'document' node (in treeToSlate function), then for each child we determine its node type and create the according rich text node, adding to our tree (in nodeToSlate function).

from contentful-cli.

Thanks for your response, the technical solution makes sense. But, just so I understand this a bit better, am I correct in saying you've created, or are in the process of creating, a custom rich text schema for Contentful or is this an existing format? If it is custom, what prompted that choice rather than using HAST?

from contentful-cli.

Hello @openbook ,

I am the aforementioned PM and, while I would like to offer you a list of reasons why we didn't implement HAST, the plain truth is that our technical research on web editors and their underlying schema missed this AST proposal. Which is a pity, because this looks very close to what we have created (I haven't evaluated if custom node types such as Contentful Entries would be implementable with this yet, so I'm only judging by a first look) and I also see some familiar to Contentful names, such as K.Mathews, in the contributors list.

If it offers any proximal explanation to our decision, our research was revolved around popular Rich Text Editors, such as ProseMirror (we based our Markdown editor on CodeMirror), SlateJS, MobileDoc, QuillJS, DraftJS–for the record we landed on SlateJS on existing architectural compatibility grounds but the Contentful-based schema should allow us to switch the Editor in the future.

Moving forward, as we already have people using this editor and a schema change would be a breaking change, I can't promise that we will change our schema to HAST but we might consider offering a converter to these standards.

I hope I answered your question as well I could do and I'd be happy to provide more information if needed.

from contentful-cli.