[RFC] Should we move Cell, ColumnHeader and Rows into the component prop?

[dtassone]

ATM to customize the cell, or the column header you have to use the ColDef object.
The idea is to refactor renderCell, renderHeader, potentially as well, the valueGetter and move to a Cell component slot.

function CustomCell(props) {
  if(props.column.field === 'someField') {
    return <Cell value={format(props.row['anotherField'])} className="important" />
  }
  if(props.column.field === 'image') {
   return <div><img src={...}></div>
  }
}

<DataGrid components={{ Cell: CustomCell }}>  

[oliviertassinari]

Why, what are the pros & cons?

[dtassone]

• Clean the colDef of the render functions, also consider removing value getter, and maybe formatters
• Centralise all components and use the same pattern for all the overridable component

[dtassone]

Cons:
More refactoring and breaking changes

[oliviertassinari]

also consider removing value getter, and maybe formatters

From what I understand:

• valueGetter is important for filtering, sorting, grouping. I definitely think that we have to keep it.
• valueFormatter is could be important for rendering the values outside of the cells, e.g. in the filtering view, but maybe it's not the right abstraction and each time a value is outside of a cell, it should have it's custom formatted.

Centralise all components and use the same pattern for all the overridable component

I don't really buy into this consistency argument. I think that two situations different enough can have two different solutions. We had almost the same case in the Autocomplete or DatePicker. We plan/have a renderInput prop as well as a components prop. Each optimizes for different things. The components prop optimizes for allowing deep customization but isn't meant to be frequently used. Actually, in a nominal use case, it's not used. The renderInput prop our our renderCell prop are not components, but render functions, which is a major difference. It's meant to be flexible, very custom, easy to use, they are almost always needed.

Clean the colDef of the render functions

Why is it better, and not worse? The render function seems to be a perfect use case for the column definition, it's stateless and very specific to a column.

---

A counter proposal, have the best of the two options:

  <props.components.Cell {...x}>
    {props.columns[x].renderCell(x)}
  <props.components.Cell>

[DanailH]

Ok sorry for the late reply.

So I've checked the pros and cons and, more importantly, how it will be used. IMO the current way to "customize" a cell is better than the proposed one. My argument is that it is likely that people will need to customize a very specific cell. The current way of doing that is more straight forward than the proposed one because if I am to provide a custom Cell component and inside it write a bunch of logic to detect if the cell I am about to customize is really the cell that I want to customize it will be more difficult that to only pass that customization to the renderCell directly.

Also, the other components that allow customization via replacing entire components is a different use case than the Cell in a way that they are not really repeated a lot and the reason why someone would want to replace them with their own is that they have very specific business requirement.