Currently content components (reusable JSON that can be add/removed via the CMS) are identified solely by their key structure. In other words, the structure of the component's _defaults.json acts as a sort of signature to define which component is currently placed on the page, and this in turn informs which field widget overrides (defined via _schema.json) should be applied if they exist. The intention was to simplify the developer experience so they didn't need to manage ID's and keep the data structure entirely flexible with no required keys or fields that mean specific things (e.g. making a title field required or something). The obvious issue is that key structure could have conflicts between components and the CMS would not be able to determine which component is present.

To demonstrate a conflict, a news article component could look like:

{
  "title": "News",
  "body": "Describe news here",
  "date": "1/1/26"
}

An event component might also look like:

{
  "title": "Event",
  "body": "Describe event here",
  "date": "1/1/26"
}

This would be a conflict for the CMS and it would not know which component is which by analyzing the key structure - it does this in order to determine which field widget overrides provided via _schema.json to apply.

Currently, to get around this you could add variation to the keys to make them more specific:

{
  "news_title": "News",
  "body": "Describe news here",
  "date": "1/1/26"
}

and

{
  "event_title": "Event",
  "body": "Describe event here",
  "date": "1/1/26"
}

However, this is not obvious and requires awareness of Plenti's internal key matching mechanism.

An improved future approach could be to automatically generate ID's for components behind the scenes, place them in the JSON source when adding them to the page but don't display them on the frontend editor. The problem here is if manually scaffolding out a page with pre-populated components via the JSON directly, the developer would need to add these ID's themselves, which is something I wanted to avoid initially. Maybe this proposal needs more thought.... I'll leave it here as a placeholder for now. Another option could be flagging component conflicts during the build process and adding short help text to the terminal explaining what to adjust.