Repository navigation
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.
Activity
mhegazy commentedon May 23, 2016
Basarat Ali Syed (@basarat) suggests adding a new API to return flattened list instead of having one API for all IDEs. see #8755.
basarat commentedon May 23, 2016
Without looking at it too much isn't
getNamedDeclarations(used on nav to) in a source file significantly slower thangetNavigationBarItems(just the ast I think). I might be completely wrong 🌹mhegazy commentedon May 23, 2016
They should be comparable. both do a full walk over the tree.
felixfbecker commentedon Jun 8, 2017
Is there any public API for getting symbols in a source file that is not UI-oriented? It seems like
getNamedDeclarationsdoes what I want, but it is marked as internal. It feels wrong usinggetNavigationTreeto do static analysis, especially since the objects emitted are not linked to the node that defines them in any way.basarat commentedon Jun 8, 2017
Felix Becker (@felixfbecker) if you want to live on the edge : https://github.com/basarat/byots 🌹❤️
mhegazy commentedon Aug 31, 2017
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.