Skip to content

Show more items in the navbar#33040

Merged
jessetrinity merged 17 commits into
microsoft:masterfrom
jessetrinity:showMoreItemsInNavBar
Sep 11, 2019
Merged

Show more items in the navbar#33040
jessetrinity merged 17 commits into
microsoft:masterfrom
jessetrinity:showMoreItemsInNavBar

Conversation

@jessetrinity
Copy link
Copy Markdown
Contributor

@jessetrinity jessetrinity commented Aug 23, 2019

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 this properties will also be added to the navigation tree with this change.

Take the following sample:

const foo = {
    bar: {
        baz: {}
    },
    biz: function qux() {
        var quim;
    }
};

var someFunctions = function () {
    var a = () => { };
    var b = function () { };
    var c = function d() { var C; };
    var e = function () {
        var f = function () { var F; };
    };
};

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.

RoughBeforeFoo

RoughBeforeQux

All of the child functions of someFunctions are deemed unimportant and only show in the member dropdown. Indeed even function e is woefully unimportant until its child f gets its own important child.

BeforeSomeFunction

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). e and f both show, as having any child item is now considered a good enough reason to show up in navigation.

RoughFooAfter

@jessetrinity jessetrinity requested review from amcasey and mjbvz August 23, 2019 02:09
@jessetrinity jessetrinity force-pushed the showMoreItemsInNavBar branch from bc25d91 to d006ef0 Compare August 28, 2019 17:55
@jessetrinity jessetrinity marked this pull request as ready for review August 29, 2019 15:20
@jessetrinity jessetrinity force-pushed the showMoreItemsInNavBar branch from a67c5e4 to 446708a Compare August 29, 2019 17:31
@jessetrinity
Copy link
Copy Markdown
Contributor Author

@amcasey this is ready for a look when you get a chance.

Copy link
Copy Markdown
Member

@amcasey amcasey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw three distinct changes:

  1. Property assignments go in the navtree
  2. Anything with a child is "top-level" (vs special heuristics)
  3. 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?

Comment thread src/services/utilities.ts
Comment thread src/services/navigationBar.ts Outdated
Copy link
Copy Markdown
Member

@amcasey amcasey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there a binding pattern test? I didn't see one.

Comment thread tests/cases/fourslash/navigationBarAnonymousClassAndFunctionExpressions.ts Outdated
@jessetrinity
Copy link
Copy Markdown
Contributor Author

I saw three distinct changes:

  1. Property assignments go in the navtree
  2. Anything with a child is "top-level" (vs special heuristics)
  3. 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?

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 ScriptElementKind.

@jessetrinity
Copy link
Copy Markdown
Contributor Author

Was there a binding pattern test? I didn't see one.

There is an existing BindingElement test. I have updated it to check that a binding element with a function initializer is correctly named.

Also offline discussions have indicated that while people would prefer to see the method ScriptElementKind for properties with function initializers, there was less enthusiasm for doing the same for variables and binding elements. I have left those the same for now.

@jessetrinity
Copy link
Copy Markdown
Contributor Author

jessetrinity commented Sep 11, 2019

@mjbvz

The changes here that would show up in VSCode are:

  1. PropertyAssignments, ShorthandPropertyAssignments, and SpreadAssignments will show up in the navtree. Essentially all properties in a below
const a = {
    b: 0,
    c: function d(){},
    d,
    ....e
}
  1. Where a variable declaration or a property assignment has a named function initializer, we use the name of the variable or property rather than the name of the function. In the above, we would expect to see c rather than d in navigation items.

Copy link
Copy Markdown
Member

@amcasey amcasey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I think the "primary navbar" requires further explanation (i.e. in a comment).

Comment thread src/services/navigationBar.ts Outdated
/** 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[] {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the "primary" navbar the middle dropdown?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about something like "container"?

Copy link
Copy Markdown
Contributor

@mjbvz mjbvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Description of new behavior sounds good for VS Code. We will see if users have any feedback once this is available in TS@next

@jessetrinity jessetrinity merged commit fd6fbdf into microsoft:master Sep 11, 2019
@jessetrinity jessetrinity deleted the showMoreItemsInNavBar branch September 12, 2019 16:41
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants