Improved Validation Behavior in FlexGrid

March 31 2020

Data entry and validation are essential functions of a data grid. The FlexGrid has always supported both. The simplest type of validation is provided by automatically coercing any edits into the proper data type defined by the column. For example, if the grid column has dataType set to DataType.Number, trying to enter a non-numeric string such as "foo" will automatically cancel the edits and preserve the original value. The same logic applies to dates and Boolean values.

But that is just the first strap. For more detailed validation, you can use the grid's itemValidator property or the CollectionView's getError method.

For example, this code makes sure values in the 'date' column are greater than 10/5/2020, and values in the 'id' column are positive integers:

// raw data  
 let data = [  
     { id: 0, value: 123.123, date: new Date(2020, 10, 28) },  
     { id: 1, value: 231.231, date: new Date(2020, 10, 29) },  
     { id: 2, value: 312.312, date: new Date(2020, 8, 1) },];  
 let minDate = new Date(2020, 9, 5);  

 // CollectionView with getError  
 var view = new CollectionView(data, {  
     getError: (item: any, prop: string) => {  
         if (prop == 'date' && item.date < minDate) {  
             return 'Please enter a date after ' +   
                     Globalize.formatDate(minDate, 'd');  
         }  
         if (prop == 'id' && ([item.id](http://item.id/) < 0 || !Number.isInteger([item.id](http://item.id/)))) {  
             return 'Please enter a positive number';  
         }  
         return null;  
     }  
 });  

 var theGrid = new FlexGrid('#theGrid', {  
     itemsSource: view,  
 });

The CollectionView specifies a getError member function that checks whether an item contains invalid data and returns an error string if it does.

When you bind a grid to this CollectionView and try to enter a date before minDate, the grid automatically highlights the error, provides a tooltip with the error description, and keeps the cell in edit mode until the error is corrected or the edits are canceled:

Improved Validation Behavior

This works great, but if a user typed "20/20/20" into the "date" column, the grid would not be able to coerce that string into a date and would simply cancel the edits, without any error messages.

To address this limitation, the latest release adds a "parsing" parameter to the getError method. This parameter is set to true to indicate the grid failed to coerce a value typed by the user. In this case, the data has not even been updated yet.

To use the "parsing" parameter, we simply extend our getError implementation as follows:

// CollectionView with getError (enhanced)  
 var view = new CollectionView(data, {  
     getError: (item: any, prop: string, parsing: boolean) => {  

         // parsing failed, show message  
         if (parsing) {  
             if (prop == 'date') {  
                 return 'Please enter a valid date in the format "MM/dd/yyyy"';  
             }  
             if (prop == 'id') {  
                 return 'Please enter a positive number';  
             }  
             return null;  
         }  

         // check that stored (parsed) data is valid  
         if (prop == 'date' && item.date < minDate) {  
             return 'Please enter a date after ' +   
                     Globalize.formatDate(minDate, 'd');  
         }  
         if (prop == 'id' && ([item.id](http://item.id/) < 0 || !Number.isInteger([item.id](http://item.id/)))) {  
             return 'Please enter a positive number';  
         }  
         return null;  
     }  
 })

The highlighted code handles cases where the editor value could not be parsed into the proper data type. In this case, if the user typed "20/20/20", you would get the same behavior with regular invalid data (in this case with a slightly different error message):

If you choose not to use the new "parsing" parameter in your getError implementation, the original behavior is preserved. The grid will still ignore invalid edits and will keep the initiall value without showing any errors.

But we recommend you add this extra logic to your getError functions. It provides an extra level of user-friendliness to data validation, making it hard for users to miss typing errors.