[data grid] Make it possible to re-use row selection propagation logic for other columns

[toddsmith-adsk]

The problem in depth

I'm syncing a 3D viewer with the MUI data grid. Each row represent an element in the 3D viewer.

I use the selection column to sync selection of items in the 3D viewer and the data grid. But I also need to add another column to sync visibility. That means I need to track a visibility state per row just like selection does. I basically need to duplicate packages\x-data-grid\src\hooks\features\rowSelection but for visibility.

I can't have two seleciton columns acting independently because they would be bound to the same state property.

Also, I'm using the treeData feature of the data grid I also need to handle propagation of the visibility state to parents and children.

Can I extend the apiRef.current.state with more properties? Is that a supported feature?

Your environment

`npx @mui/envinfo`

    System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 18.19.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD   
    pnpm: 9.7.1 - C:\Program Files\nodejs\pnpm.CMD  
  Browsers:
    Chrome: Not Found
    Edge: Chromium (127.0.2651.105)
  npmPackages:
    @emotion/react: ^11.13.5 => 11.13.5 
    @emotion/styled: ^11.13.5 => 11.13.5 
    @mui/base:  5.0.0-beta.69 
    @mui/core-downloads-tracker:  6.4.6 
    @mui/icons-material: ^6.4.6 => 6.4.6 
    @mui/lab: ^6.0.0-beta.29 => 6.0.0-beta.29       
    @mui/material: ^6.4.6 => 6.4.6 
    @mui/private-theming:  6.4.6 
    @mui/styled-engine:  6.4.6 
    @mui/system:  6.4.6 
    @mui/types:  7.2.21
    @mui/utils:  6.4.6
    @mui/x-data-grid:  7.27.2
    @mui/x-data-grid-generator: ^7.27.2 => 7.27.2
    @mui/x-data-grid-premium: ^7.27.2 => 7.27.2
    @mui/x-data-grid-pro:  7.27.2
    @mui/x-date-pickers: ^7.27.1 => 7.27.1
    @mui/x-internals:  7.26.0
    @mui/x-license: ^7.26.0 => 7.26.0
    @types/react: ^18.0.28 => 18.3.14
    react: ^18.2.0 => 18.3.1
    react-dom: ^18.2.0 => 18.3.1
    typescript: ^5.7.2 => 5.7.2

Search keywords: state management

Order ID: 86253

[michelengelen]

Hey @toddsmith-adsk ... If I understand your requirements correctly you would be able to achieve this with a boolean column, right? You can also use a custom cell renderer to render a checkbox instead of the default.

Not so sure about the requirement to propagate the state to parents/children.

@MBilalShafi would you happen to know if we already have an example showcasing this?

[toddsmith-adsk]

@michelengelen Yes, this will be a custom "boolean" column but instead of a checkbox I will use the Visibility and VisibilityOffI icons.

My main question is about managing state. Is adding custom properties to apiRef.current.state a valid solution for the state management of custom grid features? Or do we need to manage a separate state object outside of the grid?

[michelengelen]

@michelengelen Yes, this will be a custom "boolean" column but instead of a checkbox I will use the Visibility and VisibilityOffI icons.

My main question is about managing state. Is adding custom properties to apiRef.current.state a valid solution for the state management of custom grid features? Or do we need to manage a separate state object outside of the grid?

Ok, so I understood correctly. Well, since the rows are a part of the state you would not really need to have your own part of the state. You can just access them from the API.

The interesting part now is how we could build a parent child relation for the rows.

[MBilalShafi]

would you happen to know if we already have an example showcasing this?

This use-case is a bit unusual and pretty interesting too. I don't think we have a recipe for it already.

@toddsmith-adsk Could you clarify a few things about your use-case?

• Have you tried managing the visibility state outside and if there were significant challenges in doing so?
• Do you need to propagate both selection and visibility states to the parent and child rows? If yes how do you plan to show them on the UI, it'd be great if you could prepare a live example to demonstrate it.

I'll try to come-up with a recipe based on your needs.

Is adding custom properties to apiRef.current.state a valid solution for the state management of custom grid features? Or do we need to manage a separate state object outside of the grid?

Technically you could mutate the Data Grid's internal state, but I think it'd be better to keep the added functionality in the user-land for a better separation of concerns and avoiding unexpected side effects.

[toddsmith-adsk]

Here is my use case with syncing a 3D viewer to a data grid with treeData.

Ideally a user would not need the Model browser in the 3D viewer if the grid supported the same functionality to control visibility and selection.

Default View

Visibility Changed

Selection Changed

Use cases:

• Clicking on a node in the Model browser (in the 3D viewer) changes visibility state and propagates the state down to its the children (or up the tree depending on what was clicked). It will also set the visibility state to hidden for all other nodes.
• Shift clicking on a node in the Model browser (in the 3D viewer) changes the selection state and propagates the state down to its children (or up the tree depending on what was clicked). It will also set the selected state to off for all other nodes.

I need to implement the same behavior in the data grid and keep the visibility and selection with the 3D viewer in sync. Changing selection or visibility in the grid will update the 3D viewer and vice versa. Or you could close the Model browser and rely on the grid to change selection and/or visibility in the 3D viewer.

• Have you tried managing the visibility state outside and if there were significant challenges in doing so?
  I can certainly do that if that is the ideal solution. But I would need to duplicate all of the state, events and propagation logic which already exists for the selection column. I'm trying not to reinvent the wheel.

• Do you need to propagate both selection and visibility states to the parent and child rows? If yes how do you plan to show them on the UI, it'd be great if you could prepare a live example to demonstrate it.
  Yes. I've attached a screenshot.

I have a basic custom checkbox column which is using the Visibility and VisibilityOff icons but I'm missing the state management and state propagation logic.

[MBilalShafi]

Thank you for sharing detailed information about your use case, along with the screenshots. 🙏

The selection propagation feature is tightly integrated with the row selection state and is not designed to support multiple columns as per your requirements. Given this, the recommended approach would be to manage the state and propagation logic on the user side. You are welcome to reuse the internal logic while implementing your own abstraction or visibility handling.

Having said that, the use case is quite interesting. I’ll keep this issue open with a waiting for 👍 label to gauge interest from the community. If there is significant demand, we may consider making the feature internally reusable in the future.

If you encounter any challenges during implementation, feel free to reach out. I’d be happy to provide guidance or share a recipe that closely aligns with your use case.

[toddsmith-adsk]

@MBilalShafi thank you for the follow up. The approach I've taken it to effectively duplicate the GRID_CHECKBOX_SELECTION_COL_DEF and associated logic and using a lot of interface merging. It's a lot of code but seems to be working.

The interesting challenge is that, assuming I have a hook similar to useGridRowSelection, where do I get that sucker loaded? Grid slots seem to be the only viable solution to load my hook (i.e. inside a custom toolbar) because it must exist inside of the grid context.