Change Details

### Background Currently, data for table rows can be passed into the Table component via the `data` prop. This must be an array of objects, with each object being the data for a single row. However, this will not work for a table that needs both row selection and sorting. The Table component and its parent keep track of which rows are selected by referencing the selected rows' indexes in the `data` prop. If the `data` prop changes due to sorting, the indexes no longer tell us which rows should be selected. ### Solutions To fix this, we will need to do one of the following: #### Require a special property in each row This solution would require dev users who want both sorting and row selection to add a property to each TableRow with a unique ID, that can be used (if present) within the Table code to identify which rows are selected (instead of the row's index within the `data` prop array). We should probably not use `id` as the special property name, since that could feasibly be a column ID (we have such an example in our sandbox demos). Instead, it would need to be more unique, like `rowIdentifier` or `cdxRowId` or something. Pros: - Doesn't require us to completely refactor the way the `data` prop is handled - No confusion for the average Table user over how to structure the `data` prop (it's always an array of TableRows) Cons: - The burden is on the dev user to add this property - Need to avoid a collision with any possible column IDs Potential variation on this solution: we add the unique identifier to the rows inside the Table component if both sorting and row selection are enabled. We'd need to consider how this would work with the two-way data binding - is this easier on the dev user, or is it better for them to explicitly assign the unique IDs? #### Allow `data` to be an object For this solution, we would update the `data` prop to also accept an Object of TableRows keyed on a unique identifier. This will also require some fairly gnarly handling inside Table to output each table row in the template, while using the unique key for row selection instead of the row index. Pros: - No extra burden on the dev user, other than requiring them to have their data keyed on a unique ID - Would open the door for other use cases where it's easier to pass in an Object of rows keyed on IDs Cons: - Would make the Table component much more complex and difficult to maintain - Could be confusing to users that there are 2 formats to pass in `data` --- ### Acceptance criteria - [] Decide how to handle this - [] Implement the solution - [] Add/update unit tests as needed - [] Add a demo to the Sandbox showing how this works - [] Add a note to the docs site in the "row selection" demo section discussing how to pass in data when you want both sorting and row selection

### Background Currently, data for table rows can be passed into the Table component via the `data` prop. This must be an array of objects, with each object being the data for a single row. However, this will not work for a table that needs both row selection and sorting. The Table component and its parent keep track of which rows are selected by referencing the selected rows' indexes in the `data` prop. If the `data` prop changes due to sorting, the indexes no longer tell us which rows should be selected. ### Solution Dev users who want both sorting and row selection will be required to add a property to each TableRow with a unique ID, that can be used (if present) within the Table code to identify which rows are selected (instead of the row's index within the `data` prop array). As Roan suggests in the comments, we can use a symbol for this special row property. --- ### Acceptance criteria - [x] Decide how to handle this - [] Implement the solution - [] Add/update unit tests as needed - [] Add a demo to the Sandbox showing how this works - [] Add a note to the docs site in the "row selection" demo section discussing how to pass in data when you want both sorting and row selection

### Background Currently, data for table rows can be passed into the Table component via the `data` prop. This must be an array of objects, with each object being the data for a single row. However, this will not work for a table that needs both row selection and sorting. The Table component and its parent keep track of which rows are selected by referencing the selected rows' indexes in the `data` prop. If the `data` prop changes due to sorting, the indexes no longer tell us which rows should be selected. ### Solutions To fix this, we will need to do one of the following: #### Require a special property in each row This solution would require dDev users who want both sorting and row selection will be required to add a property to each TableRow with a unique ID, that can be used (if present) within the Table code to identify which rows are selected (instead of the row's index within the `data` prop array). We should probably not use `id` as the special property name, since that could feasibly be a column ID (we have such an example in our sandbox demos). Instead, it would need to be more unique, like `rowIdentifier` or `cdxRowId` or something. Pros: - Doesn't require us to completely refactor the way the `data` prop is handled - No confusion for the average Table user over how to structure the `data` prop (it's always an array of TableRows) Cons: - The burden is on the dev user to add this property - Need to avoid a collision with any possible column IDs Potential variation on this solution: we add the unique identifier to the rows inside the Table component if both sorting and row selection are enabled. We'd need to consider how this would work with the two-way data binding - is this easier on the dev user, or is it better for them to explicitly assign the unique IDs? #### Allow `data` to be an object For this solution, we would update the `data` prop to also accept an Object of TableRows keyed on a unique identifier. This will also require some fairly gnarly handling inside Table to output each table row in the template, while using the unique key for row selection instead of the row index. Pros: - No extra burden on the dev userAs Roan suggests in the comments, other than requiring them to have their data keyed on a unique ID - Would open the door for other use cases where it's easier to pass in an Object of rows keyed on IDs Cons: - Would make the Table component much more complex and difficult to maintain - Could be confusing to users that there are 2 formats to pass in `data`we can use a symbol for this special row property. --- ### Acceptance criteria - [x] Decide how to handle this - [] Implement the solution - [] Add/update unit tests as needed - [] Add a demo to the Sandbox showing how this works - [] Add a note to the docs site in the "row selection" demo section discussing how to pass in data when you want both sorting and row selection