Refined-github: Autocompletion for commit SHA

[stefanbuck]

When I work on code review comments, I often refer to a commit where this particular issue was solved. This requires manually copy & pasting the commit sha and this really annoys me.

Wouldn't it be cool, if you could trigger an autocomplete prompt for commit sha like you can do for GitHub users with the @-Sign?

[busches]

The users prompt has a nice start with the @ sign, what would be the trigger to call for a commit sha prompt, 0-9 and a-f? Doing that seems like we'll hit the API limit quickly unless we require 3 or more characters to match. Curious to what your thoughts are on implementation pattern.

[stefanbuck]

Ohh I just realised that my description is a bit lacking. Initially I was just referring to commits within the current Pull Request (not all commits from a repository). However, from a user perspective it would be better to take all commits into account to avoid confusions.

It should behave similar to the username or issue autocompletion which can be invoked with @ or #. Since those two keys are already taken, I thought that the tilde key would be perfect trigger for the commit autocompletion.

[sindresorhus]

This would be very useful. I often need to reference commits, and end up having to open a new tab and waste time. I'm ok with using tilde.

Does GitHub have an API endpoint we could use for this, to search for commits by SHA or title? How would you implement this?

[sindresorhus]

Also make sure to suggest this feature to GitHub too: https://github.com/contact

[stefanbuck]

Sure, I'll drop them a message.

Implementation wise, there is an API endpoint to search through commits, but it's currently in preview which means it can change any time. https://developer.github.com/v3/search/#search-commits

[fregante]

This is a rather complex feature. Maybe it can be done by reusing GitHub's own endpoints and UI. Help wanted to reverse engineer the existing @ or # autocompletion

[artusm]

@fregante

Help wanted to reverse engineer the existing @ or # autocompletion

An example of a custom autocompletion.

async function apiRequest(text) {
  const values = ["value", "value1", "value2", "test1", "value2"];

  return values.filter((value) =>
    value.toLowerCase().includes(text.toLowerCase())
  );
}

async function searchSHA(text) {
  const autocompleteValues = await apiRequest(text);

  const fragment = document.createElement("ul");
  fragment.setAttribute("role", "listbox");
  fragment.className =
    "suggester-container suggester suggestions list-style-none position-absolute";

  fragment.innerHTML = autocompleteValues
    .map(
      (
        value,
        i
      ) => `<li role="option" id="suggester-example-${i}" data-value="${value}">
    <span>${value}</span>
    <small>${value}</small>
  </li>`
    )
    .join("");

  return {
    matched: autocompleteValues.length > 0,
    fragment,
  };
}

const textExpander = document.querySelector("text-expander");
textExpander.setAttribute("keys", `${textExpander.getAttribute("keys")} !`);
textExpander.addEventListener("text-expander-change", (event) => {
  const { key, provide, text } = event.detail;
  if (key !== "!") return;

  provide(searchSHA(text));
});
textExpander.addEventListener("text-expander-value", (e) => {
  if ("!" !== e.detail.key) return;

  e.detail.value = `--__${e.detail.item.dataset.value}__--`;
});

[fregante]

Not too bad. Do we have to handle the list generation and API rate limiting ourselves? I thought that the UI would at least be handled by GitHub

[fregante]

That looks correct according to https://github.com/github/text-expander-element :tada:

I suppose your code is only missing the api.v4 call to get the commit list. Also it can use JSX to generate the fragment effortlessly

[artusm]

Also it can use JSX to generate the fragment effortlessly

I know. It was just an example.

I suppose your code is only missing the api.v4 call to get the commit list

event listener (text-expander-change) added from Content Scripts - detail: null

event listener (text-expander-change) added from console - detail: {...}

It looks like we can't access to event.detail from Content Scripts (Only in Chrome).

Update: It works in Firefox

[fregante]

That's likely due to isolation. I thought events were somewhat safe from this…

We worked around this for resolve-conflict, even if it's not pretty.