Land a design for NavBar and NavTo that works across editors

[billti]

With the changes in #6644 , JavaScript and TypeScript currently have different NavBar implementations - which is different to the NavTo implementation. We should aim to unify the behavior and reuse logic as much as possible.

There are a couple of design challenges to work through:

• The presentation and usage of NavBars is different across editors. For example, in Visual Studio, you have a list of containers, and beside it a list of members in that container, and this is commonly used to understand/navigate the structure of the code. In VSCode, this is more a "Go to symbol" implementation, that is presented as a single list and is typically used to fuzzy search on a symbol name in the file (perhaps it should use 'navto' for file?).
• The data structure is currently different. The API returns a NavigationBarItem[], and a NavigationBarItem contains a member childItems: NavigationBarItem[]. This lends itself to a tree-like structure which VSCode handles and shows all items in its single list, whereas VS expects ALL containers to be members of the top-level array returned, with only a single-level depth of childItems (the members for that container).
• What constitutes a container? Currently TypeScript has a relatively classical structure, with the source file, namespaces and classes being containers. However it is not unusual in JavaScript to have functions within arrow functions within class members, etc... We need to figure out how this maps to editor models for presenting structure.

[mhegazy]

@basarat suggests adding a new API to return flattened list instead of having one API for all IDEs. see #8755.

[basarat]

Without looking at it too much isn't getNamedDeclarations (used on nav to) in a source file significantly slower than getNavigationBarItems (just the ast I think). I might be completely wrong 🌹

[mhegazy]

isn't getNamedDeclarations (used on nav to) in a source file significantly slower than getNavigationBarItems (just the ast I think). I might be completely wrong

They should be comparable. both do a full walk over the tree.

[felixfbecker]

Is there any public API for getting symbols in a source file that is not UI-oriented? It seems like getNamedDeclarations does what I want, but it is marked as internal. It feels wrong using getNavigationTree to do static analysis, especially since the objects emitted are not linked to the node that defines them in any way.

[basarat]

@felixfbecker if you want to live on the edge : https://github.com/basarat/byots 🌹❤️

[mhegazy]

We have landed a design for unified nav-bar between JS and TS for VS and a new navtree for VSCode. We have had this in place for over a year now with no complaints from API uses. I do not think this is needed any longer.