Navigation tree overhaul

[zardoy]

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.

[RyanCavanaugh]

I feel like if anything, the bug here is that foo appears in A in the first place. The navigation tree, in my view, is so that you can jump to the correct screenful of code within a file. The odds that A is so long that you can't see foo once you've gotten there are very low, and that situation would call for different metaphors anyway since the nav tree would also be too long at that point. I agree that they should be consistent though; people use these syntaxes interchangeably and it's weird for them to be different.

The behavior requested here feels like having a book whose Index reprints all of its content - the whole point is to have a reduced navigable digest of the content, not a retelling of it.

@mjbvz can you weigh in on what should happen here?

[fatcerberus]

Yeah, I’m inclined to agree - showing individual properties of an interface in the nav tree feels like noise.