Respect user-supplied color range given zero-variance data #42
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thank you for publishing the reactablefmtr package. It has helped me achieve a professional look to my app. I've encountered two challenges with the fixed color ranges and would like to share a fix.
First, the zero-variance checks cause user-supplied color range values (min_value & max_values) to be ignored. Note that zero-variance will always occur for single-row tables. This changes applies the zero-variance test after selecting the color range end points instead of before. The variance test itself is also reduced down to a simpler range calculation.
Second, in some fixed color range applications (e.g. red for negative, green for positive) the potential data range is unbounded, which limits the usefulness of hard "min_value must be less than the minimum value observed in the data" stop's. So this change removes the stops and instead clamps the post-normalized value to [0,1]. That way data values outside [min_value, max_value] are displayed using the most-extreme color value.
A different approach (not included in this change) to scale-and-clamping would be to map the potential (-Inf,Inf) data range to the (0,1) color range via some sigmoid function. That way there is always a more-extreme color for a more-extreme data value in a continuous way (although becoming infintesimally similar). Since there are endless such mapping functions, consider accepting an arbitrary mapping function as input, with scale-and-clamp and sigmoid function-factories provided by the package. Just an idea...
Fixes kcuilla/reactfmtr#43