How to fetch specific fields in a non-deprecated way

Developing with Prismic
, ,
1

Hello,

We have a quite large custom type which is used on a lot of pages, but some pages only need one or two fields from this document, so we thought it would be smart to only fetch what is needed.

I had planned to use fetch param for this, but upon checking the docs saw it has been deprecated in favour of graphQuery Content API Reference — Prismic Docs

Unfortunately, from what I can tell graphQuery has also been marked as deprecated, and the docs actually suggest you use fetch instead, which is obviously also deprecated Content Relationship — Prismic Docs

I then thought I could use GraphQL to work around this, only to find out that you are seemingly unable to fetch group fields within a slice via GraphQL GraphQL API Technical Reference — Prismic Docs

To query a field in a slice, add the field’s API ID inside primary if it’s in the static zone or fields if it’s in repeatable zone (deprecated).

Questions

  1. Is it possible to fetch specific fields from a document in a non-deprecated way, including group fields within a slice?
  2. If it must be done in a deprecated way - what is the best option?
  3. Are there any plans to add the ability to fetch group fields within a slice via GraphQL in the future, or reinstate some form of the fetch param?
1 Like
2

Hi Connor,

Welcome to the community!

Non-deprecated options today:

  • GraphQL: Select exactly the fields you need from each type and from a slice’s primary zone.

  • Modeling tweak: If you need selective fields from repeatable items, move those fields into the slice’s primary (or link to a small “summary” document via a Content Relationship and choose allowed fields there).

We understand this isn’t ideal right now. If selective fetching for repeatable slice items is critical for your project, please share your specific use case. We can pass the feedback to our dev. team.

In the meantime, you can experiment with queries in the API Explorer to see exactly what the current responses look like and refine what you select from primary: https://your-repo-name.prismic.io/builder/explorer.

3

Hello,

Thanks for you reply

I'm unable to use GraphQL as a solution due to the inability to fetch group fields from slices, here is an example GraphQL query where I've commented out some group fields that I would like to fetch, I hope this explains it?

No matter how I try to query it, I always get an error saying the field does not exist. The Documentation Explorer also backs this up as all the group fields are missing from the types.

I'm a bit confused by your modelling tweak suggestion - these group fields are already within the slices primary section. I was under the impression that the old repeatable zone for slices had been deprecated in favour of group fields? (sorry don't think I made this very clear in my original post)

We've considered content relationships to other documents for this, but we are of the opinion that it would be more confusing for content editors and is unnecessary complexity for something that should be relatively simple with a GraphQL query, or even simpler with the old fetch param which has been deprecated.

4

Hi,

Why has fetch been deprecated when there’s no true successor to it?

5

Hi Connor,

Thanks for clarifying, most likely you’re seeing something similar to this, yes?

{
  "slice_type": "example_slice",
  "primary": {
    "title": "…",
    "items_group": [
      { "field_a": "…", "field_b": "…" },
      { "field_a": "…", "field_b": "…" }
    ]
  }
}

If so, technically those groups live under primary, but they’re still group fields (nested another layer down).

Right now, there isn’t a fully non-deprecated way to selectively fetch those group fields. The main workaround is to restructure your model (move fields up into primary or split them into linked docs). I understand this creates trade-offs for editors, which is why your feedback is valuable.

You’re not missing anything as this is a current limitation. If you’d like to add or share your use case we can pass this along to our product/dev team so they have more context on how this impacts projects.