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

Use js to show status of gh issues and PR #1896

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

Carreau
Copy link
Collaborator

@Carreau Carreau commented Jun 20, 2024

See #1895.

Not that I heve the right skills and am good at desing, just show what could be done.

Need to be pulled into a separate JS file and properely desinged.

@Carreau
Copy link
Collaborator Author

Carreau commented Jun 20, 2024

Screenshot 2024-06-20 at 15 30 37

With my less than optimal design skills.

@Carreau
Copy link
Collaborator Author

Carreau commented Aug 15, 2024

Can we add @isabela-pf to the repo (even only with read access) so that we can assign her to review ?

@choldgraf
Copy link
Collaborator

choldgraf commented Aug 15, 2024

I wonder if the tool that mystmd.org uses for GitHub hover cards could be repurposed here?

@agoose77 or @stevejpurves any thoughts on that?

Either way I think that updating the statuses is pretty nice 🙂

@drammock
Copy link
Collaborator

drammock commented Aug 15, 2024

@Carreau there was a long-ish discussion before on whether this was a good idea, that ended in a stalemate: #1085

FWIW my views (one, two) on this haven't really changed since then. But there's enough new voices now that I could be outvoted!

EDIT: I realize now that the two proposals are different; here you just want to add the icons, not convert the link into the full PR title. I'm OK with adding/coloring the icons.

@drammock
Copy link
Collaborator

Can we add @isabela-pf to the repo (even only with read access) so that we can assign her to review ?

invitation sent!

Copy link

@isabela-pf isabela-pf left a comment

Choose a reason for hiding this comment

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

EDIT: I realize now that the two proposals are different; here you just want to add the icons, not convert the link into the full PR title. I'm OK with adding/coloring the icons.

I'm glad you called this out, because I was going to double check on the same after reading preceding issues. Thank you!

And many thanks to @Carreau for posting the screen shot of the result! That also makes it much easier for me to be sure what I'm looking at.

I'm going to write my comments as a numbered list for (hopefully) easier reference, but they are not reliant on one another.

  1. The icon choice is good! I am glad to see them used in the same way as the GitHub reference discussed previously.
  2. The addition of icons also makes sense considering GitHub as a reference. Do the icons get announced as a part of the link or in the tooltip, or are they visual only?
  3. I think it was a good idea to map the status colors in the GitHub reference to the ones within the theme, and I think appropriate colors were chosen. However, in this situation, I do worry that they are close in value (light/darkness) and could be easily mixed up due to colorblindness, low or bright light situations, and any other situation where color is harder to discern. If the status is reiterated in the tooltip or in a text precursor to the #xxxx I think this is acceptable. If color is the only way to tell this status, I'd like to advise an additional way of communicating.

Please let me know if you have any questions for me! This is definitely on a good track, self-appointed "less than optimal design skills" or not.

@Carreau
Copy link
Collaborator Author

Carreau commented Aug 22, 2024

Thanks for the links to #1085, I missed it. I think this is indeed much narrower in scope.

2. The addition of icons also makes sense considering GitHub as a reference. Do the icons get announced as a part of the link or in the tooltip, or are they visual only?

Currently those are just visual, we can change if we want.

3. I think it was a good idea to map the status colors in the GitHub reference to the ones within the theme, and I think appropriate colors were chosen. However, in this situation, I do worry that they are close in value (light/darkness) and could be easily mixed up due to colorblindness, low or bright light situations, and any other situation where color is harder to discern. If the status is reiterated in the tooltip or in a text precursor to the #xxxx I think this is acceptable. If color is the only way to tell this status, I'd like to advise an additional way of communicating.

I think that's my main question, I'm really not good ad design/color. If you think there are changes we need to do and you can come up with colors that work with PST that would help me. I've mostly use red/green/purple because I know that's what GitHub is doing.

I don't want to bias the design process, but should the link be colors the same way as the icon, and should for example closed issues be strikethrough. I'm tempted to think no for strikethrough as most issue reference in documentation will be to merged PR and closed issues.

@Carreau
Copy link
Collaborator Author

Carreau commented Aug 29, 2024

I likely need to use font-awesome 6 instead of 5.

@drammock
Copy link
Collaborator

drammock commented Aug 29, 2024

I likely need to use font-awesome 6 instead of 5.

or even octicons? I think a complete set for us would be:

  • PR open

  • PR closed (unmerged)

  • PR merged

  • issue open

  • issue closed (unsolved/solved is gray vs purple)

font awesome has code-merge and code-pull-request and circle-check but its circle-dot doesn't really resemble the octicon equivalent.

@Carreau
Copy link
Collaborator Author

Carreau commented Aug 30, 2024

I'm happy to use octicon, I just wanted to avoid an extra dependnecy by default.
I'klk see if I can make it work

Copy link

@isabela-pf isabela-pf 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 weighing in one more time with more explicit approval on the design front in hopes that clarifies any lingering questions. In terms of what's been done so far, I find it matches GitHub's patterns of status icons and coloring, matches pydata-sphinx-theme's design system (uses color variables and relevant icons), and is mindful of dependencies that may mess with either of these patterns from a user experience/user interface perspective. That's all good to me!

I do think this is not a change that is needed to, for example, fix a bug or anything in the pydata-sphinx-theme, so if there is a choice to not move forward with this I also think that preserves a perfectly fine experience. But if it is wanted, this proof of concept seems like the right way to go about it from the design perspective.

@trallard
Copy link
Collaborator

trallard commented Sep 6, 2024

We should be using FA 6 (this is the one we are vendoring with the theme).

@drammock
Copy link
Collaborator

drammock commented Sep 6, 2024

We should be using FA 6 (this is the one we are vendoring with the theme).

Also despite my earlier comment about octicons, I won't object to using FA6 equivalents --- we can always switch to octicons later if necessary.

@trallard
Copy link
Collaborator

trallard commented Sep 9, 2024

Sorry this was meant more at @Carreau since he is currently using FA 5

@Carreau Carreau marked this pull request as ready for review September 19, 2024 14:52
@Carreau Carreau changed the title POC: use js to show status of gh issues and PR Use js to show status of gh issues and PR Sep 19, 2024
@drammock
Copy link
Collaborator

here's a screenshot of how this will look:

Screenshot 2024-09-19 at 13-31-46 Update our kitchen sink — PyData Theme 0 15 4dev0 documentation

IMO we're not there yet:

@Carreau
Copy link
Collaborator Author

Carreau commented Sep 20, 2024

  • open and merged PRs have same color

Nah, that is because the PR I linked to has been merged since then...

underline on the icon looks odd

I did not figured out how to not underline it

I'll have a look at the rest.

Copy link

github-actions bot commented Sep 30, 2024

Coverage report

This PR does not seem to contain any modification to coverable code.

@Carreau Carreau marked this pull request as draft September 30, 2024 13:26
<script type="module">
import { Octokit, App } from "https://esm.sh/octokit";
const octokit = new Octokit();
window.octokit = octokit;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a good reason to make the octokit instance global?

Suggested change
window.octokit = octokit;

Copy link
Collaborator

@gabalafou gabalafou left a comment

Choose a reason for hiding this comment

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

Reviewing this PR has given me some ideas for how to roll it out. I am inspired by the approach that you have taken with some of your other work (for example, with same-name-different-URL links).

I think it would be good to start with just our own website first, the PST docs. To do this, I believe you need to move the JavaScript and CSS into external files and then add them to the Sphinx config:

html_css_files = ["custom.css", ("github-matches.css", {"rel": "preload"})]
html_js_files = ["pydata-icon.js", "custom-icon.js", ("github-matches.js", {"type": "module"})]

Note: using rel=preload and type=module should ensure that both files are loaded asynchronously. I believe this will cause a layout shift since you apply a CSS class that adds content (via a :before pseudo-element) after the page is rendered, but I think this shouldn't be too disruptive, since it's just an icon... but I'm not sure, which is another reason why it would be prudent to release this first only on the PST docs.

Another idea I had while reviewing this PR is that maybe this is one of those things that's better to put in the docs as a recipe rather than including it by default in the code. A recipe gives theme adopters something to follow if they wish to add this behavior to their own website, but frees us from the urgency of having to fix the code if something breaks. A recipe is also frees us from needing to get the implementation right for every site that uses PST, because a recipe can be adapted by implementers for the specific needs of each site individually.

What do you think?

</noscript>
// Regular expression to match the desired GitHub issue URL pattern
// the s in pulls/issues is technically wrong but we find it sometimes.
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(pull|issue)s?\/(\d+)$/;
Copy link
Collaborator

Choose a reason for hiding this comment

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

optional trailing slash?

Suggested change
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(pull|issue)s?\/(\d+)$/;
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(pull|issue)s?\/(\d+)\/?$/;

untested regexes make me nervous...

Comment on lines +34 to +40
const githubIssueLinks = Array.prototype.filter.call(anchorTags, function(element) {
return regex.test(element.href);
});
Copy link
Collaborator

Choose a reason for hiding this comment

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

The way you've written it is not wrong, but here is a bit more modern way to write the same thing:

Suggested change
const githubIssueLinks = Array.prototype.filter.call(anchorTags, function(element) {
return regex.test(element.href);
});
const githubIssueLinks = Array.prototype.filter.call(anchorTags, ({ href }) => regex.test(href));

// we can sometime be throttled, or just refused connection,
// just do one request on root, and if not 200, just do nothing.
const root_res = await octokit.request('GET /');
if (root_res.status == 200) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

how do you feel about turning this into an early return?

githubIssueLinks.map(async (atag) => {
const match = atag.href.match(regex);
if (match) {
const [fullUrl, username, repo,pr, issueNumber] = match;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
const [fullUrl, username, repo,pr, issueNumber] = match;
const [fullUrl, username, repo, pr, issueNumber] = match;

</noscript>
// Regular expression to match the desired GitHub issue URL pattern
// the s in pulls/issues is technically wrong but we find it sometimes.
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(pull|issue)s?\/(\d+)$/;
Copy link
Collaborator

Choose a reason for hiding this comment

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

non-capturing group?

Suggested change
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(pull|issue)s?\/(\d+)$/;
const regex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/(?:pull|issue)s?\/(\d+)$/;

if (res.data.pull_request !== undefined){
console.debug('[PST] DEBUG: 4')
pull_issue = 'pull';
state = res.data.pull_request.merged_at != null ? 'merged': res.data.state ;
Copy link
Collaborator

Choose a reason for hiding this comment

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

could you comment this line? why can't we just set the variable to res.data.state

Comment on lines 66 to 84
console.debug('[PST] DEBUG: 1')
let pull_issue = 'unset';
console.debug('[PST] DEBUG: 2')
let state = 'unset';
console.debug('[PST] DEBUG: 3')
if (res.data.pull_request !== undefined){
console.debug('[PST] DEBUG: 4')
pull_issue = 'pull';
state = res.data.pull_request.merged_at != null ? 'merged': res.data.state ;
console.debug('[PST] DEBUG: 4b')
} else {
console.debug('[PST] DEBUG: 5')
pull_issue = 'issue';
state = res.data.state;
console.debug('[PST] DEBUG: 5b')
}
console.log('[PST] adding classes to', pull_issue, state);
atag.classList.add(`pst-gh-${pull_issue}`)
atag.classList.add(`pst-gh-${state}`)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I felt a bit misled by this code because of the initial value "unset," which made me think that these are the default values, but in fact these values get reset in the unconditional else-block to "issue" and res.data.state. So I would rewrite it as:

Suggested change
console.debug('[PST] DEBUG: 1')
let pull_issue = 'unset';
console.debug('[PST] DEBUG: 2')
let state = 'unset';
console.debug('[PST] DEBUG: 3')
if (res.data.pull_request !== undefined){
console.debug('[PST] DEBUG: 4')
pull_issue = 'pull';
state = res.data.pull_request.merged_at != null ? 'merged': res.data.state ;
console.debug('[PST] DEBUG: 4b')
} else {
console.debug('[PST] DEBUG: 5')
pull_issue = 'issue';
state = res.data.state;
console.debug('[PST] DEBUG: 5b')
}
console.log('[PST] adding classes to', pull_issue, state);
atag.classList.add(`pst-gh-${pull_issue}`)
atag.classList.add(`pst-gh-${state}`)
let issueType = 'issue';
let state = res.data.state;
if (res.data.pull_request) {
issueType = 'pull';
if (res.data.pull_request.merged_at) {
state = 'merged';
}
}
atag.classList.add(`pst-gh-${issueType}`)
atag.classList.add(`pst-gh-${state}`)

Comment on lines 38 to 41
// we can sometime be throttled, or just refused connection,
// just do one request on root, and if not 200, just do nothing.
const root_res = await octokit.request('GET /');
if (root_res.status == 200) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// we can sometime be throttled, or just refused connection,
// just do one request on root, and if not 200, just do nothing.
const root_res = await octokit.request('GET /');
if (root_res.status == 200) {
// GitHub's API server may throttle us or refuse the connection,
// so make a request on root, and if not 200, just do nothing.
const rootResponse = await octokit.request('GET /');
if (rootResponse.status == 200)

//repo: 'REPO',
//issue_number: 'ISSUE_NUMBER',
headers: {
'X-GitHub-Api-Version': '2024-09-30'
Copy link
Collaborator

Choose a reason for hiding this comment

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

This line results in a 400 on the Read the Docs preview build, for example, on preview -community/topics/attribution:

"The version you specified in the "X-GitHub-API-Version" request header, "2024-09-30", is not a supported version. The following versions are currently supported: "2022-11-28" (most recent)."

@trallard trallard added this to the 0.16.1 milestone Oct 15, 2024
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.

6 participants