Skip to content

Conversation

@DominikB2014
Copy link
Contributor

Work toward #75230

Adds geo selector in the web vitals and resource module and ensure all queries gets the filter applied

NOTE: not all the metrics are properly tagged yet, so web vitals doesn't work entierely yet, and the resource module doesn't have geo data for resource size metrics. Its all behind a feature flag, so this not an issue that customers can see.

@DominikB2014 DominikB2014 requested a review from a team August 14, 2024 17:19
@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Aug 14, 2024
Copy link
Contributor

@KevinL10 KevinL10 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, would suggest a custom decoder for the regions


const query = decodeScalar(location.query.query, '');
const browserTypes = decodeBrowserTypes(location.query[SpanIndexedField.BROWSER_NAME]);
const subregions = decodeList(
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would make sense to use a custom query decoder for all of these places we're decoding the subregions -- similar to decodeBrowserTypes -- so that we can guarantee the regions are valid

Copy link
Contributor Author

@DominikB2014 DominikB2014 Aug 14, 2024

Choose a reason for hiding this comment

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

Hmm, When would this occur?
I suppose we can just be safe here, and cover the manual case.
although the query would still succeed. (Would just look for a region that doesn't exist)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm going to address this in another PR, i'm still not 100% sure on the benefit so i'll give it some thought, there are 2 cases I can see that would produce an invalid regions.

  1. Our code somehow produces an invalid subregion. In this case, i feel as though adding decodeSubregion might actually mask any problem we have in code that shouldn't be occurring anyways. I think we would want to see if this problem occurs.
  2. The user manually enters a subregion in the url bar. In this case the query should succeed here anyways, unless they enter a string that happens to match some other query syntax. Which in that case i think it might be better to show a failed query in our UI, so that the user knows what they entered in the url bar doesn't make sense. Either way I like the idea of showing the user the results of their own changes in the url bar.

Copy link
Member

@mjq mjq left a comment

Choose a reason for hiding this comment

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

Tiny, judgment call nit aside (and Kevin's notes above), LGTM!

@DominikB2014 DominikB2014 enabled auto-merge (squash) August 15, 2024 13:45
@DominikB2014 DominikB2014 merged commit 3465d84 into master Aug 15, 2024
@DominikB2014 DominikB2014 deleted the DominikB2014/implement-geo-selector branch August 15, 2024 13:55
@github-actions github-actions bot locked and limited conversation to collaborators Aug 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants