Enable `_label` field to specify its GraphQL dependencies

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)

[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.

[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?)