Keystone: Enable `_label` field to specify its GraphQL dependencies

[jesstelford]

Given a User list:

keystone.createList('User', {
  fields: {
    name: { type: Text },
    posts: { type: Relationship, many: true }
  }
});

We want to display the label as <name> (3 posts).

As it stands today, the labelResolver option doesn't expose any way to get the number of posts:

keystone.createList('User', {
  fields: {
    name: { type: Text },
    posts: { type: Relationship, many: true }
  },
  labelResolver: item => {
    // This will fail because `item._postsMeta` is not set
    return `${item.name} (${item._postsMeta.count} posts)`;
  }
});

Ideally, we'd be able to specify a query snippet which is injected into the item query, something like:

keystone.createList('User', {
  fields: {
    name: { type: Text },
    posts: { type: Relationship, many: true }
  },
  labelFragment: `
    _postsMeta {
      count
    }
  `,
  labelResolver: item => {
    // This will now succeed!
    return `${item.name} (${item._postsMeta.count} posts)`;
  }
});

Gotchyas

• Need to de-dupe the labelFragment from any incoming query
• Need to consider how this will impact Virtual Fields (#1117)

[JedWatson]

Nice

Question: could this also solve the use-case for items that are identified by something they're related to?

e.g given an RSVP in our meetup demo; it really has no identifying information without the user and the event it's linked to.

Could we achieve something like this?

labelFragment: `
  meetup {
    name
    startTime
  }
  user {
    name
  }
`,
labelResolver: item => {
  return `${item.user.name} ${item.status === 'yes' ? 'coming' : 'not coming'} to ${item.event.name} on ${item.event.startTime.format('Do DD/MM/YY')}`;
}

(slight magic there with the format method, just simplifying the example)

[jesstelford]

Yep, that's the exact use-case we're solving for here 👍

(Sorry, some context was lost between talking about this via other channels to opening this issue)

[dcousens]

This issue could be resolved completely using an implementation of https://github.com/keystonejs/keystone-5/issues/1117 - labelResolver would remain as is, using the virtual field.

(this may be apparent if you are reading this in depth)

[jesstelford]

Yes, that's right! We have an immediate need for the labelFragment implementation, so we're going to build it into the special _label field case for now, then that logic will form the basis of the Virtual Fields implementation in #1117 :+1:

[JedWatson]

I imagine that, post #1117, we could reimplement the _label special field as a built-in virtual field that is automatically added to every list.

(background for anyone reading that and wondering "why" without context: the Admin UI needs to be able to make an assumption on how to render an item when it's displayed in various contexts. that's what we use the built-in _label field for. it's a bit of a kludge and more opinionated than most things we do in keystone, but simplifies what would otherwise be a large amount of required configuration. I think I'm open to discussing this down the track if there's a valid use-case for not having it?)

[timleslie]

For additional context I'm currently looking into the actual implementation of this this. The main focus will be on getting the desired behaviour for _label. It is expected that this will inform the full implementation of #1117, but if it turns out the the delta from this specific case to the general case is tiny then I'll do it all in one hit.

[dcousens]

See https://github.com/keystonejs/keystone-5/pull/1296