Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Limit x-axis by filtered measurements #1827

Merged
merged 6 commits into from
Aug 20, 2024
Merged

Conversation

joverlee521
Copy link
Contributor

@joverlee521 joverlee521 commented Aug 16, 2024

preview of measurements panel paper dataset

Description of proposed changes

Resolves #1814

Raw measurements

Before:

Screenshot 2024-08-16 at 1 34 53 PM

After:

Screenshot 2024-08-16 at 1 34 58 PM

Mean ± SD

It's not perfect for the mean ± SD view because the xScale is based on the underlying raw data.

Before:

Screenshot 2024-08-16 at 1 32 17 PM

After:

Screenshot 2024-08-16 at 1 32 24 PM

Checklist

Replace the clunky use of `useMemo` with built in `useCallback`.
Based on React docs, this should be completely equivalent
<https://react.dev/reference/react/useMemo#memoizing-a-function>
Resolves #1814

Includes a new `useDeepCompareCallback` wrapper to be able to do a
deep comparison of the filtered measurements array so that the `xScale`
does not change on every re-render.
Add padding to x-axis by padding the domain of the xScale.
Copied the example shared in open issue to support this natively in
d3-scale

<d3/d3-scale#150 (comment)>
Copy link
Contributor

@huddlej huddlej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome, @joverlee521! I actually like how the axis scale doesn't change between the raw and mean/std displays, since it allows me to toggle between those displays without the panel context jumping around.

Playing around with the paper dataset, this view shows the expected domain on the x-axis for the two references:

image

When I dropped the first reference, the x-axis domain didn't update which seemed like a bug here.

image

Then I switched to the raw display and saw that there actually are measurements at the far left of the domain that are plotted in gray as an "undefined" clade and that don't appear in the mean/std view:

image

This seems like a bug with the dataset (that it doesn't define a clade for every reference) and a separate bug with the measurements panel (that it doesn't show a mean/std anyway even when the clade is "undefined"). That's not a bug for this PR, though, (it happens in the production app) and the way you've implemented a fixed x-axis domain for both raw and mean/std views actually reveals the underlying data issue which is great.

I only noticed a couple of edge case issues where the std dev could exceed the lower and upper bounds of the x scale. For example, in the preview app if I filtered the source to "nimr-sep-2011-2011-06-24" and the clade reference to "158N/189K", I get the following mean/std view:

image

And this is the raw view:

image

That's a pretty extreme case, though, so maybe it's ok for now?

return (
scaleLinear()
.domain(extent(measurements, (m) => m.value))
.domain(padLinear(extent(measurements, (m) => m.value), 0.1))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This proportion of 0.1 is the kind of parameter I could imagine exposing to users some day through the measurements config JSON, since there could be dataset-specific reasons to prefer a lower or higher value. Maybe for the sake of remembering what this value means here and eventually exposing it later, could we define 0.1 as a variable in this code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's totally fair! I'll add it as an optional param with a default value for now and we can feed in a user defined value in the future if desired.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in c302939

Based on feedback from @huddlej
<87b4446#r1720389378>

I added as optional param here with a default value of 0.1
In the future, we can potentially feed in a user defined value from
the measurements JSON.
@joverlee521 joverlee521 temporarily deployed to auspice-measurements-x--bzidhe August 16, 2024 22:31 Inactive
Fixes bug flagged by @huddlej in review
<#1827 (review)>

Previously, measurements that were group by `undefined` did not have a
mean for display because the panel was only iterating over existing
legend values.
@joverlee521 joverlee521 temporarily deployed to auspice-measurements-x--bzidhe August 16, 2024 23:18 Inactive
@joverlee521
Copy link
Contributor Author

This seems like a bug with the dataset (that it doesn't define a clade for every reference) and a separate bug with the measurements panel (that it doesn't show a mean/std anyway even when the clade is "undefined").

Ah, this is a case where the test strain does not have a defined clade. Looks like they don't get included in the mean display because the panel was adding means for the legend values only. This should be fixed with b201e5c.

I only noticed a couple of edge case issues where the std dev could exceed the lower and upper bounds of the x scale. For example, in the preview app if I filtered the source to "nimr-sep-2011-2011-06-24" and the clade reference to "158N/189K"

Huh, I would think this is an issue outside of this PR if those were the only two data points the measurements collection. I'll leave it as-is for now since it's such an extreme case.

@joverlee521 joverlee521 temporarily deployed to auspice-measurements-x--bzidhe August 16, 2024 23:24 Inactive
@joverlee521
Copy link
Contributor Author

I only noticed a couple of edge case issues where the std dev could exceed the lower and upper bounds of the x scale. For example, in the preview app if I filtered the source to "nimr-sep-2011-2011-06-24" and the clade reference to "158N/189K"

Huh, I would think this is an issue outside of this PR if those were the only two data points the measurements collection. I'll leave it as-is for now since it's such an extreme case.

Tracking in #1828 as a future TODO.

If there's no other feedback, I'll merge this tomorrow.

@joverlee521 joverlee521 merged commit 981eb5b into master Aug 20, 2024
26 checks passed
@joverlee521 joverlee521 deleted the measurements-x-scale branch August 20, 2024 16:42
@huddlej
Copy link
Contributor

huddlej commented Aug 22, 2024

Awesome! Thank you again, @joverlee521!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Limit x-axis by visible measurements
3 participants