Skip to content

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

Merged
merged 23 commits into from
Dec 8, 2021
Merged

Faceting #259 #272

merged 23 commits into from
Dec 8, 2021

Conversation

chowington
Copy link
Member

Works toward #259

@dmfalke
Copy link
Member

dmfalke commented Nov 23, 2021

@chowington I updated the linked issue with some missing details. It may impact the work you've done here.

Copy link
Member

@bobular bobular left a 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.

@bobular
Copy link
Member

bobular commented Dec 2, 2021

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.

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.

@dmfalke
Copy link
Member

dmfalke commented Dec 2, 2021

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.

@chowington
Copy link
Member Author

@bobular @dmfalke The main tasks for this PR's ticket are mostly done. Do take a look please! There's one outstanding bug and potentially other improvement to make that we can discuss.

@chowington chowington marked this pull request as ready for review December 3, 2021 01:27
Copy link
Member

@bobular bobular left a 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.

@bobular
Copy link
Member

bobular commented Dec 3, 2021

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',
          };

@chowington
Copy link
Member Author

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.

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!

@chowington
Copy link
Member Author

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 👍

@bobular
Copy link
Member

bobular commented Dec 3, 2021 via email

@chowington
Copy link
Member Author

chowington commented Dec 3, 2021

@bobular @dmfalke The main tasks for this PR's ticket are mostly done. Do take a look please! There's one outstanding bug and potentially other improvement to make that we can discuss.

Sorry, I was a little vague late last night! More details:

  • Bug (Fixed): Clicking directly on the pie chart portion of a pie facet doesn't trigger the click handler that opens the modal. You have to click outside the pie itself. I'm not sure why exactly this is happening yet; if anyone has an idea, let me know!
  • Comment: I'll probably double check the layout prop defaults to make sure they are reasonable
  • Question: Should we have defaults for the modal component layout props as well?
  • Question: How should we handle the mosaic contingency table? Should there be a modal for those tables as well? I didn't test that at all and there isn't a story for the cont table, faceted or otherwise

@chowington
Copy link
Member Author

@dmfalke @bobular Any comments on the above?

@bobular
Copy link
Member

bobular commented Dec 7, 2021

Thanks @chowington - having a look now.

Unrelated to your questions, I saw this in the console, FYI:

error: "Warning: react-modal: App element is not defined. Please use Modal.setAppElement(el) or set appElement={el}. This is needed so screen readers don't see main content when modal is opened. It is not recommended, but you can opt-out by setting ariaHideApp={false}."

@dmfalke
Copy link
Member

dmfalke commented Dec 7, 2021

@bobular @dmfalke The main tasks for this PR's ticket are mostly done. Do take a look please! There's one outstanding bug and potentially other improvement to make that we can discuss.

Sorry, I was a little vague late last night! More details:

* [x]  Bug (Fixed): Clicking directly on the pie chart portion of a pie facet doesn't trigger the click handler that opens the modal. You have to click outside the pie itself. I'm not sure why exactly this is happening yet; if anyone has an idea, let me know!

* [ ]  Comment: I'll probably double check the layout prop defaults to make sure they are reasonable

* [ ]  Question: Should we have defaults for the modal component layout props as well?

I think it makes sense to have defaults.

* [ ]  Question: How should we handle the mosaic contingency table? Should there be a modal for those tables as well? I didn't test that at all and there isn't a story for the cont table, faceted or otherwise

My initial thought is to have the same set of tabs we include for an unfaceted mosaic plot.

Copy link
Member

@bobular bobular left a 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
Copy link
Member

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!

@dmfalke
Copy link
Member

dmfalke commented Dec 7, 2021

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?

You're right, I didn't think about that. Let's just stick with the plot for now and see what others think.

Copy link
Member

@dmfalke dmfalke left a 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.

@chowington
Copy link
Member Author

Thanks @chowington - having a look now.

Unrelated to your questions, I saw this in the console, FYI:

error: "Warning: react-modal: App element is not defined. Please use Modal.setAppElement(el) or set appElement={el}. This is needed so screen readers don't see main content when modal is opened. It is not recommended, but you can opt-out by setting ariaHideApp={false}."

Yeah, I saw that. The modal comes from core-components, and Mike said he'll address that console warning at some point 👍

@chowington
Copy link
Member Author

chowington commented Dec 7, 2021

  • Question: Should we have defaults for the modal component layout props as well?

I think it makes sense to have defaults.

I thought about and worked on this a little bit and I think the resulting API would be a bit odd. Currently modalComponentProps existing is the way we activate the click-to-expand feature. If we provide sensible defaults, it would be odd for the user to still have to provide modalComponentProps in order to activate the click-to-expand feature.

Instead I attempted to create a better API by providing a clickToExpand?: boolean prop that controls the expand feature's activation, however after changing the logic appropriately, there was a complicated TS error that cropped up involving the P generic type. I think I understood it, but I didn't see a way to get around it.

So what all this means is that I decided to stick with what we have currently, including not giving default modalComponentsProps (I did stash my attempt at a better API though). How does this sound @dmfalke?

@chowington
Copy link
Member Author

chowington commented Dec 7, 2021

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?

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 :)

@chowington
Copy link
Member Author

chowington commented Dec 8, 2021

I'm getting ready to wrap this up on the web-components side. Just wanted to get one more review from @dmfalke on this particular commit and I'll merge: ac3926d

@chowington chowington requested a review from dmfalke December 8, 2021 21:41
Copy link
Member

@dmfalke dmfalke left a comment

Choose a reason for hiding this comment

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

Looks good!

Comment on lines +35 to +38
export interface FacetedPlotPropsWithRef<D, P extends PlotProps<D>>
extends FacetedPlotProps<D, P> {
facetedPlotRef?: Ref<FacetedPlotRef>;
}
Copy link
Member

Choose a reason for hiding this comment

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

👍

@chowington
Copy link
Member Author

Thanks Dave!

@chowington chowington merged commit 2c2496c into main Dec 8, 2021
@chowington chowington deleted the faceting-#259 branch December 8, 2021 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants