Support Reactions of Comments #266

Activity

1. TylerLeonhardt

   added

   enhancementAn issue or pull request introducing new functionality to the project.An issue or pull request introducing new functionality to the project.

   triage neededAn issue that needs to be reviewed by a member of the team.An issue that needs to be reviewed by a member of the team.

   on Jul 16, 2020
2. Howard Wolosky (HowardWolosky)

   added

   discussionWe are looking for additional community feedback on this topic before proceeding further.We are looking for additional community feedback on this topic before proceeding further.

   api-reactionsWork to complete the API's defined here: https://github.com/proxy/developer.github.com/v3/reactionsWork to complete the API's defined here: https://github.com/proxy/developer.github.com/v3/reactions

   on Jul 16, 2020
3. HowardWolosky commented on Jul 16, 2020

   

   Howard Wolosky (HowardWolosky)

   on Jul 16, 2020

   Contributor

   More actions

   Some initial thoughts:

   #242 renamed Get-GitHubComment -> Get-GetHubIssueComment because it's really just focused on Issue comments. It was aliased back to Get-GitHubComment to avoid a breaking change, but it's really an Issue-focused function.

   I think it's going to be difficult to create a single function that can handle all of the different comment types. For instance, getting a specific pull request comment does not require having the pull request number available. Neither do you need the issue number to get a specific issue comment . We could in theory author the function to require the PullRequestNumber/IssueNumber, which would make the signature much more straight-forward, but trying to enable the minimum required parameters of the API means that we can't cover both types in the same function. It's a similar situation with reactions to those other comment types. We don't technically need that information to successfully use those API's, so it seems a bit artificial to require them of the user.

   I also don't think that adding an additional string parameter to capture the type of comment is a good alternative either. E.g.

   [ValidateSet('IssueComment', 'PullRequestComment', 'PullRequestReviewComment']
   [string] $CommentType

   Feel free to prove me wrong though or provide a compelling argument.

   Right now, you can see that in #172 I added Get-GitHubGistComment (which is yet another comment type, but one that doesn't support reactions), and in my ongoing pullRequests work it adds Get-GitHubPullRequestReviewComment.

   Maybe we do move forward with your current designed plan and have Get-GitHubComment/Get-GitHubReaction support all comment types, but additionally require the unnecessary parameters in order to qualify what the CommentId is referencing, but then also add type-specific functions (e.g. Get-GitHubIssueComment, Get-GitHubPullRequestComment, Get-GitHubPullRequestReviewComment, etc...) that don't require that additional data given the context is already there in the name.

   Thoughts?
4. TylerLeonhardt commented on Jul 17, 2020

   

   TylerLeonhardt

   on Jul 17, 2020

   MemberAuthor

   More actions

   Do you think there's a scenario when you want only Pull Request review comments and not Pull Request normal comments?

   I'm thinking about:

   Get-GitHubComment -PullRequest 1234
   

   What would a user expect that to do?

   Personally - I'm thinking it'd grab both review and normal comments.
5. TylerLeonhardt commented on Jul 17, 2020

   

   TylerLeonhardt

   on Jul 17, 2020

   MemberAuthor

   More actions

   but then again....... commit comments show up in pull requests on the website... so then a user might expect those to come back as well

   but I don't agree with that.
6. HowardWolosky commented on Jul 17, 2020

   

   Howard Wolosky (HowardWolosky)

   on Jul 17, 2020

   Contributor

   More actions

   Do you think there's a scenario when you want only Pull Request review comments and not Pull Request normal comments?

   I can imagine scenarios where you'd just want PR comments and not review comments. I could see that resolved possibly with a couple parameter sets (these are just the pull request-related ones):

   1. List all comments

   • [int64] PullRequest
   • [switch] $IncludeReviewComments

   2. Get a specific comment

   • [int64] PullRequest
   • [int64] Comment

   Keep in mind that this is just for Get-GitHubComment. They would look different in the type-specific functions.
   Also keep in mind that proceeding this way means that Get-GitHubIssueComment should no longer be aliased to Get-GitHubComment and instead a separate Get-GitHubComment should be created that starts to support these additional comment types.
7. TylerLeonhardt commented on Jul 17, 2020

   

   TylerLeonhardt

   on Jul 17, 2020

   MemberAuthor

   More actions

   I can imagine scenarios where you'd just want PR comments and not review comments

   Could follow Get-GitHubPullRequest's State parameter which has validate set of:

   All     Closed  Open
   

   could do:

   All     ReviewComments  GeneralComments
   

   or something like that