Handling relational data when filtering/faceting tables

[donaldharvey]

I'm working on a table that has a lot of relational data and I'd like to implement column filtering and faceting based on related objects and their IDs. I've not found much in the docs or examples about how to handle this, so I'd like to get the community's thoughts.

Consider these example rows:

[
  {
    "id": 1,
    "name": "John Doe",
    "age": 30,
    "city": "New York",
    "country": "USA",
    "company": {
      "id": 1,
      "name": "Acme Inc",
      "industry": "Tech"
    }
  },
  {
    "id": 2,
    "name": "Jane Smith",
    "age": 25,
    "city": "Los Angeles",
    "country": "USA",
    "company": {
      "id": 2,
      "name": "Acme Inc",
      "industry": "Health"
    }
  }
]

Let's say I had a Company column which displays the company name, and wanted to add faceting and filtering to it. In the filter/facet dropdown, I would want to show the company name, but would want the data above to display as two different companies. When the user selects a company, I would want to filter based on the ID and not the name.

There are three options I can see for the accessor in the column def:

1. company (the whole company object)
2. company.name
3. company.id

Option 1 uses non-primitive values in the accessor, which doesn't seem like a good idea, and the default faceting functions won't work with it.

If we use company.name as the accessor, then column.getFacetedUniqueValues() would return company names, which displays names in the dropdown but doesn't let us display the two companies with the same name as distinct filter options.
If we just use company.id, then the dropdown will just return numeric IDs, which is not user-friendly.

The approach I'm currently using is to use company.id as the accessor and then call a memoized function getFilterDisplayMap(table, column) in my dropdown component to return a mapping between IDs and names that can then be used in the filter dropdown. While this works fine, it seems like this use case is common when working with relational data, and could be better supported by the library directly.

Have I missed anything? Is there a better way to handle this case?