Suggestion

⭐ Suggestion

Navigation tree should print more information in:

• type literals
• array literals and tuples

🔍 Search Terms

outline vscode arrays types type literals extend react jsx

✅ Viability Checklist

My suggestion meets these guidelines:

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

📃 Motivating Example

Type literals

Compare these snippets of code:

interface A {
    foo: string
}

type B = {
    foo: string
}

Navigation tree (simplified):

A:
  foo
B:

It makes sense to print navigation tree of type literals, just like of object literal expressions or interfaces.

Array Literals

As an example I can provide here JSON implementation in vscode includes indexes for arrays e.g.:

[
    {
        "foo": "bar"
    },
    {
        "foo": "baz"
    }
]

Outline:

0:
  foo
1:
  foo

And having something similar in TS:

const a = [
    {
        "foo": "bar"
    },
    {
        "foo": "baz"
    }
]

Will have navigation tree (simplified):

a:
  - "foo"
  - "foo"

Which is probably okay, but can be really confusing sometimes, especially if its static array with a lot of data.

💻 Use Cases

For example in vscode having more information in outline enable more precise navigation and more ways to navigate e.g.

const a = [
  {
    a: 500
  }
]

Here you can have option to navigate to start of object literal expression or go to Nth element. As a small benefit there is a way to count number of elements in array!

Also I wonder is that possible to have JSX outline support and a better API for navigationBar? Speaking of JSX support there is well-known pattern elem.class#id (I have implemented it as plugin). But speaking of API I really want to have a way to hook into addChildrenRecursively to add / disable support for specific node kinds, so I don't need to patch anything.