Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Comments API #972

Merged
merged 81 commits into from
Mar 19, 2019
Merged

New Comments API #972

merged 81 commits into from
Mar 19, 2019

Conversation

rebornix
Copy link
Member

@rebornix rebornix commented Feb 25, 2019

The refactoring of registering comment threas for Pull Request list view is done but review mode part is still in progress, following code needs to be improved

  • Register comment threads for pr, review and file scheme files
  • Update them properly when there are new comments update
  • Update commenting range when document is dirtly
  • Dispose them properly

@rebornix rebornix changed the title register comments in review mode. WIP: New Comments API Feb 25, 2019
package.json Outdated
@@ -397,7 +432,6 @@
},
{
"command": "pr.refreshPullRequest",
"when": "view == pr && viewItem =~ /pullrequest|description/",
"group": "pullrequest@2"
Copy link
Member Author

Choose a reason for hiding this comment

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

It's a hack as context values seem not working when debugging.

Copy link
Contributor

@RMacfarlane RMacfarlane left a comment

Choose a reason for hiding this comment

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

I'm still doing some more testing so might add another review


export function getEmptyCommentThreadCommands(thread: vscode.CommentThread, inDraftMode: boolean, handler: CommentHandler, supportGraphQL: boolean): { acceptInputCommand: vscode.Command, additionalCommands: vscode.Command[] } {
let commands: vscode.Command[] = [];
let acceptInputCommand = {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the title for this command should also change based on whether we are in draft mode like getCommentThreadCommands below, either Add Comment or Add Review Comment

[]
);

thread.comments.forEach(comment => {
Copy link
Contributor

Choose a reason for hiding this comment

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

could move this above and then call createCommentThread with vscodeThread.comments so there's no update event

Copy link
Member Author

Choose a reason for hiding this comment

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

comment relies on thread as it's one argument for edit and delete command.

Copy link
Member Author

Choose a reason for hiding this comment

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

Here I put comments in ctor and then update comments again with proper edit/delete commands, the reason is if we create comment thread with empty comments, there are chances that VS Code focuses in the comment editor.


if (fileChange instanceof RemoteFileChangeNode) {
throw new Error('Comments not supported on remote file changes');
thread.comments = [...thread.comments, convertToVSCodeComment(rawComment!, undefined)];
Copy link
Contributor

Choose a reason for hiding this comment

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

The edit and delete commands are not being added here, we should have another method that will create comments when the thread already exists

canDelete: comment.canDelete,
isDraft: !!comment.isDraft,
userIconPath: vscode.Uri.parse(comment.user!.avatarUrl),
label: !!comment.isDraft ? 'Pending' : undefined,
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems to be an upstream issue, if I start a review, and then reload vscode, the comments are not initially shown with the 'Pending' label. I see that the label is correctly being set here. If I add another pending comment to the thread, the labels for the thread are rendered

await this._prManager.deleteReviewComment(this.pullRequestModel, comment.commentId);
const index = fileChange.comments.findIndex(c => c.id.toString() === comment.commentId);
const index = thread.comments.findIndex(c => c.commentId === comment.commentId);
if (index > -1) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If the comment is the last in the thread, we should also dispose the thread. Ditto in the reviewDocumentCommentProvider

@rebornix
Copy link
Member Author

@RMacfarlane thanks for your thorough review, I feel confident with our product quality as your review is always high quality ❤️

I addressed your comments and fixed a few upstream issues (not in Insiders yet so please wait till Monday). In addition to issues you ran into, I also fixed a few bugs with Review and comments update. Since we didn't merge this pr when I was still in office, I need your help to merge this pr. You may still run into bugs so it would be great if you have a better understanding how comment threads cache is managed in this PR

  • PR List View
    • Raw comments are saved in fileChanges, which is the same as before
    • When an editor is being opened, we will check if we already create comment threads for the newly opened editor or not. If not, we create comment threads based on fileChange.comments.
    • When an editor is being closed, we will dispose all related comment threads.
    • When we refresh the PR, we will compare the cached comment threads for this PR, with the new comments, and update accordingly.
    • Note, we only update all comment threads for PR when users attempt to refresh the PR, which is the same behavior as before.
    • When we create/update/delete comments, we need to update fileChanges.comments and visible comment threads.
  • Review
    • Raw comments are saved in fileChanges, which is the same as before
    • We will create comment threads when we detect the workspace is in review mode.
    • When we open diff view from PR List View or Changes in PR, we will create comment threads when the editor is being opened, and dispose the comment threads when the editor is being closed. The logic is the same as what we have in PR List View
    • When we create/update/delete comments, we need to update all visible review/pr comment threads and all workspace file comment threads.

The challenge here is we now moved to push mode from previous pull mode. It means we need to manage the state/cache of comment threads. It can be simple if we only need to support file scheme but life is life, we need to support pr, review and file. So if you run into weird bug, look into how we cache comment threads, usually that's where the bug is from.

The code architecture can be improved by moving the visible editors change listener to PRDocumentCommentsProvider instead of registering in PRNode and remove any pr related code from ReviewDocumentCommentsProvider but we don't need to do that now.

@RMacfarlane
Copy link
Contributor

RMacfarlane commented Mar 18, 2019

Thanks for the clear explanation! I've done some more testing and found some more issues that need to be fixed, seems like a lot of them are upstream.

  • Without checking out a PR, open a file and leave a comment. Switch to another file and then back, comment is gone
  • Leave some text in a comment without submitting it, switch to another file and do the same. Switch back, the pending comment text is overwritten
  • If clicking the gutter icon quickly, mutiple empty comment threads can be created
  • No way to remove empty comment threads
  • Toggling reaction on something I haven't reacted to tries to remove the reaction and errors out
  • Checkout a PR, then return to master. No commenting ranges are shown on any file opened from the tree after that
  • Comments on 'review' scheme diffs always show on the right side even if they were made on the base
  • The inline 'open file' action in the changes in PR tree doesn't work

Copy link
Contributor

@RMacfarlane RMacfarlane left a comment

Choose a reason for hiding this comment

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

I think it's OK to merge now.

@RMacfarlane RMacfarlane merged commit f6bb4cd into master Mar 19, 2019
@RMacfarlane RMacfarlane deleted the rebornix/commentscontrol branch March 19, 2019 23:47
alexr00 added a commit that referenced this pull request Mar 31, 2020
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.

2 participants