-
Notifications
You must be signed in to change notification settings - Fork 0
Faceting #259 #272
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
Faceting #259 #272
Conversation
@chowington I updated the linked issue with some missing details. It may impact the work you've done here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi!
Looks to me like there's a bug in the Storybook Controls UI
In Barplot, for example, I would say there should only be 2 controls: data
and props
, but it lists 27. 25 of them are inoperative. But I guess we shouldn't dwell on this right now.
Looks great otherwise, cheers.
Maybe the controls are shared per story tsx file? Or leak between stories in the same file, or something? Not worth investigating further, just thought I'd make a note of this here. |
I took a very quick look at the code, and I think you're going in the right direction. I haven't tested anything, but hope to do so in the next day or two. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. I tested also by nuking modalComponentProps
in storybook controls and it works great with the modals disabled.
Am I correct in thinking that if we have N facets, we have N on-screen components that each "contain" data. We also have N lots of divModalProps.onClick handlers which also contain a copy of the data (in sharedProps
). Is that using twice the memory? Or is it just a copy by reference. And even if it is a deep copy, does it even matter? (thinking scatterplots)
Excellent work with the interactive
/displayLegend
stuff and I think it is essential to set the modal plot's title
, so all 👍 from me.
Oh there is one small thing. If you check the Histogram story, you see that the modal plot has a legend with a single item. In EDA we disable the legend when there's only one data series. So we will want to be able to control
|
Thanks Bob! I believe JS's object passing behavior is a (slightly-modified) form of pass-by-reference, so theoretically we aren't duplicating the data here. Definitely a valid concern though! |
This should already allow that! The current logic allows you to override |
Oh yeah, sorry I didn't spot that!
…On Fri, Dec 3, 2021 at 5:37 PM Connor Howington ***@***.***> wrote:
Oh there is one small thing. If you check the Histogram story, you see
that the modal plot has a legend with a single item.
In EDA we disable the legend when there's only one data series. So we will
want to be able to control displayLegend from the upstream component,
rather than have it always true as below
const divModalProps = modalComponentProps && {
onClick: () => {
setModalPlot(
<Component
{...sharedProps}
displayLegend={true}
interactive={true}
{...modalComponentProps}
title={label}
/>
);
setModalIsOpen(true);
},
style: { cursor: 'pointer' },
title: 'Click to expand',
};
This should already allow that! The current logic allows you to override
displayLegend={true} by passing your own displayLegend value in
modalComponentProps, as {...modalComponentProps} overwrites the previous
props 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#272 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACLLH6YBOZJL6FL7C7XLFLUPD55NANCNFSM5ISFCPEA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Sorry, I was a little vague late last night! More details:
|
Thanks @chowington - having a look now. Unrelated to your questions, I saw this in the console, FYI:
|
I think it makes sense to have defaults.
My initial thought is to have the same set of tabs we include for an unfaceted mosaic plot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, works great.
It would be nice to have the mosaic modal have the table tabs too, but isn't this going to be a nightmare to implement? Instead of passing modalComponentProps
to FacetedMosaicPlot
we'll have to pass an actual component. Maybe that's an OK hack?
const onPlotlyRender = useCallback((_, graphDiv) => { | ||
// Replace each slice DOM node with a copy of itself. | ||
// This removes the existing click event handler, which | ||
// otherwise blocks the click handler that opens the modal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comment - was looking at an older commit and was going to ask for one!
You're right, I didn't think about that. Let's just stick with the plot for now and see what others think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this all looks great. One suggestion is to export the default styling and spacing options so that consumers can use them if passing in custom styling or spacing.
Yeah, I saw that. The modal comes from |
I thought about and worked on this a little bit and I think the resulting API would be a bit odd. Currently Instead I attempted to create a better API by providing a So what all this means is that I decided to stick with what we have currently, including not giving default |
Alternatively, we could have the click-to-expand feature for the contingency tables as well, separate from the faceted mosaics. Would that be useful? I forgot what the contingency tables look like in faceted mode. UPDATE: I don't think the contingency tables need an expanded view, as they're not compressed in the first place. I am itching to get this merged though, because if another PR gets merged beforehand it could be a nasty merge conflict :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
export interface FacetedPlotPropsWithRef<D, P extends PlotProps<D>> | ||
extends FacetedPlotProps<D, P> { | ||
facetedPlotRef?: Ref<FacetedPlotRef>; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Thanks Dave! |
Works toward #259