Can’t use payload in admin.condition function of field, can’t use async/await, can’t create options for select field dynamically

[robinscholz]

Link to reproduction

No response

Payload Version

beta

Node Version

20.15.1

Next.js Version

15.0.0-rc.0

Describe the Bug

We are trying to either conditionally render the options of a select field or render the whole field conditionally based on siblingData from a relationship field. Since the siblingData only show a number for the relationship field, we would need to fetch the related collection entry to get its “slug” to decide if the field should be rendered.

The options seems to be static, so we tried to create multiple fields for each set of options and render them conditionally. Sadly the information given within the condition function arguments is not sufficient. It also appears that the condition field won’t take an async function.

Another solution would be if payload would allow the depths of the given data and sibling data to be configured somehow.

Reproduction Steps

export const maasRouteField: SelectField = {
  name: 'route',
  type: 'select',
  options: ['/', '/products/'],
  admin: {
    position: 'sidebar',
    condition: async (_data, siblingData) => {
      console.log('siblingData:', siblingData, payload)

      return await payload.findByID({
        collection: 'tenants',
        id: siblingData?.tenant,
      })
    },
  },
}

Adapters and Plugins

No response

[jmikrut]

Hey @robinscholz — right now, this is deliberate, but I think we could potentially change this in the future. The thing is that conditional logic runs very frequently and should be heavily optimized so that your UI doesn't slow down. Generally, querying on data in a condition will add latency to the function and that would slow down the reactivity of the conditions themselves.

Instead, what we normally do here is add a virtual field to the field schema that you need to run your condition against, and in that virtual field, populate the slug or whatever field you need from your related item into that virtual field - then run your condition against that field instead. In this case, your virtual field could have a custom UI component that fetches the related item one time and stores the related item's field in its field in the form state. That would be way more performant.

Does that make sense? I will convert this to a Feature Request so that we can evaluate others' interest in supporting the Local API inside conditions, but generally, you probably don't want to do this. You want to find a pattern to fetch that related data one time, and then use it accordingly rather than fetching it every time the condition runs (which is a lot).

[robinscholz]

Thanks for the quick reply! Seems like I am running into a different bug when trying to use payload to populate a virtual field.

Error: The collection with slug tenants can't be found. Find By ID Operation.

const getTenantSlug: FieldHook = async function ({ data }) {
  const tenant = await payload.findByID({
    collection: 'tenants',
    id: data?.tenant,
  })

  if (tenant) {
    return tenant.slug
  } else {
    return undefined
  }
}

export const tenantSlugField: TextField = {
  name: 'location',
  label: false,
  type: 'text',
  hooks: {
    beforeChange: [
      ({ siblingData }) => {
        // Mutate the sibling data to prevent DB storage
        // eslint-disable-next-line no-param-reassign
        siblingData.tenantSlug = undefined
      },
    ],
    afterRead: [getTenantSlug],
  },
  access: {
    create: () => false,
    update: () => false,
  },
  admin: {
    hidden: true,
  },
}

In general I’d argue that the best solution for the select field would be if the select field options could take a function that has access to data as well as sibling data and maybe the user just like the conditions function. On top of that it’d be great if I could configure how deep the data would be unraveled, either globally in the payload config or even better granularly for that field. Not sure how feasible this would be with the current architecture though.

Anyways, appreciate the lengthy answer regarding the topic!

[builtbymax]

heyho, just wanted to hop in here - i know this discussion aged a bit but now with the release of the 3.0 version maybe this feature-request can be looked at again?

I stumbled upon this as I wanted to request the uploaded media to check the mimeType if it's video or image. To have a collapsible shown with video controls if mimeType is the video one.

Would be cool if someone can have a second look here after the time was passing a bit :)