fix(editor): Open only one tab with plans page

[inga-lovinde]

Issue

In community edition, clicking on "View plans" button on "Settings" -> "Usage and plan" page (e.g. http://127.0.0.1:5678/settings/usage) opens two new tabs with n8n pricing (one of them with UTM tracking, another without).
This was introduced in #6317 , when click handler of "View plans" link container started calling uiStore.goToUpgrade(...) which opens n8n pricing in a new tab, while browser opens another tab for the link URL.

The simplest fix, implemented in this PR, is to prevent default event handling (so that, after onViewPlans is called, browser will not attempt to process the click additionally as clicking on the link), similarly to how it is prevented on some other pages. It only solves the immediate problem of browser opening two new tabs on clicking "View plans".

Note that I didn't implement any tests for the changed behavior, because it was not covered by tests before, and I couldn't quite figure out how to cover it now within the existing test approach (considering that testing the fact that only one new tab is open will likely require to write entirely new tests relying on puppeteer; as far as I can see, no existing editor-ui tests are doing anything like that). I'll gladly implement tests for the new behavior if you tell me how you would like them to look.
The existing tests for editor-ui still pass; I didn't run tests for other subpackages (see "additional contribution notes" below).

Additional notes on the issue.

I'm not sure that the change in this PR is the correct long-term solution for the issue, because the URLs for these two methods (custom click handler for link container and default link handling) are slightly different:

• Custom click handler calls useTelemetryStore().track('User clicked upgrade CTA', ...); then calls sendUsageTelemetry('view_plans') (it feels weird that two calls to telemetry are made); then opens new tab for https://n8n.io/pricing?utm_campaign=open&source=usage_page (note that prior to feat(editor): Support autologin for upgrade path #7316 the second call to telemetry was done after the new tab is opened, not before);
• Link itself refers to another page, with slightly different tracking parameters: https://subscription.n8n.io/?instanceid=[REDACTED]&version=1.10.0&callback=http%3A%2F%2F127.0.0.1%3A5678%2Fsettings%2Fusage&source=usage_page; but this page redirects to https://n8n.io/pricing/.
  It is not clear which one of the two is the right way of doing things. Although goToUpgrade is called in 20 places throughout editor-ui, while viewPlansUrl, as far as I can see, is used for this button only.

Additionally, since Settings pages don't work without JS anyway, I can only think of two separate scenarios where any tab would be opened:

• Left-clicking the link (or Ctrl-clicking, or pressing Space or Enter when the link is focused, or tapping): previously, both custom click handler was executed and link's href was opened; in this PR, only custom click handler is executed (similarly to how it is done in the other places where goToUpgrade is called);
• Right-clicking (or long tapping, or opening context menu in any other way) and selecting "open link in new tab" (or similar): opens a new tab for URL from the href attribute (and does not send any telemetry at all).

I'd say that the better permanent solution would probably be to get rid of one of these methods entirely, and only rely on another in all cases (for me, as an outside contributor, the preferred way would be for custom click handler to only send telemetry, while letting my browser handle the actual navigation). However, that would be a large change, much more than one line in this PR.
Additionally, other similar places where goToUpgrade is currently called (directly or indirectly) would also need to be adapted for this change.

Additional contribution notes

As a first-time contributor, I've encountered several things I didn't expect; I'm not sure if they should be expected or are issues:

1. Tests for the entire monorepo consume a lot of RAM; 20GB free RAM was not enough, so I couldn't run tests for the entire monorepo and had to only run them for packages/editor-ui;
2. Linting is very slow; pnpm lint in packages/editor-ui takes ten minutes to complete;
3. It seems that types are not checked. Code OSS highlights numerous errors in code files: for example, 'debug' is incompatible with CloudUpdateLinkSourceType expected by goToUpgrade here:

   n8n/packages/editor-ui/src/composables/useExecutionDebugging.ts

   Line 128 in 3e7a4d3

   void uiStore.goToUpgrade('debug', 'upgrade-debug');

   
   However, I'm not getting any errors during build. There is a typecheck script defined in package.json, but pnpm typecheck fails with:

   n8n-toy-demo:~/projects/n8n/packages/editor-ui$ pnpm typecheck
   
   > [email protected] typecheck /home/inga/projects/n8n/packages/editor-ui
   > vue-tsc --emitDeclarationOnly
   
   error TS5069: Option 'emitDeclarationOnly' cannot be specified without specifying 
   option 'declaration' or option 'composite'.
   
   
   Found 1 error.
   
    ELIFECYCLE  Command failed with exit code 1.
   n8n-toy-demo:~/projects/n8n/packages/editor-ui$ 
   

   Replacing --emitDeclarationsOnly with --noEmit in package.json unblocks typechecking and results in seemingly, at first glance, correct "Found 1924 errors in 306 files" (at least several of the reported errors that I've checked seem to be correct).
   But maybe I'm missing something and there are not in fact two thousands type errors in editor-ui?

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching packages/**:

• If fixing bug, added test to cover scenario.
• If addressing forum or Github issue, added link to description.

Files matching **/*.vue:

• Used composition API for all new components.
• Added component or unit tests to cover functionality.

Files matching packages/editor-ui/**/*.vue:

• Added E2E if adding new features.
• Used design system tokens (colors, spacings...) where possible.

Make sure to check off this list before asking for review.

[alexgrozav]

Hey @inga-lovinde,

Thank you for your detailed PR and for pinpointing the issues you found.

Your short-term solution is well noted, and I’ll merge it so that we can work towards a more robust, long-term solution.

Regarding the two telemetry calls, this is an interesting point that you’ve raised, and I’ve created a ticket to look into finding other places where this happens.

Given that the component is not currently tested, we’ll merge your PR without tests, but thank you for taking the matter into consideration.

Although speeding up testing and linting is on our radar, we’re not currently addressing the issue. We’ll be tackling developer tool performance after we go through with our current runtime performance improvement plans.

You’re completely right about the editor-ui typecheck issues. We’ve recently migrated to Vue 3, which improved type safety in our components tremendously. The unfortunate downside of this is that we now have a few thousand errors to fix that were previously undetected.

We’ll be working on this during our dedicated technical debt days and we’ll gradually fix the errors.

Once again, thank you for the great remarks!

[inga-lovinde]

Thank you for the response, @alexgrozav

(Just a small clarification: my problem with tests is not that they're slow, it's that they crash my system with out-of-memory errors if I try to run all tests by pnpm test from monorepo root.)

Seeing how "Unit tests" workflow still doesn't work, and I don't know if you discuss it internally already (you probably do? Still worth it to mention this here for other external contributors, though): it's very difficult for me to diagnose the issue only by its external appearances, but I looked into things a bit, and created a new issue for that, #7423

[inga-lovinde]

I think that CI will continue failing until this branch is rebased onto the latest main (or until the latest main changes are merged here). However, unfortunately, I cannot do this right now.

UPD: Rebased and force-pushed, but workflows are awaiting approval right now.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (1307d48) 33.50% compared to head (0b92947) 33.49%.
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7377      +/-   ##
==========================================
- Coverage   33.50%   33.49%   -0.01%     
==========================================
  Files        3390     3390              
  Lines      207045   207077      +32     
  Branches    22344    22341       -3     
==========================================
- Hits        69369    69366       -3     
- Misses     136554   136589      +35     
  Partials     1122     1122              

Files	Coverage Δ
...kages/editor-ui/src/views/SettingsUsageAndPlan.vue	100.00% <100.00%> (ø)

... and 11 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[janober]

Got released with [email protected]