Unable to deploy schema field with ref and object array

[doublejosh]

trafficstars

When trying to create an array field of objects along with references to that same object the schema will not deploy.

Doing this works fine in the editor UI. It seems like a common case, so perhaps I'm missing something?

Error

Error: Found duplicate type names: Objective
    at ~/ROOT/studio/node_modules/@sanity/core/lib/actions/graphql/deployApiAction.js:156:31
    at Generator.throw (<anonymous>)
    at asyncGeneratorStep (~/ROOT/studio/node_modules/@sanity/core/lib/actions/graphql/deployApiAction.js:7:103)
    at _throw (~/ROOT/studio/node_modules/@sanity/core/lib/actions/graphql/deployApiAction.js:9:291)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Schema example causing the error

    {
      name: "objectives",
      type: "array",
      title: "Objectives",
      of: [
        { type: "reference", to: { type: "objective" } },
        { type: "objective" },
      ],
    },

Screenshot of schema field in editor UI

Sanity version: 2.7.4

Node version: 16

[judofyr]

Doing this works fine in the editor UI. It seems like a common case, so perhaps I'm missing something?

I wouldn't say it's a super common case.objective has type: "document", right? I wasn't actually aware that you could have inline documents inside list. I'll check if there's a simple way to add support for this in the current API.

[doublejosh]

Yeah, objective is a doc.

export default {
  name: "objective",
  type: "document",
  title: "Objective",

Maybe there's a way to create an object that contains either the doc or doc reference... but that seems avoidable.

The bummer workaround is two fields.

[saasen]

If we want to fix this, we need to change how the types are named which would affect everyone with breaking changes.

Before delving into this deeper, could you explain why you want users to be able to add both inline objectives and references to objectives?

[doublejosh]

Thanks! For clarity, users need to either pick from a library of choices or create a one-off.

Two sites...

1. Page sections, create a new section or reference one from a library (day job).

2. Character sheets, reuse a trait or create a unique one (murder mystery fun project).

Right now I have a separate object types for each case above.

[saasen]

I see.

This depends on your content modelling and how your editors want to work, but wouldn't it make sense to only allow references?

I think this is something we won't fix at the moment, due to breaking changes. We are working on improving the GraphQL API, and what we have in mind will solve this problem you are having. I can't give any estimate as to when that will be done, though.

[geball]

@doublejosh Is this issue resolved with the ability to now create references in place?

[doublejosh]

Pretty sure this feature does not exist yet.

Forcing editors to know they must exit document authoring flow to go create some other document, then go back and reference it... but any edits must be back in the referenced doc ...is bad. I can't imagine advocating for this. We haven't implemented references in our page builder, because they can't stack along with objects in a page array.

Seems worth keeping on your roadmap.

[geball]

Okay, thanks for confirming. I'll leave it open.

[struct78]

Having a similar issue related to mixing documents and references. I've yet to work out a way to implement something similar that isn't a complete pain for developers, content authors, or both.

#3357

[kmelve]

This happens because name isn't specified for the array types, which makes the Studio see two types with the same name. This wouldn't work in GraphQL either, since the objects have different signatures.

The way to solve this is to specify name for both (e.g objective and objectiveReference. This will also make it much clearer in the implementation since you have to query differently on these objects.

[kmelve]

By the way, the studio will interpret a document type as a object when used in this way, which is completely fine!