Add null value handling to sorting logic and update tests

[spenserhale]

What?

Adjusted sorting functions to handle null values by placing them at the end for both asc & desc directions.
The decision to move null values to the end of the list is to make sorting more beneficial to the user by consistently providing values above empty ones.

Why?

Currently throws TypeError if you attempt to sort data with null values:
Uncaught TypeError: Cannot read properties of null (reading 'localeCompare')
at Object.sort (app.js?ver=2ec77682ff5b8736892f:1:10684)
at N.e.map.s [as sort] (app.js?ver=2ec77682ff5b8736892f:1:10950)

Testing Instructions

Updated test cases to validate the new sorting behavior and included new fixture data for testing scenarios with null values.
npm run test:unit packages/dataviews

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: spenserhale <spenserhale@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @spenserhale! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[oandregal]

This is Spenser's first PR to Gutenberg! Thanks for that :)

I was talking to him about this PR in the WordCamp US, and I mentioned that I see two approaches to work with null values:

1. One approach is displaying null values always to the end (no matter the sorting order, ascending or descending), like spreadsheet does:

Gravacao.do.ecra.2024-09-17.as.12.14.54.mov

2. Another approach is consider null values as empty, which means sorting order affects its position. This is similar to what I've seen in other wp-admin places:

Gravacao.do.ecra.2024-09-17.as.12.15.23.mov

I think both have pros/cons. For example, in the 2 approach, if you have tons of null data, it may be difficult to get to the first non-empty value.

I'm on the fence on this one. I perhaps like 1 the most. Thoughts about this @jameskoster @youknowriad ?

[youknowriad]

Why do we have to handle "null" values in "integer" type. Null is not an integer (same question for text)

[oandregal]

The field type doesn't do "data typing", it's just a way for us to provide default implementations of certain functions. As a result, we may end up having data that is string or null. Another way to put it: how should we work with types that can be nullable?

A related conversation was this: given that data can be null, it'd be interesting to having a precreated filter (elements not required) that allows users to filter by "empty data / not empty data". Similar to what a spreadsheet has:

Gravacao.do.ecra.2024-09-18.as.07.22.59.mov

[youknowriad]

Another way to put it: how should we work with types that can be nullable?

Should we allow this? That would be my first question. Maybe it's ok for "null/undefined" values but for me it's not for say assigning strings to numbers for instance. And we should consider that "doing it wrong" rather than actually providing a fix.

[oandregal]

I see, and I agree to that. Looking at the current use cases of the WP table in the wp-admin, and considering this will be used with user data, I'd think we need to support nullable data. I was surprised we hadn't yet run into this, to be honest.

[youknowriad]

I'm on the fence but I wonder if:

• If type is "string/text", treat empty values as ""
• If type is "number", treat it as 0
• If there's no type, move to the end or something.

[oandregal]

I'd think we need to be consistent and using one of the two approaches #65423 (comment) no matter the type. Like Jay, I believe 1 is more practical — though I can be convinced for 2 as well. No strong opinion other than preventing DataViews from breaking and being consistent.

[youknowriad]

For strings, I don't really see why "" would be different than null or undefined. For the rest I don't mind much.

[youknowriad]

To clarify, I also don't mind any approach to be honest.

[jameskoster]

Option 1 seems more practical to me.

Unsure if it's related, or if it will affect anything here, but we should avoid entirely empty table cells as screen readers can interpret it as missing content.

[oandregal]

Unsure if it's related, or if it will affect anything here, but we should avoid entirely empty table cells as screen readers can interpret it as missing content.

What should we do here? Should we render — when the content is empty? So far this has been "consumer territory": it's up to them to define how a given field is rendered.

[jameskoster]

I suppose a 'No data' label inside a VisuallyHidden could work.