-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
ref(groupingInfo): Refactor grouping info to avoid storing redundant data #101135
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
base: master
Are you sure you want to change the base?
Conversation
❌ 1 Tests Failed:
View the top 1 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
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.
LGTM! I assume you've tested sending both types of payloads?
const grouping_config = old | ||
? ( | ||
Object.values(old).find( | ||
variant => 'config' in variant && variant.config?.id | ||
) as any | ||
)?.config?.id | ||
: null; | ||
return old | ||
? { | ||
grouping_config, | ||
variants: old, | ||
} | ||
: null; |
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.
Nit, totally not worth changing in this temporary function, but just an option to keep in mind. If you do an early out (if (!old), {return null;}
as your first statement), then it'll save you from having to nest so deeply in the rest of the function, which will in turn make it easier to read.
function isOld( | ||
data: EventGroupingInfoResponseOld | EventGroupingInfoResponse | null | ||
): boolean { |
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.
Again, more important in principle than in practice since this is all temporary, but if you make this a type predicate, then you won't have to do the casting in your groupInfoNew
value below.
event: Event; | ||
group: Group | undefined; | ||
}): EventGroupingInfoResponse | null { | ||
}): EventGroupingInfoResponseOld | EventGroupingInfoResponse | null { |
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.
If you add groupingConfig: null
to the return here, I think bugbot will stop yelling at you.
cf9cf47
to
bf44c8c
Compare
expect(screen.getByText('123')).toBeInTheDocument(); | ||
// Should not make grouping-info request | ||
expect(groupingInfoRequest).not.toHaveBeenCalled(); | ||
}); |
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.
Bug: Unnecessary API Mock in Local Data Test
The test "gets performance new grouping info from group/event data" mocks an API response for grouping info, then asserts the API call isn't made. Since performance grouping data is derived locally, this mock is unnecessary and creates a confusing contradiction in the test.
First PR in a series to refactor grouping info data structure (see linear issue).
Make front end accept and implement new grouping info data structure with
grouping_config
pulled out of individual grouping variants. Now the front end can accept either the correct newEventGroupingInfoResponse
or the oldEventGroupingInfoResponseOld
which it will convert into the correctEventGroupingInfoResponse
data type.