I am using Material UI DataGrid component to render EXCEL file. Each Excel file has several column Names and have specific types. For example:
const columns = [
{
"field": "uwgroup",
"headerName": "Group",
"minWidth": 200,
"editable": true
},
{
"field": "Amazing column Name ",
"flex": 1,
"minWidth": 150,
"editable": true
},
{
"field": "Building TSI",
"type": 'number',
"flex": 1,
"minWidth": 150,
"editable": true
},
{
"field": "dev",
"flex": 1,
"minWidth": 150,
"editable": true
}
]
The column Name Building TSI is of type number. And I am adding class name invalid using cellClassName, something like:
classnames({
invalid: !isPositiveNumber(params.value)
})
It works fine and renders class name and indicates error cells. The problem is, I want to count total number of error cells. The reason is, we only allow to save the grid values to the database, if there are no errors in any cells.
Solutions, I have tried so far:
errorCount and increment errorCount when I add class. This causes several re-renders and exceeds memory limit.document.getElementByClassNames('invalid') and check its length. It works only for the rendered item. That is to say, if excel file has more than 10 rows, it is paginated. The invalid cells count is only done for the currently rendered page.preProcessEditCellProps props to indicate error. However, I could not find anyway to get the total error cells count. Only thing, I could get out of this props is an ability to not allow user to enter incorrect value.localStorage. It has the exact same issue as solution number 2.I would appreciate if anyone has faced similar scenario. It would be nice to get overall error cells count, so, I can enable to disable SAVE button.
One of the constraints that I have is the excel files are huge and contains on average of 30-40k rows and 25-40 columns. Adding state for each cells becomes less performant.
Thanks in advance!
Having another property in columns and referring to it before exporting for each cell/row can help.
In this example, invoke eligibleForExport function with the columns definiton and the actual data as parameters will give a boolean stating if error exists or not. Can be changed to count errors as well.
const isInvalidBuildingTSI=(value)=>!isPositiveNumber(value);
const isPositiveNumber=(num)=>num>=0;
const eligibleForExport=(columns,data)=>{
return !(data.find(row=>columns.find(column=>row[column.field]
&& typeof column["isValid"] === "function" && column["isValid"](row[column.field]))))
}
const columns = [
{
"field": "uwgroup",
"headerName": "Group",
"minWidth": 200,
"editable": true
},
{
"field": "Building TSI",
"type": 'number',
"flex": 1,
"minWidth": 150,
"editable": true,
"isValid" : isInvalidBuildingTSI,
"cellClassName":isInvalidBuildingTSI(param.value)?"invalid":""
}
];
If the initial data is always valid an easy way to solve your issue would be to follow the DataGrid documentation about clients side validation:
Client-side validation 🔗
To validate the value in the cells, first add a
preProcessEditCellPropscallback to the column definition of the field to validate. Once it is called, validate the value provided inparams.props.value. Then, return a new object contaningparams.propsand also theerrorattribute set to true or false. If theerrorattribute is true, the value will never be committed.const columns: GridColDef[] = [ { field: 'firstName', preProcessEditCellProps: (params: GridEditCellPropsChangeParams) => { const hasError = params.props.value.length < 3; return { ...params.props, error: hasError }; }, }, ];
For your scenario this would result in the following:
const columns = [
{
"field": "uwgroup",
"headerName": "Group",
"minWidth": 200,
"editable": true
},
{
"field": "Amazing column Name ",
"flex": 1,
"minWidth": 150,
"editable": true
},
{
"field": "Building TSI",
"type": 'number',
"flex": 1,
"minWidth": 150,
"editable": true,
preProcessEditCellProps(params) {
const invalid = !isPositiveNumber(params.props.value);
return { ...params.props, error: invalid };
}
},
{
"field": "dev",
"flex": 1,
"minWidth": 150,
"editable": true
}
]
There is an important difference with what you currently have. This validation only effects edits. So the initial data has to be valid. The advantage is that you no longer have to use classnames({ invalid: !isPositiveNumber(params.value) }) and the save button can always be enabled, since all committed changes can be assumed to be valid.
If the initial data can be invalid, this is probably not the answer you're looking for.