Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Updated table component #140

Open
kevinlustig opened this issue Oct 23, 2019 · 1 comment
Open

Updated table component #140

kevinlustig opened this issue Oct 23, 2019 · 1 comment
Assignees

Comments

@kevinlustig
Copy link
Collaborator

Per discussion with WRI, I'm going to be starting work on upgrades to the table component.

The main approach question on my end is sorting. I understand the table component is a wrapper around React Virtualized Table, and sorting issues are pretty common there.

One approach would be to build a more complex column configuration into the cw-components table. Right now, we pass only the display labels of the columns to the component. Sorting is based solely on the actual JS type of the data values - i.e., numbers are sorted as numbers but all strings, including numeric strings, are sorted as strings.

A more robust column config object could include a sort type value such as "percent" or "date" to trigger a transformation of some kind for numeric-ish strings prior to sorting. This would allow for a good variety of value types now and good extensibility in the future. The sort type could be provided by the component where each table is implemented (if applicable), or we could add it directly to the values metadata in the dataset to allow WRI to manage it.

Also should keep in mind that this is not strictly a string/number issue. There may be cases where strings also need to be sorted in something other than alpha order (e.g., "Not Implemented", "Partially Implemented", "Fully Implemented".)

Alternatives to consider:

  1. Rather than a sort type value, provide a custom sort function for each table instance and/or column. Would probably end up writing the same sort functions again and again, though.
  2. Auto-detect the sort type based on common string formats. Does not handle one-offs or slight formatting variations/errors, though

Thoughts or other approaches welcome.

@simaob
Copy link
Contributor

simaob commented Nov 4, 2019

Hey Kevin,

Thanks for this write up. The sort-type seems like a good solution here. Maybe it could be built so that there are a series of pre-existing sorting types (e.g.: numeric, string, percentage, etc), but also allow passing a function to sort it in an ad-hoc way. It would be more work, but make it more resilient.

What do you guys think: @aabdaab and @Bluesmile82?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants