GraphQL + Shared Slices Variations support

Developing with Prismic
1

Slicemachine People! We need your opinion!

Hey guys, as you all know, we're close to supporting variations for Shared Slices in Slicemachine.
We also want to support GraphQL and that's something we're currently working on, but we have something needs your attention and input.
We have a dilemma on graphQL (and graphQuery) in term of syntax for shared slices:
There are 3 solutions

  • Make it flat, but it can get messy since you need to specify all the fields of all the variations in the same spot
    query {
      allPages {
        edges {
          node {
            body {
              ... on MySharedSlice {
                variation
                primary
                items
              }
            }
          }
        }
      }
    }
  • Switch on variations inside a slice: that one is the perfect representation of what is actually going on but it makes it huge to build
query {
  allPages {
    edges {
      node {
        body {
          ... on MySharedSlice {
            variation {
              ... on Variation1 {
                primary
                items
              }
              ... on Variation2 {
                primary
                items
              }
            }
          }
          ... on MySlice2 {
            primary
            items
          }
        }
      }
    }
  }
}
  • Merge Slices and SharedSlices + Variation on the same level to make it look simple even though there are as many cases
query {
  allPages {
    edges {
      node {
        body {
          ... on MySharedSlice_Variation1 {
            primary
            items
          }
          ... on MySharedSlice_Variation2 {
            primary
            items
          }
          ... on MySlice2 {
            primary
            items
          }
        }
      }
    }
  }
}

What do you think would be best and easiest to understand?

Thanks.

9

#3 makes the most sense to me - keep each slice variation at the same level with the descriptive name that includes the variation name. #2 seems crazy.

I understand the way slices work currently and I like the idea of shared slices. But honestly, I'm not sure why I would need to have a variation of shared slices? Doesn't the original way slices work cover that use case?

10

@john1 3 will mix both original Slices + Variations of Shared Slices, it's not only variation that you'll see in this switch.
I'm scared that it's too many things at the same time that would lost any given new Prismic User.
#2 on the other side is more verbose but matches exactly what you define in your model and seems more intuitive to me since you can completely identify entities based and what you built for your components.

About Variations, It's not meant to create two completely different components like a Header and a Footer but more like a banner with a call to action and a banner without.
It would share 99% of the model, most probably the same Component in your code, it would just be a slight change.
For the editor both would be referenced as banner with with Variations and not 2 complete different components in the page.

11

I guess I can see it now, #2 or #3 would both be workable to reason out. #1 seems inconsistent with the underlying data model.

I still think the biggest issue with your GraphQL setup is the inability to query inside groups. This is a major limitation in my opinion: it really limits relational logic between types which is a foundational concept in building a CMS.

12

#2 and #3 make sense reading them for the 'first' time.

With the first query, is the option still there to pick the data in the variation? It doesn't make sense if it will be an array or a duplicated object structure of the variation.

The last two are more clear to me as to what data I would be asking for and what to expect to come out. Like if the project moved onto another dev to continue maintenance, they wouldn't have to try an figure what data would be coming into the slice.

13

This issue has been closed due to inactivity. Flag to reopen.