Rant: Datatable/Column should handle string to date conversions for filtering.

[SolidAnonDev]

I am a little confused in general as to why the decision is made that in order for date filtering to be successful on a column filter, the incoming data has to have an instance of JavaScript Date. The docs themselves depict the mapping of the date fields in incoming data to Javascript Date instances. If there's some way around this I would like to know.

This is confusing to me for two reasons:

1. Data coming from the server cannot be an instance of JavaScript dates. It comes in as a string.
2. If you use typescript and don't follow the practice of using any or plain JS everywhere like the docs do, you likely have a type that maps to your database entity. Because the data cannot come in from the server as a Date, your type will likely contain the date field as a typescript string type.
3. This then results in the necessity to .map the data like the docs show, however, this changes your type if you need to use the row data from the Datatable. It is no longer your original type, it is your type with a converted date field.

Here's an example.

I do a lot of abstractions like the below..

Given this type:

type MyEntity = {
name: string;
date: string;
}

Let's say I have a scenario where I am using the datatable as a 'selection interface' of sorts. THe user needs to select a MyEntity from the list and the datatable wrapper below provides a repeatable interface to both load the data, and allow a selection that is provided to the parent component via props:

interface Props {
selectedItem: MyEntity
setSelectedItem: (entity: MyEntity) => void;
}
export const MyEntityRepeatableTable: React.FC<Props> = ({ selectedItem, setSelectedItem}) => {

        const { data, isPending} = useQuery({
                queryFn: DataService.GetMyEntities,
                queryKey: 'my-entities'
        })

      return (
      <DataTable 
        value={data} 
        selectionMode="single" 
        selection={selectedItem} 
        onRowClick={(e) => setSelectedItem(e.data as MyEntity))}>
              <Column field='name' header="Name"/>
              <Column field='date' header="Date" body={(data: MyEntity) => someDateFormatter(data.date)}/>
      </Datatable>
        )
}

If I want to filter on date however, I have to first map the data to convert the date field into a javscript date

This results in a problem, because my parent component is asking for MyEntity, not the result of mapping MyEntity to now have a Date instance instead of a string.

I either have to change my type entirely, have two separate types, or convert the type back to the original before passing it to the parent, because the parent needs the original type, not the type + date conversion.

I don't see how it is a smart choice to require this conversion pre-filtering. It doesn't cause a problem if you're not trying to filter on date, but it causes kind of a big problem the second you want to filter on a date column.

Futhermore, this results in the necessity to map potentially 1000's of rows of data, rather than just providing the incoming data to the table without the map operation. This doesn't seem optimal to me at all.

[melloware]

I guess what it comes down to is you can NOT sort dates as "strings" logically so it has to be a Date object for sort ascending and descending to know if one date is before or after another.

Take for example these strings in dd-mm-yyyy format.

04-10-2022
01-01-2024
22-12-2019

As strings these would sort ascending...

01-01-2024
04-10-2022
22-12-2019

Which is just clearly incorrect. And since date strings in countries can literally be any flavor like "mm-dd" or "yyyy-dd-mm" using String to sort makes no logical sense.

[SolidAnonDev]

My complaint isn't that it's not being used and sorted as a string.

My complaint is that the DataTable requires me to alter my data before passing it in. It appears to me that rather than require the user .map their data to convert their dates to a Date instance, the comparison made in a column filter should check the typeof the input date, and if it's a string, it should convert to Date for me before it makes the comparison. It doesn't appear to do this now, because if you attempt to use string date data, it fails as it's attempting to call date functions on the input strings, so clearly it's not doing this conversion.

So then the Datatable spits out the type of whatever you put in, and since the DataTable is requiring me to alter my type before input, any use of that type when extracting it becomes a misrepresentation of what is being used in the rest of the app and I can no longer use onRowClick and similar functions without hacky conversions to return the data extracted from the row to its original type: MyEntity

My point is this:

If I'm using MyEntity everywhere in my application, but the DataTable requires me to convert it to a new type that has a date conversion, then I have two differing objects:

{ name: string; date: string} Original MyEntity object
{name: string: date: Date) converted object that can't be used when extracted from the datatable row because it's no longer MyEntity because we were forced to convert it, and all functions calling for input of MyEntity will now complain, because the datatable doesn't return MyEntity anymore because I was forced to convert.

The comparisons made when setting up filters and using them for column filtering should convert the input datatype which should probably look something like Date | string to be Date always based on the typeof the input. It would be logic to do this when the user specifies the datatype="date" prop.

My gripe with this comes from the fact that literally all server-returned data will be strings, so you've relegated all your users of DataTable to doing this arbitrary conversion, and subsequently the results of onRowClick and similar functions now return data that is not an accurate reflection of what the entirety of the rest of the app is using because, again, all server returned data will be strings by default.

[melloware]

Don't get me wrong I see your point. You are just saying the burden should be on the component to know what you want to do.

[SolidAnonDev]

Hardly, as there appears to be 'switches' via props already in place that could ascertain that information and do a simple conversion if it's not already a Date object, for example the datatype="date" prop on a <Column/>

I'm not relying on the component to do everything, but for it to know that the input type is intended to be a date, and then use typeof to check whether it's a Date object or a string object should in general not be a big deal.

It's not like it's uncommon either - Plenty of functions that amount to Date comparisons allow either string | Date input are abound in the wild, for example, the entire date-fns library is defined with string | Date

It doesn't seem reasonable that the <Column/> component couldn't just be string | Date like endless other functions when it goes to make comparisons in order to provide the same functionality.

[melloware]

You are more than welcome to submit a PR no?