Implement Gist onebox

feature
,
1

We had a naive implementation for Gist oneboxes, however it failed miserably due to dynamic loading:

In particular this:

To resolve this issue:

The Gist oneboxer should use a similar approach to the blob oneboxer

  1. It must take care of truncating huge files
  2. It must take care of displaying gists with multiple files

Syntax highlighting is to be handled by our pre-existing syntax highlighting engine, all the onebox is to do is to decorate divs with the guessed syntax.

I thought of possibly using therubyracer to evaluate the gist js, but it inserts stylesheets. Additionally there is a possibly iframe approach but it will be both slower (and impact rendering) and more fragile.

3 Likes
2

Iā€™m working on it.

Itā€™s relevant, right?
(Iā€™m asking because is an ā€œold topicā€ rs)

Thanks.

2 Likes
3

Hi,

I was following a similar approach to the blob oneboxer, that is to make requests to ā€œGist APIā€ and build a HTML component on server side. It sounded clean for me.

However, Iā€™m concerned about something that read here (https://developer.github.com/v3/#rate-limiting):
ā€œFor unauthenticated requests, the rate limit allows you to make up to 60 requests per hour.ā€

I think that is a bad idea to make requests to Gist API from server side, considering that low limit. So, what do you think about to make these requests from the client side
@sam?

Some JavaScript would be added in the mustache templete to keep the component decoupled.

Thanks!

4

I think the onebox content is all baked into the cooked HTML, which means that the server only needs to hit the Gist API once for any given link.

2 Likes
5

Hmmā€¦ I donā€™t think soā€¦

The flow that Iā€™m thinking is:

  1. The ā€œGist URLā€ is detected in the message:
    https://gist.github.com/karreiro/208fdd59fc4b4c39283b

  2. We detect the URL and the sha: 208fdd59fc4b4c39283b

  3. We make a request to ā€œGist APIā€ to obtain the information:
    https://api.github.com/gists/GIST_ID
    https://api.github.com/gists/208fdd59fc4b4c39283b

Finally, we manipulate the JSON response to cook the HTML through a mustache template, that would be something like this:

<h4>
  <a href="{{link}}" target="_blank">{{title}}</a>
</h4>
{{#gist_files}}
  <section>
    <pre>
      <h5>
        {{filename}}
      </h5>
      <code class='{{language}}'>
        {{content}}
      </code>
      {{#truncated}}
        This file has been truncated. <a href="{{link}}" target="_blank">show original</a>
      {{/truncated}}
    </pre>
  </section>
{{/gist_files}}

So, every time that we detect a Gist URL, weā€™ll need to make a different request to ā€œGist APIā€ to obtain specific information.

Am I right? .-.

Thanks! :slight_smile:

6

Correct, so a condition where users on your site are posting more than 60 gists per hour in posts would be ā€¦ presumably ā€¦ quite rare.

Also ā€¦ we are open to a PR that wires in GitHub OAuth stuff if you really want it.

1 Like
7

Ohh! Now I realised what @mcwumbly said!

Thank you guys.

Iā€™ll keep the server side approach, without the OAuth implementation, for while.

Thanks again. :wink:

8
6 Likes
9

Can we now mark this as closed/implemented?

10

Nope,

https://gist.github.com/mitsuji/bd667abfd11b2be45612

1 Like
11

I guess it is working now! :partly_sunny:

1 Like