tinacms: Cannot use different types for the fields (with the same name) in multiple templates

Description

When you have a field that has the same field name of another field in another template, the build will fail if the fieldType doesn’t match exactly.

Originally logged here by @Perni1984 .

Steps to reproduce

Create the following field:

        {
          type: "object",
          label: "Foo",
          name: "foo",
          templates: [
            {
              label: "Blog Posts",
              name: "post1",
              fields: [
                {
                  type: "string",
                  label: "title",
                  name: "title",
                  required: true,
                },
              ],
            },
            {
              label: "Blog Posts",
              name: "post2",
              fields: [
                {
                  type: "string",
                  label: "title",
                  name: "title",
                },
              ],
            },
          ],
        },

^ One is required, one is not

Expected result

Build should pass (Not exactly sure what the types would look like to allow this)

Actual result

Build fails with:

Error 3: GraphQLDocumentError: Fields “title” conflict because they return conflicting types “String!” and “String”. Use different aliases on the fields to fetch both if this was intentional.

Environment

Tinacms Package Versions

├── @tinacms/cli @0.61.9 ├── tinacms@0.69.4

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 23 (19 by maintainers)

Most upvoted comments

@jeffsee55 imho the most straightforward option to solve this would be the ability to support aliases in the tinacms schema. With this people have the ability to solve this immediately when the situation occurs. The Alias should then be picked up by the autogenerated client (see https://discord.com/channels/835168149439643678/835172431836479508/900617826572836904).

Eg. something like

        {
          type: "object",
          label: "Foo",
          name: "foo",
          templates: [
            {
              label: "Blog Posts",
              name: "post1",
              alias: "post1"
              fields: [
                {
                  type: "string",
                  label: "title",
                  name: "title",
                  // use an alias to avoid conflicting fields
                  alias: "requiredTitle",
                  required: true,
                },
              ],
            },
            {
              label: "Blog Posts",
              name: "post2",
              fields: [
                {
                  type: "string",
                  label: "title",
                  name: "title",
                },
              ],
            },
          ],
        },

For us this is a real blocker aswell and we try to “avoid” templates whenever possible (as you don’t know beforehand when you run into such a situation as the schema can change due to client requirements). We’re missing out an important feature of tina I guess. As the autogenerated client is now more usable and stable than it was several month ago it is our go to strategy for querying tina and not using any self written queries.

FYI there are other graphql clients that are using some automagic to avoid that problem (and also more info why this was done in the spec you’ll find here https://github.com/dillonkearns/elm-graphql/issues/95) - but I think we don’t need to overcomplicate things here, just to have a bit more control on the autogenerated client generation and being able to fix this problem ourselves when it occurs without having to write custom queries by hand.

Perni1984 on Sep 8, 2022