Help with subRows (or subComponents) with different types than the original row

[javed24]

My main use-case is this: for each row in my table, if a certain condition satisfies, then I'll need to make the row expandable. This expanded row will have a (totally) different set of fields than the original row. For instance,

instead of the subRow or the subComponent having the same set of fields as the original row (as shown in the example),

my table will have a different set of fields (AND columns) in the subRow/subComponent -

In terms of the data, the list for the expanded/sub row will be a field within the root-level of the original object. So something like the following -

type MyDocument = {
  user_name: string;
  signup_date: string;
  organization: {
    organization_name: string;
    profile_name: string;
  };
  status: string;
  contact: {
    name: string;
    title: string;
  };
  additional_documents?: AdditionalDocument[]; // this will be the subRow/subComponent
};

type AdditionalDocument = {
  initial_date?: string;
  request_date?: string;
  previous_company?: string;
  organization: {
    organization_name: string;
    profile_name: string;
  };
  status: string;
  contact: {
    name: string;
    title: string;
  };
};

I initially went with the expanded rows API's but quickly realized that this particular case probably corresponds more to the "subComponents" approach. However, what I'm basically stuck on is the fact that this particular use-case also requires to have a different set of columns for that expanded rows and so I don't think simply passing {renderSubComponent({ row })} as shown in the example is going to work. For folks who have come across a case like this before, how did you end up working around this?

[cpotey]

Having this exact problem now - and really struggling to come to a good solution.

Did you manage to get anywhere with this, as I feel like I'm at a point where I might need to seriously rethink design ideas because of it.

I could look to use the custom expanding functionality, but I still need all the "sub" data to be filterable still - which I don't believe it will be if I looked to use that, instead of the default subrows functionality.