-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix(vue): Update Vue trackComponents
list to match components with or without <>
#13543
fix(vue): Update Vue trackComponents
list to match components with or without <>
#13543
Conversation
…or without `<>` Signed-off-by: Kaung Zin Hein <[email protected]>
packages/vue/src/tracing.ts
Outdated
if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) { | ||
currentCompo = `<${currentCompo}>`; | ||
} | ||
return formattedName === currentCompo; |
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.
formattedName
from formatComponentName()
always return a name with < >
.
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.
Oh, it can also be <Component> at Component.vue
.
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.
Hey @Zen-cronic thanks for opening this PR!
The change looks good to me but I had a slightly more size-efficient solution.
Could you add a test as well? We already have a Vue 3 test E2E test application. I was thinking that we could set a trackComponents
array option in the Sentry init call and adjust the pageload test that it also includes a ui.vue.*
span for a component that matches one of the array entries.
If you don't have time, just let me know, then I'll add the test.
packages/vue/src/tracing.ts
Outdated
let currentCompo = compo; | ||
|
||
if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) { | ||
currentCompo = `<${currentCompo}>`; | ||
} | ||
return formattedName === currentCompo; |
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 we can replace this with a more bundle size efficient version:
let currentCompo = compo; | |
if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) { | |
currentCompo = `<${currentCompo}>`; | |
} | |
return formattedName === currentCompo; | |
return compo.replace(/^<(.*)>$/, '$1') === formattedName |
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.
Ah in this case we don't even need the block anymore but could inline it to the some
call. So feel free to do that as well :)
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.
Noted
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.
hey, I've taken your approach and found that formattedName
must also be replaced:
function findTrackComponent(trackComponents: string[], formattedName: string): boolean {
function extractComponentName(name: string): string {
return name.replace(/^<(.*)>(?:.*)?$/, "$1");
}
const isMatched = trackComponents.some(compo => {
return extractComponentName(formattedName) === extractComponentName(compo)
}
);
return isMatched;
}
The regex is needed for both the user provided component and the formatted component.
- User provided: either
<App>
orApp
- Formatted: either
<App>
or<App> at App.vue
.
What do you 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.
Good observation, you're right! Also, I didn't think about the <App> at App.vue
case.
There's one unfortunate side effect of this regex though: It can lead to polynomial build up when evaluating an input. Given that we run extractComponentName
on user input I'd rather not risk the (still unlikely but possible) chance of some kind of ReDoS attack (I used this ReDoS checker to test it)
I played around with the regex to make it safer and keep it linear and arrived at this one: /^<([^\s]*)>( at [^\s]*)?$
I think this should still cover all component names but would appreciate it if you could double check it as well :)
Also, since this logic is getting a little bit more involved now, could you add a couple of unit test for findTrackComponent
? It's fine to export the function just for testing purposes btw. Thanks!
(I don't want to overburden you with tests btw, I just want to keep stuff like this covered and understandable for everyone. So if you don't have the time, just let me know. We appreciate your hard work either way!)
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.
Noted, unit and e2e tests added.
Just read your comments and review, I'll take them up now. Thanks! |
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.
Sorry, I realized I approved the PR yesterday on accident. Please don't mind the change request, I'm just putting it here so that we don't merge the PR accidentally before the extract name logic is resolved.
Signed-off-by: Kaung Zin Hein <[email protected]>
* | ||
*/ | ||
function extractComponentName(name: string): string { | ||
return name.replace(/^<([^\s]*)>(?: at [^\s]*)?$/, '$1'); |
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.
Based on what you suggested @Lms24, just an added non-capture group. The ReDoS Checker passes.
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.
Sounds good to me, thanks!
Signed-off-by: Kaung Zin Hein <[email protected]>
'sentry.op': 'ui.vue.mount', | ||
'sentry.origin': 'auto.ui.vue', | ||
}, | ||
description: 'Vue <<HomeView>>', |
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.
Just making sure, are the double brackets intended? They're formatted 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.
Good observation! I don't think they're intended. Let's remove them.
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 making the changes! We're almost there :)
@@ -122,3 +122,101 @@ test('sends a pageload transaction with a route name as transaction name if avai | |||
}, | |||
}); | |||
}); | |||
|
|||
test('sends a lifecycle span for the tracked HomeView component - with `<>`', async ({ page }) => { |
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 is a bit of an unfortunate and very intransparent limitation of our e2e test setup but we shouldn't navigate to the same route in more than one e2e test. The reason is that we execute them in parallel in CI and the waitForTransaction
call from one test might actually resolve for a transaction in another test, depending on the condition in the callback.
To avoid this confusion, we generally create a new route for each test. Suggestion: Either we create new routes for the two new tests or we integrate them in already existing tests and simply check for the spans there. I'll let you make the call, I'm fine with either option.
Also, feel free to test both kinds trackComponent
notations in one route/test :)
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.
hey, thanks for the info. i decided to go with creating a new route, and grouped the different notations together in a single test.
Signed-off-by: Kaung Zin Hein <[email protected]>
Group trackComponent tests together: 1. With <> 2. Without <> 3. Not tracked Signed-off-by: Kaung Zin Hein <[email protected]>
<h1>Demonstrating Component Tracking</h1> | ||
<ComponentOneView /> | ||
<ComponentTwoView /> | ||
</template> |
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.
Inspired by the sveltekit-2-svelte-5 test setup.
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 a lot @Zen-cronic, looks great to me now!
By the way, the entire JS SDK team really appreciates your contributions! @mydea sent you a message with a small thank you gift on LinkedIn a couple of days ago, in case you missed it. If this message somehow got lost, please feel free to drop me or @mydea an email (email in GH bio) :)
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #13543 Co-authored-by: Lms24 <[email protected]>
Resolves #13510
Tests to be added.
yarn lint
) & (yarn test
).