Portable Text – JSON rich text specification for content editing platforms

Re:Portable Text – JSON rich text specification for content ... by specialist on Wednesday December 05, 2018 @04:54PM (#18613009)

Why this?

  {
   "_key": "a-key",
   "_type": "markType"
  }

And not this?

  {
   "a-key": "markType"
  }

Why this?

  {
   "style": "h1",
   "children": []
  }

And not this?

  "h1": {
   "children": []
  }

[ Parent | on HN ]

Re:Portable Text – JSON rich text specification for content ... by atombender on Thursday December 13, 2018 @03:15PM (#18675626)

The _key is an ID, not a key as in "JSON key". It's metadata.

"style" is optional, so it doesn't make sense for "h1" to be a key.

More importantly, JSON is harder to work with when a key can be anything. A schema is more uniform and easy to make strict if all keys are reserved. This also makes it easier to map to data structures used in languages that have struct-type types. Think of the JSON objects here as structs, not key/value pairs:

  type Block {
    Style string
    Children []Block
    Type string
  }

or whatever.

[ Parent | on HN ]

Re:Portable Text – JSON rich text specification for content ... by bryanrasmussen on Wednesday December 05, 2018 @06:34PM (#18613880)

but what if you have to do this: "h1": { "children": [] }, "h1": { "children": [] } which can't be done because JSON?

[ Parent | on HN ]

Re:Portable Text – JSON rich text specification for content ... by dreamer_soul on Wednesday December 05, 2018 @04:59PM (#18613059)

Maybe parsers would have a better way of parsing that into a sensible datatype for example look at Gson where you map a json to a Java class, that way you can have a node where you can query if it is H1 or not.. That's just off of my head maybe I'm wrong

[ Parent | on HN ]