Skip to content

Add commands for navigating the steps on a path#175

Merged
jcreedcmu merged 4 commits intogithub:masterfrom
asgerf:asgerf/path-result-nav
Nov 25, 2019
Merged

Add commands for navigating the steps on a path#175
jcreedcmu merged 4 commits intogithub:masterfrom
asgerf:asgerf/path-result-nav

Conversation

@asgerf
Copy link
Copy Markdown
Contributor

@asgerf asgerf commented Nov 21, 2019

This adds the command CodeQL: Show Next Step on Path and CodeQL: Show Previous Step on Path for navigating the steps on the currently shown path.

The idea is that you can add keybindings for these commands to navigate the path without the mouse. Doing this with the mouse required quite a bit of zig-zag eye tracking between the code view and result view.

You still have to click one of the steps on a path to "choose" that path. There are currently no commands for switching between results or paths. It would be nice to have a fully keyboard-controllable result view, but I think I'll leave that for a future PR.

It's a bit of a hassle to make the result view remember which path node was previously clicked. For this we need a way to reference a specific part of the result set, that is, a result index, path index, and a path step index. I introduced the types Keys.Result, Keys.Path, and Keys.PathNode to represent such indices.

Commit-by-commit review recommended.

@asgerf asgerf requested a review from jcreedcmu November 22, 2019 07:04
jcreedcmu
jcreedcmu previously approved these changes Nov 25, 2019
Copy link
Copy Markdown
Contributor

@jcreedcmu jcreedcmu left a comment

Choose a reason for hiding this comment

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

Mostly lgtm, just a couple of optional nits.

export function getResult(sarif: sarif.Log, key: Result): sarif.Result | undefined {
if (sarif.runs.length === 0) return undefined;
if (sarif.runs[0].results === undefined) return undefined;
let results = sarif.runs[0].results;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This can be const, yeah?

super(props);
this.state = { expanded: {} };
this.state = { expanded: {}, selectedPathNode: undefined };
this.handleNavigationEvent = this.handleNavigationEvent.bind(this);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I almost prefer to have the .bind(this)s at the callsite, or else give the property the .bind()ed method a different name from the original method name. Do you have a strong opinion here? I haven't seen this pattern before but am willing to defer if you feel like it's idiomatic.

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.

I'd say it's quite common. It's recommended on reactjs.org, with the other alternative being to make the method into a field instead.

We generally recommend binding in the constructor or using the class fields syntax, to avoid this sort of performance problem.

@jcreedcmu jcreedcmu merged commit e056c61 into github:master Nov 25, 2019
@shati-patel shati-patel mentioned this pull request Dec 12, 2019
@asgerf asgerf mentioned this pull request Oct 5, 2022
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants