Description
I've recently been trying to use Akita and this plugin for state management, and the experience has been mostly amazing thus far.
However, I've been running into some strange behavior that was hard to debug regarding sorting fields that can be falsy/null in AkitaMatDataSource.
When comparing the two values for their sorting, if either value is null or falsy the original ordering is preserved, this is not ideal for most uses. I would expect it at least check that both are falsy before returning 0 and to place the truthy/non-null value before the null (for ascending at least).
The responsible code appears to be this if statement inside of the sortFunction.
if (!varA || !varB) {
return 0;
}I would expect it to behave roughly like the vanilla MatDataSource (snippet below)
// If both valueA and valueB exist (truthy), then compare the two. Otherwise, check if
// one value exists while the other doesn't. In this case, existing value should come last.
// This avoids inconsistent results when comparing values to undefined/null.
// If neither value exists, return 0 (equal).
let comparatorResult = 0;
if (valueA != null && valueB != null) {
// Check if one value is greater than the other; if equal, comparatorResult should remain 0.
if (valueA > valueB) {
comparatorResult = 1;
} else if (valueA < valueB) {
comparatorResult = -1;
}
} else if (valueA != null) {
comparatorResult = 1;
} else if (valueB != null) {
comparatorResult = -1;
}
return comparatorResult * (direction == 'asc' ? 1 : -1);This would probably be considered breaking if someone were relying on this behavior, but as it stands its difficult to sort nullable fields.
This is an example of the current hack/workaround I've been using inside of the sortingDataAccessor to not return null.
some?.nullable?.value?.trim()?.toLowerCase() ?? 'z'.repeat(LONGEST_ACTUAL_VALUE)When the field is null, this gives a value that will always (as long as the value is shorter than the 'z' string) be seen as later in the list (the expected behavior for null).