Propagating 'fields' array programmatically in using groq queries and custom input widgets

18 replies
Last updated: May 5, 2022
Hello!Is there a way to propagate the
array programatically? I am trying to use the data returned from a
query from another document to then create the needed fields.
seems to only set the state of already existing field and I don’t think a
would work. Or if it could I am not sure how. Thanks!
May 5, 2022, 1:47 PM
May 5, 2022, 2:24 PM
I think the canonical way to resolve this at the moment is to have all possible fields defined in the schema, and use the hidden and read only properties defined dynamically based on the groq queries you mentioned.
May 5, 2022, 2:42 PM
user P
thanks for the quick reply. That is also what I am finding. But
can not return a
which is required for the
. Any work arounds?
May 5, 2022, 2:46 PM
I haven’t had the problem you’re describing as I usually believe it
May 5, 2022, 2:48 PM
Can the
callback access all the documents or only the parent?
May 5, 2022, 2:50 PM
I haven’t had the problem you’re describing as I usually believe it’s a sign that I should either• A - Use the block field for a dynamic content, or an array of various fields that the user can pick from.
• B - Create a new schema for the desired purpose.
With that said, I would look into initialValueTemplates - but without intimately understanding why you’re needing this I’m not sure I can help
May 5, 2022, 2:50 PM
Maybe it will help to describe the problem. 😉
One document has a list of languages the user can select. This value is an array of strings.

Then a custom
type would use the value from the previous document to dynamically render the selected languages input elements for the Google Translate plugin.
May 5, 2022, 2:56 PM
It could be a filter solution maybe? But the props from
only give you the document values from the current document so hidden is not an option
May 5, 2022, 2:57 PM
Could you help me understand the relationship between these two documents and why they are seperate?
May 5, 2022, 3:01 PM
is a reusable schema that creates inputs for the Google Translate plugin. It is a custom
. Must be separate.
The other is a basic
with elements of
which uses the above
object type
as their
May 5, 2022, 3:13 PM
Here are some snipets.

fields: [
      name: 'title',
      title: 'Heder Title',
      type: 'localizedString',
      description: 'Page header title'
Custom Google Translate Object Type

const localizedString = {
  name: 'localizedString',
  type: 'object',
  inputComponent: GoogleTranslateInput,
  options: {
  fieldsets: [
      title: 'Translations',
      name: 'translations',
      options: { 
collapsible: true, collapsed: true }
  fields: => ({
    type: 'string',
    fieldset: lang.value === 'en' ? null : 'translations',
    options: {
      list: async () => {
        const selectedLangs = await languages();
        return => !selectedLangs.includes(lang.value))
      layout: 'string'
May 5, 2022, 3:17 PM
const selectedLangs = await languages();
is calling a helper function that is the
May 5, 2022, 3:18 PM
I haven’t ghosted you, in a standup until the top of the hour. will look back when I can focus on it.
May 5, 2022, 3:22 PM
No worries
user P
I appreciate it.
May 5, 2022, 3:25 PM
So I think this plugin maybe the best way to approach my problem. At least is helps depict what I am looking for better. But I was looking to just have a way of doing it thru a separate document for the languages
May 5, 2022, 3:40 PM
Ahh, would you still like help or is this resolving your challenge?
May 5, 2022, 4:02 PM
Well this plugin doc are not great so lets see. 😉
May 5, 2022, 4:06 PM
But I think I am ok for now. Thanks!
May 5, 2022, 4:07 PM

Sanity– build remarkable experiences at scale

The Sanity Composable Content Cloud is the headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Was this answer helpful?