Show more items in the navbar#33040
Conversation
bc25d91 to
d006ef0
Compare
a67c5e4 to
446708a
Compare
|
@amcasey this is ready for a look when you get a chance. |
amcasey
left a comment
There was a problem hiding this comment.
I saw three distinct changes:
- Property assignments go in the navtree
- Anything with a child is "top-level" (vs special heuristics)
- We use the property/variable name, rather than the initializer name, if the initializer is a function
Does that sound right? Did I miss anything?
This basically looks good - my main concern is that there might be other interesting SyntaxKinds.
I haven't read through the test changes yet, but I'm a little surprised to see that there aren't new tests. Maybe existing tests were expanded?
amcasey
left a comment
There was a problem hiding this comment.
Was there a binding pattern test? I didn't see one.
Your summary sounds correct. Mostly I just updated tests because this change should largely just make existing navbar tests more like the navtree ones. I have added some more specific test for nested object literals to address (1) and a test for the function initializer |
There is an existing Also offline discussions have indicated that while people would prefer to see the |
|
The changes here that would show up in VSCode are:
const a = {
b: 0,
c: function d(){},
d,
....e
}
|
amcasey
left a comment
There was a problem hiding this comment.
LGTM, but I think the "primary navbar" requires further explanation (i.e. in a comment).
| /** Flattens the NavNode tree to a list, keeping only the top-level items. */ | ||
| function topLevelItems(root: NavigationBarNode): NavigationBarNode[] { | ||
| const topLevel: NavigationBarNode[] = []; | ||
| function primaryNavBarItems(root: NavigationBarNode): NavigationBarNode[] { |
There was a problem hiding this comment.
Is the "primary" navbar the middle dropdown?
There was a problem hiding this comment.
Explained it the comment where the selection actually occurs. I was trying to be 'editor agnostic' but I will just update 'primary' to 'middle' since (I think) this is VS only anyway.
There was a problem hiding this comment.
What about something like "container"?
mjbvz
left a comment
There was a problem hiding this comment.
Description of new behavior sounds good for VS Code. We will see if users have any feedback once this is available in TS@next
Currently the navigation bar in Visual Studio is not very useful for JavaScript files. We make the choice to show an item in the navbar based on the node type of its child items, and in some cases, its parent node.
By relaxing most the rules around what makes a navigation item "top level," we will get a more informative code hierarchy in the middle "object" dropdown, similar to how the navtree is presented in VSCode.
The right "member" dropdown always shows the child nodes of whichever node is selected in the middle dropdown, so we can keep navigation leaf nodes out of the middle dropdown to reduce clutter.
Property assignments and class
thisproperties will also be added to the navigation tree with this change.Take the following sample:
Before
Property assignments do not show up, so we don't see any structure of nested objects (see
foo) unless they have an 'important' node such as a function (qux). In those cases, the name of the function shows up in the child items list rather than the more intuitive member name.All of the child functions of
someFunctionsare deemed unimportant and only show in the member dropdown. Indeed even functioneis woefully unimportant until its childfgets its own important child.After
Property assignments now show up in navigation, and the name of the property shows instead of the function name.
We keep the decision to not show functions with empty bodies in the middle dropdown (though they do show as a child item in the right dropdown).
eandfboth show, as having any child item is now considered a good enough reason to show up in navigation.