Cmd+click of JSX component shows type definition in VSCode, instead of linking to component definition

[davnicwil]

As requested by @RyanCavanaugh on issue #24809 - reopening the issue with an updated concrete way to reproduce.

Tested with latest VSCode 1.43, latest typescript 3.8.3.

Simply create a .tsx file in VSCode with the following content:

import React from 'react'

const Thing: React.FC<{ text: string }> = (props) => <div>{props.text}</div>

const HelloWorld = () => <Thing text="hello world" />

And cmd+click on <Thing on line 5

Expected behavior:

Cursor moves to definition of const Thing on line 3.

Actual behavior:

VSCode opens a definitions window with links to 2 definitions:

1. The component definition on line 3 (that I expected to be linked to)
2. The definition for the type of the component: React.FC, in node_modules/@types/react.

---

This seems like a bug. In practice it means navigating is broken for JSX components, as cmd+clicking to link doesn't work - you have to cmd+click then click on the code definition again in the definitions window.

I am pretty sure that in the vast, vast majority of cases, when people cmd+click on the JSX for a component, they want to link to the component's definition and not the type.

Even supposing people did want to do that, in some cases:

1. Just seeing what the type is would be solved in one click, because it is there in the definition
2. Navigating to that type definition if you really wanted to would remain at 2 clicks - by just cmd+clicking it right there in the definition.

So, there seems no downside here. Improve (fix) the most common usecase, less common (if ever) usecase still works, still 2 clicks.

[nk1tz]

I just want to bump this thread and say that I am also feeling this pain.
My click throughs are broken..
@davnicwil until this is fixed, you might appreciate that it is possible to hit enter after first click to go to file.
Not a great workaround but its something 😄

[davnicwil]

@nk1tz great shout - I'm probably doing this 100s of times a day so removing the friction even a little is really helpful. Cheers!

[JulianKingman]

Can you clarify the workaround? I can't figure out how to get to the source file. I command+hover, it brings up some definitions, but I can't get anywhere from there (command clicking does nothing)

[davnicwil]

@JulianKingman cmd+click on the component itself (i.e. <Thing), it brings up the definitions (like in the screenshot), then pressing the enter key navigates to the actual component definition. Just saves you that second click in the definitions popup.

[varemenos]

I'm experiencing this a few hundred times a day as well, It's a really frustrating experience.
Most of our React components are based on React.FC making jump to definition a constant chore.

[bcole808]

Just wanted to bump the thread to say I am also experiencing this friction a lot; it's also frustrating that the first suggestion on the list is the result from node_modules/@types/react and not the actual line where const Thing = is defined.

A non-ideal workaround is to re-write it so that the function argument has the type definition:

const Thing = (props: React.PropsWithChildren<{ text: string }>) => (
  <div>{props.text}</div>
);

const HelloWorld = () => <Thing text="hello world" />;

This avoids the problem where the definition lookup of <Thing> suggests the unwanted type from node_modules/@types/react. However, this workaround is a less specific type definition because the return value of the function doesn't have a type declared which isn't great.

[sambecker]

Dealing with this all day long in a React TypeScript project. All components are typed React.FC and exported as default.

One fix that's helped is changing Editor > Goto Location: Multiple Definitions from peek to goto in settings.

Obviously, this will end up concealing some secondary definitions that might actually be useful to know about but in the meantime it makes command-clicking components behave as I would expect it to.

[apeqqut]

I would love for this to be resolved as well. Thanks @sambecker for the tip! That definitely helps as a workaround.

[Miaonster]

Hello guys, I made a simple vscode extension to resolve this problem. vscode-tsx-arrow-definition, and you can search vscode extension marketplace to find it.

This extension's function is simple:

• If there're more than one defintions, and one definition is @types/react/index.d.ts, just remove it from the definition list.
• If there's only one definition or no definition is @types/react/index.d.ts, just use the original result.

Hope this helps.

[mliq]

I've not had a problem with this because I've used "Goto" as mentioned above by @sambecker. Suddenly today my "Goto" is defaulting to the @types/react/index.d.ts instead of the actual component, and it is driving me nuts.

Any solutions?
I'm not sure if something changed in VSCode or my project.

What determines the order of the definitions and can we reprioritize them?

A setting to state that anything in node_modules or *.d.ts should not be the first/default definition if multiple exist would be one way to solve this.