This is great, but it should be done via API v4 to make them appear at once and to avoid making up to 25 API v3 request at the same time.

I think we should drop the username prefix when it's the same as the current repo.

Merge sindresorhus:reaction-avatars into sindresorhus:master => Merge reaction-avatars into master

@bfred-it Should we add to the contribution guidelines that new features should prefer the v4 API?

@bfred-it commented on Nov 29, 2018, 4:14 AM GMT+1:

This is great, but it should be done via API v4 to make them appear at once and to avoid making up to 25 API v3 request at the same time.

I'll have a look again into v4. I tried it, but it wasn't that simple as v3.

Ok, I think I've got the correct query:

{
  repository(owner: "${owner}", name: "${repo}") {
    pullRequest(number: ${number}) {
      baseRef {
        name
        repository {
          url
          owner {
            login
          }
        }
      }
      headRef {
        name
        repository {
          url
          owner {
            login
          }
        }
      }
    }
  }
}

I just need to figure out how to do it with a list of ids...

I just need to figure out how to do it with a list of ids...

#438 (comment)

Should we add to the contribution guidelines that new features should prefer the v4 API?

Sure

@bfred-it commented on Nov 29, 2018, 8:23 AM GMT+1:

I just need to figure out how to do it with a list of ids...

#438 (comment)

You mean that with GraphQL it should fetch all the PR's in a project and then in the code find the correct PR?

Maybe you can use the pullRequests call instead of pullRequest (notice the former is plural).

• https://platform.github.community/t/retrieve-all-open-pull-requests-by-author/7106
• https://platform.github.community/t/how-to-query-pull-requests-merged-within-past-7-days/799

Unfortunately, it seems GraphQL doesn't do batch queries:

• [RFC] Executing multiple operations in a query graphql/graphql-spec#375
• https://platform.github.community/t/feature-request-filters-and-batch-queries-for-prs-and-branches/7671/4

Unfortunately, it seems GraphQL doesn't do batch queries:

Sure it can, that's what I showed in my previous link. You can't specify a simple list of IDs but you can request multiple things in the same query

You mean that with GraphQL it should fetch all the PR's in a project and then in the code find the correct PR?

No, you can fetch the specific IDs in the same query, so instead of:

{
  repository(owner: "${owner}", name: "${repo}") {
    pullRequest(number: ${number}) {
      baseRef {etc}
      headRef {etc}
  }
}

your query would be:

{
  id134: repository(owner: "${owner}", name: "${repo}") {
    pullRequest(number: 134) {
      baseRef {etc}
      headRef {etc}
    }
  }
  id200: repository(owner: "${owner}", name: "${repo}") {
    pullRequest(number: 200) {
      baseRef {etc}
      headRef {etc}
    }
  }
  id566: repository(owner: "${owner}", name: "${repo}") {
    pullRequest(number: 566) {
      baseRef {etc}
      headRef {etc}
    }
  }
}

or

{
  repository(owner: "${owner}", name: "${repo}") {
    id134: pullRequest(number: 134) {
      baseRef {etc}
      headRef {etc}
    }
    id200: pullRequest(number: 200) {
      baseRef {etc}
      headRef {etc}
    }
    id566: pullRequest(number: 566) {
      baseRef {etc}
      headRef {etc}
    }
  }
}

essentially querying all the PRs you see on a page, but in a single request.

You can see a live implementation here: https://github.com/bfred-it/github-issue-link-status/blob/master/source/content.js and perhaps you can steal a lot of code from it

@bfred-it I updated the code to fetch all PR's in one query. Is this the direction you were thinking of?

@sindresorhus & @bfred-it I just finished this PR 🎉, care to review again.

@bfred-it can we add one more case? the users own pr's too.

Added in d1b805c, but I'm still not entirely sure that this is useful

can we add one more case? the users own pr's too.

@yakov116 Why? What's your use-case for this?

I've been using this PR for some additional days now and my experience is that showing non-default head branch (E.g. To v10.x-staging) is useful, but I never found it useful to see non-default base branch (E.g. From foo-branch)`. A lot of projects use use repo branches for PRs instead of from forks. I don't really see why it's useful to show them in the list. The use-case from #190 was about merged PRs, not all PRs, so maybe we should only show non-default base branch for merged PRs?

Does anyone have any use-cases for having non-default base branch (E.g. From foo-branch)` in the list?

The use case for me (and team) is that we use a convention for naming branches:

<type>/<name>-<issue>-<description>

• Where <type> is the type of issue. This can be "improvement", "feature", "bug" or "task" (using a slash after it, will create a folder containing all types).
• The user's name at <name>.
• The issues related to the branch for <issue>.
• And a short <description> to summarize what the branch contains.

For example on this branch name features/jvw-103-190-pr-branches:

• It's a completely new feature...
• created by me...
• for issue Show base branch in PR list when different than master #103 and Show branch name in PR list #190...
• concerning PR branches.

This way I can see I one glance all the information what I needed, without checking out the branch or opening the PR.

Looks like information that doesn’t belong to the branch name.

• type: use labels; they’re multiple and dynamic
• username: it’s right there already
• issue number: already appears in the first post, linked. I don’t know how a plain number makes sense to anyone reading it, generally speaking, unless it’s an especially-known big number.
• description: that’s the PR title, which is more readable than a dash-case name

In short you can use them in your branch name but they don’t add much to the PR list, imho

In short you can use them in your branch name but they don’t add much to the PR list, imho

That's fine. To explain, these conventions are there for branch naming; it doesn't mean that a PR is always being created. But it was asked for an use-case, this is our use-case, and one of the reasons I created this PR.

can we add one more case? the users own pr's too.

@yakov116 Why? What's your use-case for this?

When I filter pull requests that I made I like to know if I made it from a patch (online) or I created it local

I reverted that part to avoid too much noise in the PR list. This is ready to be merged

Drop add- in filename?!

Yes