Land a design for NavBar and NavTo that works across editors #7523
Description
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 aNavigationBarItemcontains a memberchildItems: 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 ofchildItems(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.