Dynamic config based on siblingData

[JarrodMFlesch]

I have run into a few scenarios where I would love for the config to be dynamic, I may not want to completely hide the field, but instead I would just like to adjust some of its properties.

One example I have is with the following fields config:

fields: [
  {
    name: 'media',
    label: 'Media',
    type: 'array',
    minRows: 1,
    maxRows: 3,
    fields: [
      {
        name: 'media',
        label: 'Media',
        type: 'upload',
        relationTo: 'media',
        required: true,
      },
    ]
  },
  {
    name: 'imagePlacement',
    label: 'Image Placement',
    type: 'select',
    conditional: (_, siblingData) => siblingData?.media?.length > 1,
    options: [
      // only options if siblingData.media.length === 2
      {
        label: 'Stacked Vertically',
        value: 'stackedVertically',
      },
      {
        label: 'Stacked Horizontally',
        value: 'stackedHorizontally',
      },
      // only options if siblingData.media.length === 3
      {
        label: 'Two On Left',
        value: 'twoOnLeft',
      },
      {
        label: 'Two On Right',
        value: 'twoOnRight',
      },
    ]
  },
]

The idea here is to disallow the user from selecting a value that does not make sense, without needing to create two separate fields that I show/hide conditionally as this would clean up my api response and front end code a little. So if the user adds 3 images, the imagePlacement options would be different that if they were to only add 2 images. I was also thinking this could be done another way (with a similar approach) where you let the user select from imagePlacement and then dynamically adjust the media array's minRows value based on the selected option.

For now, I have sidestepped this issued by creating two separate fields and hiding/showing each one based on the number of media elements added.

Anyone else have any use cases? Is there a better approach to something like this?

[Ontopic]

Would love some extra options to achieve this as well. For I cam up with creating a custom component and then using Payload's React hooks - the hooks you can import from payload/components/forms, listed at https://github.com/payloadcms/payload/blob/929b21d68b9d4504adf2d46ccca74d8da5595179/components/forms.ts - and storing JSON stringified data

[DanRibbens]

I don't think there is a one correct way here. I can see both cases being made depending on the project of either allowing the content authors to make presentational choices in their workflow, or automating content flow decisions for them as you've done.

I've done something similar where content blocks in a page are an array of blocks that impose the layout choices for the author to choose layout structures before entering the content. Then also adding options for the child content as a second layer of designing, with checkboxes or selects to give components control over for things like alignment, inverting color scheme, etc. I think it is a reasonable abstraction for most people to understand and manage while giving them a lot of power and autonomy to create. The main downside is maybe that if one wanted to say change a two-column group to one-column, the user would have to delete already entered content when they remove the parent layout and re-enter the child elements after picking the new layout. Also, the editor needs to have to think a little about the presentation flow and cannot just blindly enter content.

With your fluid approach of dynamically making layout decisions for authors, I would expect more developer effort as you need to impose the restrictions with min and maxRows, validation and conditions to be sure the content that the editor can create still works within the frontend design system you build. Going this route, I would advise to keep it as simple as you can to avoid endless dev time in validating that the allowed content structures cannot break the presentation in any way. Users always find ways to input the unexpected and they will surely let you know how your tools are "broken". It would be nice if it does work out well, and it could be really powerful.

This is a good discussion topic and I'm curious what you decide to do and what others think.

[JarrodMFlesch]

@jmikrut I was thinking the same actually. Creating a custom component would probably allow me to do more anyways, since I could create simple icons to depict the layout of the media block which would provide overall better UX for my purpose here. Then the user could click the icon and I could store the value of it.

[JarrodMFlesch]

@jmikrut ok so I'm thinking about this again, I'm not sure what you are suggesting would allow me to do what I am wanting, would it? I'm looking for the Select options to depend on another field, the upload field. How would my Select component access the data of the the Upload field? I understand the custom component part, adjusting what options are given to the imported Select component, but I still don't see how my custom component could access the data from the Upload field.

[jmikrut]

@JarrodMFlesch inside your custom component, you can import { useWatchForm } from 'payload/components/forms', which will give you access to the whole form's context, including ways to access specific fields' current values.

From there, you can use it like this:

const { getDataByPath } = useWatchForm();
const fieldValue = getDataByPath('field-path-here');

Will this do what you need?

[JarrodMFlesch]

@jmikrut I think so! It might be useful to add some of this to the custom component documentation. Thanks for the tip! 🤓

[Ontopic]

Agreed! I was so happy when I found these hooks when playing around with building my own fork. Created quite a few cool features with it.