Skip to content

More portable data model (pt. 2) #989

Open
@chrisvxd

Description

@chrisvxd

Description

#984 closed #255 and introduced the slots API as part of 0.19.0, enabling components to be nested in a portable fashion. Backwards compatibility for DropZones was retained, and a migration guide provided.

This ticket follows on from #255, and focuses on breaking changes to make the final switch to a more portable payload, where all nodes (including root) are treated equally.

Proposed changes:

  • Remove data.zones
  • Remove data.content in favor of data.root.props.content
  • Remove DropZone component from public API
    • Consider renaming DropZone to Slot internally to better reflect it's function
  • Addition of type and id to root component

Considerations

  • DropZones are widely adopted
  • Does this also impact the component config? Root is currently defined separately.

Existing data model

{
  "content": [
    {
      "type": "Columns",
      "props": {
        "id": "Columns-1234"
      }
    }
  ],
  "root": { "props": { "title": "Page" } },
  "zones": {
    "Columns-1234:left": [
      {
        "type": "Heading",
        "props": { "title": "Hello, world" }
      }
    ]
  }
}

New data model

{ 
  "root": {
    "type": "Root", // Root now requires type
    "props": {
      "id": "root",  // Root now requires id
      "title": "Page",
      "children": [
        {
          "type": "Columns",
          "props": {
            "id: Columns-1234",
            "left": [
              {
                "type": "Heading",
                "props": { "id": "Heading-1234", "title": "Hello, world" }
              }
            ]
          }
        }
      ]
    }
  }
  // content and zones now removed
}

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions