Closed turnerniles closed 7 years ago
@turnerniles We could convert everything to strings and tell the user that everything will be converted to a string. But then the user would be limited with the fancy custom filtering when passing a callback function (I guess they could convert it back to whatever data type they want or we could just not change the data type if a callback is passed). It also feels weird to change the user's data type to a string for filtering but if they do some mathematical aggregations on that dimension (like averaging or maximum/minimum) then it should stay as a number? The more I think about it, the more complicated I think it actually is to manipulate the data type... Maybe we should just handle it on the front-end by using the callback feature for filtering?
I agree in principle if you are writing code and using quick-pivot without a front-end. But when rendering it on the frontend and passing it back, the value passed back will be a string. And if I convert all strings to ints, before calling the filtering function, if the number is stored as a string on the backend then it won't work. Also if we use an <input>
tag to allow the user to pass a custom value, it will also be passed back as a string.
I will use the custom callback for the UI.:
return filterValues.indexOf(value) == -1;
instead of return filterValues.indexOf(value) === -1;
And we can close the issue. What do you think?
Sounds good!
When filtering on value fields, strings passed in as filters are not converted into ints. Should we do this in the pivot logic or on the front end? Numbers on the front-end are rendered as strings so when passed back as in a filter as a they do not match the respective int stored in the pivot.