How to Deploy a Shopify Dashboard Template with GraphQL

3 replies
Last updated: Dec 9, 2021
Hey friends,
I’ve been experimenting with Sanity Connect, the Shopify template and (our version of) Hydrogen today and managed to get your template dashboard running with our sync’d store. I wanted to rely on Sanity’s idea of “right” so I created the studio from within Shopify and attempted to deploy your boilerplate graphql for use with some new components in our Hydrogen repo. It didn’t work straight up, and as the Shopify dashboard template is likely still a WIP I thought it’d be useful to flag the things I had to do to get the schema deployed.

Lifted all problematic inline object definitions (we habitually avoid anonymous objects to protect graphql):
- galleryProduct
- section
- footer
- menu
- linkGroup
- priceRange

Change the settings.ts fields to:

  fields: [
    {
      name: 'menu',
      title: 'Menu',
      type: 'menu'
    },
    {
      name: 'footer',
      title: 'Footer',
      type: 'footer'
    },
    {
      name: 'seo',
      title: 'SEO',
      type: 'seo.standard' // removed your inline seo object
    }
  ],
Removed attributes from options array block in shopifyProduct.ts:

    {
      name: 'options',
      title: 'Options',
      type: 'array',
      of: [
        {
          type: 'productOption' // was 'option' previously
        }
      ]
    },
AI Update

Thank you for taking the time to document these issues! This is incredibly valuable feedback for the community working with Sanity Connect for Shopify and Hydrogen.

You've hit on a fundamental issue when working with Sanity's GraphQL API: anonymous inline object definitions don't translate cleanly to GraphQL. GraphQL requires all types to be explicitly named at the top level of your schema, and when it encounters inline objects, you'll typically see errors like "Encountered anonymous inline object for field/type... To use this field with GraphQL you will need to create a top-level schema type for it."

Your solution of extracting these inline definitions into proper named object types is exactly the right approach:

Inline objects you correctly lifted:

  • galleryProduct
  • section
  • footer
  • menu
  • linkGroup
  • priceRange

In settings.ts, changing from inline object definitions to named type references ensures these types can be properly resolved:

fields: [
  {
    name: 'menu',
    title: 'Menu',
    type: 'menu'  // Named type reference instead of inline definition
  },
  {
    name: 'footer',
    title: 'Footer',
    type: 'footer'  // Named type reference
  },
  {
    name: 'seo',
    title: 'SEO',
    type: 'seo.standard'  // Named type reference
  }
]

For the productOption issue, the change from type: 'option' to type: 'productOption' suggests the template had a mismatch between the inline type name and the actual schema type that should be referenced.

This is a best practice pattern when working with Sanity schemas intended for GraphQL consumption - always prefer explicitly named document and object types over anonymous inline definitions. It makes your schema more maintainable, reusable, and most importantly, compatible with GraphQL generation.

Since the Shopify template is relatively new as part of the evolving Sanity Connect ecosystem, these kinds of adjustments are valuable for others who might hit the same issues. If you haven't already, consider sharing this feedback in the relevant GitHub repository or Sanity's community Slack - it could help improve the template for future users!

Thank you for this
user H
– very useful!
I think we might only have run this with GROQ ourselves and therefore have unhoisted, anonymous objects in the model
No worries! Yeah I’d guessed that might be the case, didn’t take long to shuffle the code around so it’s not a really major issue. That product option change is probably the most dangerous, not yet sure what the implications might be but I’ll probably find out soon…

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?