Skip to content

Support "jump to" for literal record keys #54937

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

Open
5 tasks done
donaldpipowitch opened this issue Jul 9, 2023 · 3 comments
Open
5 tasks done

Support "jump to" for literal record keys #54937

donaldpipowitch opened this issue Jul 9, 2023 · 3 comments
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@donaldpipowitch
Copy link
Contributor

Suggestion

πŸ” Search Terms

  • jump to record key

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Record keys should support "Jump to definition" actions.

πŸ“ƒ Motivating Example

type Something = { field: string };

type Somethings<Keys extends string> = Record<Keys, Something>;

type ContainerOfSomethings = Somethings<'a' | 'b'>;

const container: ContainerOfSomethings = {
    a: { field: 'a' },
    b: { field: 'b' }
};

console.log(container.a);
                     // ^---- "Jump to" should bring me to line 5 where 'a' is listed

Playground Example

πŸ’» Use Cases

Enhance Developer Experience.

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Jul 10, 2023
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jul 10, 2023
@suica
Copy link
Contributor

suica commented Jul 18, 2023

In fact, sometimes it can be really tricky to track for the definition of key. Maybe we can only support a portion of them. For example, the original Record type constructor.

Naive case

type A = 'a' | 'b';
declare const test: {[x in A]: string}
test.a

Expected to show type A.

Simple case

type A = 'a' | 'b';
type C = 'a' | 'c';
declare const test: {[x in A | C]: string}
test.a

Expected to show a definition list of length 2, including type A and type C.

Complicated case

type A = 'a' | 'b';
type C = 'a' | 'c';
declare const test: {[x in A extends C ? A : C]: string}
test.a

Expected to show the definition is from type A. But can be not very easy to implement in few lines of code.

@suica
Copy link
Contributor

suica commented Jul 19, 2023

There is a hard-coded implementation of the idea.
One the tricky problems is that in fact we cannot get declaration at a in rec.a (as there is no declaration field in the symbol, unlike a regular object). Type literals are just not symbols, hence TypeScript only defined what's declaration for symbols.
So, in the implementation I searched both the AST level and the type level to find the exact so-called "declaration".
It's really awkward.
Looking for feedbacks! :)

@Andarist
Copy link
Contributor

There is a good overlap between this issue and those two: #49033 , #45549

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants