Skip to content
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

Merged
merged 5 commits into from
Sep 9, 2024

Conversation

Zen-cronic
Copy link
Contributor

Resolves #13510

Tests to be added.

  • If you've added code that should be tested, please add tests.
  • Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) {
currentCompo = `<${currentCompo}>`;
}
return formattedName === currentCompo;
Copy link
Contributor Author

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 < >.

Copy link
Contributor Author

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.

@Zen-cronic Zen-cronic marked this pull request as ready for review September 3, 2024 01:00
Copy link
Member

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

Comment on lines 52 to 57
let currentCompo = compo;

if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) {
currentCompo = `<${currentCompo}>`;
}
return formattedName === currentCompo;
Copy link
Member

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:

Suggested change
let currentCompo = compo;
if (!(currentCompo.startsWith('<') && currentCompo.endsWith('>'))) {
currentCompo = `<${currentCompo}>`;
}
return formattedName === currentCompo;
return compo.replace(/^<(.*)>$/, '$1') === formattedName

Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Noted

Copy link
Contributor Author

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> or App
  • Formatted: either <App> or <App> at App.vue.

What do you think?

Copy link
Member

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

Copy link
Contributor Author

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.

@Lms24 Lms24 self-assigned this Sep 4, 2024
@Zen-cronic
Copy link
Contributor Author

Just read your comments and review, I'll take them up now. Thanks!

Copy link
Member

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

*
*/
function extractComponentName(name: string): string {
return name.replace(/^<([^\s]*)>(?: at [^\s]*)?$/, '$1');
Copy link
Contributor Author

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.

Copy link
Member

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!

'sentry.op': 'ui.vue.mount',
'sentry.origin': 'auto.ui.vue',
},
description: 'Vue <<HomeView>>',
Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

@Lms24 Lms24 left a 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 }) => {
Copy link
Member

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

Copy link
Contributor Author

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.

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>
Copy link
Contributor Author

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.

Copy link
Member

@Lms24 Lms24 left a 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) :)

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.

Vue trackComponents allowlist should match for components without <>
2 participants