[Meta] Admin UI Searching

There are a number of suggested improvements / open issues for searching in the Admin UI. This issue to collate & organise them.

• #352 Add support for filtering by relationship fields in the admin UI
• #319 Full-text list filters (aka. “simple search”)
• #2613 Search bar in UI Admin List view doesn’t work
• #2605 Scrolling and Searching for referenced data
• #1654 Knex adapter doesn’t implement the search condition
• #640 Relationship Select only queries a list’s name field
• #343 Implement configurable search fields

[JedWatson]

😍 love your concept mockup @jesstelford

(to be explicit we’d definitely not want to actually overload the select that much 😅 putting the field pills below the select would work though)

I’d like to propose a first solution here, based on what’s worked in Keystone Classic for years:

(prerequisite opinion: we should never default the search to all text-like fields because in certain schemas this is a serious perf foot-gun; the default should lean to less intensive queries until the author explicitly expands the field set being searched)

The search input defaults to

• the name field if it is defined, and is a Text(-type) field
• the id field as an exact match otherwise

You can provide a searchFields config on the List which contains one or more paths of Text(-type) fields or false to turn the feature off entirely (this would need support in the Admin UI, and can happen separately)

So if I had the following list:

keystone.createList('User', {
  searchFields: ['name', 'email'],
  fields: {
    name: { type: Text },
    email: { type: Email },
    bio: { type: Text },
  },
});

The search would be have similar to what @jesstelford suggested above:

query relationshipSearch($query: String) {
  Users(where: { OR: [
    { id: $query },
    { name_contains_i: $query },
    { email_contains_i: $query },
  ] }) {
    id
    _label_
  }
}

Given case-sensitive and -insensitive queries can have significantly different performance characteristics we could expand the syntax to allow specifying sensitive/insensitive clauses, but I’d treat that as an enhancement.

When the list is constructed, the searchFields would be validated against the defined fields and we’d throw an error if any of the field paths provided are invalid or not text type fields.

note: I’m not sure we have any way at the moment of easily identifying that a field is compatible with a specific type; which is why I’ve said “Text(-type)” fields above. Ideally for, e.g an Email field, we would have a way of saying “this is functionally compatible with a Text field”. OR some way of knowing which generic input fields are supported in the gqlQueryInputFields implementation, would achieve the same effect here.

[jesstelford]

From @timleslie

{ id: $query }, won’t work with a String argument. We’ll have to think about how to manage those, but I’m sure it’s solvable.

Taking my idea of “push that to the field itself”, perhaps we could have something like this:

class TextView extends View {
  getGqlSearchInput() {
    return '$textValue: String';
  }

  getGqlSearchVariables(value) {
    return {
      textValue: value
    }
  }

  getGqlSearchWhereClause() {
    return `{ OR: [
      { ${this.path}_startsWith_i: $textValue }
      { ${this.path}_endsWith_i: $textValue }
     ] }`;
  }
}

class IdView extends View {
  getGqlSearchInput() {
    return '$idValue: ID';
  }

  getGqlSearchVariables(value) {
    return {
      idValue: value
    }
  }

  getGqlSearchWhereClause() {
    return `{ ${this.path}: $idValue }`;
  }
}

Then in the AdminUI, it would execute something like:

const uniqueFields = uniq(fields, field => field.type);
const inputs = uniqueFields.map(field => field.getGqlSearchInput()).join(', ');

const where = `{
  OR: [ ${fields.map(field => field.getGqlSearchWhereClause()).join(', ')} ]
}`;

const data = await query(
  `
    query search(${inputs)) {
      all${listName}s(where: ${where}) {
        id
      }
    }
  `,
  variables: Object.assign({}, ...uniqueFields.map(field => field.getGqlSearchVariables(searchTerm))),
);

Which would be the equivalent of:

const data = await query(
  `
    query search($textValue: String, $idValue: ID) {
      allUsers(where: { OR: [
        { id: $idValue }
        { OR: [
          { name_startsWith_i: $textValue }
          { name_endsWith_i: $textValue }
         ] }
      ] }) {
        id
      }
    }
  `,
  variables: { idValue: searchTerm, textValue: searchTerm },
);