-
Notifications
You must be signed in to change notification settings - Fork 212
feat: setting up early indexes experimentation and experiment viewed event CLOUDP-311776 #6860
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
Conversation
{useLeafyGreenStyling ? ( | ||
<H3 data-testid="modal-title" id="modal-title"> | ||
{title} | ||
</H3> | ||
) : ( | ||
<h1 | ||
className={cx(titleStyle, darkMode && titleStyleDark)} | ||
data-testid="modal-title" | ||
id="modal-title" | ||
> | ||
{title} | ||
</h1> | ||
)} |
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.
The purpose of compass-components package is to have uniform, consistent components for all places where they are used in compass and this goes very much against it. For the experiment if we really need to do this, this should really just stay scoped to the create index modal, but generally speaking this is just not aligned with how we are building compass: why only this single modal needs a custom header style that will not be aligned with everything else in the application?
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 has been approved by Claudia and Diancheng also reviewed the designs! also i tried to make it more generic by saying 'useLeafyGreenStyling', which is consistent with leafy green at least. if useLeafyGreenStyling is false (which it is by default) then it'd be uniform for all the other modals!
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.
More generic configurable option is not the same as uniform styles (more variants less uniformity) 🙂 If Claudia signed off on switching all modals to this style because it's aligned with leafygreen more, let's just do it. Adding a generic option that we will be using only once in one specific place for an experiment that can be scrapped is not how we approach adding new components or properties to this particular package
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.
seems like Claudia is OOO and i'm not sure if there's a plan to switch the others just that she signed off on the design for this specific modal. would it be better if i make a separate component for modal header or update the prop name to be specific to index guidance?
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.
Better would be to create a separate component in packages/compass-indexes/src/components/create-index-modal/create-index-modal.tsx file and use it instead of ModalHeader and not modify compass-components, it's just two existing leafygreen components you need to stack together, there is absolutely no point to generalize this if we're not planning to update other parts of Compass to use it. Just to stress again: we don't put one-off components in the compass-components package, we don't put feature specific props in the components in this package
packages/compass-indexes/src/components/create-index-modal/create-index-modal.tsx
Outdated
Show resolved
Hide resolved
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.
Looking good, left two small comments/questions.
@@ -83,6 +83,7 @@ export { VisuallyHidden } from '@react-aria/visually-hidden'; | |||
export { openToast, closeToast, ToastArea } from './hooks/use-toast'; | |||
|
|||
export { breakpoints, spacing } from '@leafygreen-ui/tokens'; | |||
export { H3, Body } from '@leafygreen-ui/typography'; |
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.
We're already exporting these from the leafygreen.tsx
file:
So we can remove this.
export { H3, Body } from '@leafygreen-ui/typography'; |
|
||
useFireExperimentViewed({ | ||
testName: TestName.earlyJourneyIndexesGuidance, | ||
shouldFire: enableInIndexesGuidanceExp && isVisible, |
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.
Maybe I'm understanding this wrong, should this be showIndexesGuidanceVariant
and not enableInIndexesGuidanceExp
?
shouldFire: enableInIndexesGuidanceExp && isVisible, | |
shouldFire: showIndexesGuidanceVariant && isVisible, |
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.
nope this should fire for when user is in the control as well so it should be enableInIndexesGuidanceExp
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.
Should we track that they're in the control then? Or is there already a way we differentiate that they are shown/not shown the new experience?
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 tracks if they are in the control as well, if they are in the experiment enableInIndexesGuidanceExp
is true. i need to confirm once i get the latest into our mms but i think by default we have code set up to send down whether user is in the variant or control
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.
Would it make things easier if we track if they're in the control or shown the experience here as some metadata for the tracking event? If it's on the mms side I suppose we don't need to since we'll be able to correlate them anyway. Feel free to resolve!
|
||
<Body | ||
data-testid="create-index-modal-header-subtitle" | ||
style={{ color: palette.gray.dark1 }} |
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.
Small nit, we typically avoid using style
unless it's a dynamic value we're passing to it. Instead we would create a css
style variable and pass that to the className
like we do for headerStyle
.
|
||
<Body | ||
data-testid="create-index-modal-header-subtitle" | ||
style={{ color: palette.gray.dark1 }} |
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.
Should we account for dark mode here? Is there a reason we need to explicitly set the color here and not use the default color? Typically we try to default to the colors from the leafygreen typography components. They're also plugged into the dark mode provider so they automatically switch when it changes.
If we explicitly want to have a color here, and we want it to change based on the theme, you can look for the useDarkMode()
hook in the code base as a reference.
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.
designs for dark mode will come out but is not available right now, here's a ticket: https://jira.mongodb.org/browse/CLOUDP-313986.
i only followed the design for the dark gray color though and in the design it was that color
|
||
const CreateIndexModalHeader = () => { | ||
return ( | ||
<div className={cx(headerStyle)}> |
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.
<div className={cx(headerStyle)}> | |
<div className={headerStyle}> |
import React from 'react'; | ||
|
||
const headerStyle = css({ | ||
padding: spacing[5], |
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.
padding: spacing[5], | |
padding: spacing[800], |
nit The single digit values here are deprecated (we'll be updating all of them in #6871 )
Description
Before:

After (made modal bigger, updated the header title, removed db + collection name, added a description):

Experiment Viewed event added:

Checklist
Motivation and Context
Types of changes