Helping Engineers GIF Their Best Life: Challenges Faced When Building the ‘GIFs for GitHub’ Extension

At Vend, there’s a very strict requirement on most of our repositories to include a relevant, woke, and thought-provoking GIF with each pull request.

Having to open a new tab to search GIPHY, find the right GIF, then embed it in a GitHub comment, is time-consuming, and, can have some serious negative side effects… such as lazy GIF selection:

This sparked the idea to help Vend engineers save time (and maybe be a little more considerate) when it comes to choosing an appropriate GIF for their pull request.

Building GIFs for GitHub turned out to be (surprise!) a little more difficult than I initially thought it would be. Below, I’ve shared the challenges I faced throughout this Chrome Extension journey — and no, they’re not just debates around whether it’s pronounced jif or gif…promise!

The challenges I encountered building GIFs for GitHub

The idea was to add a button to the comment toolbar, which when clicked would show a popover with GIFs from Giphy. It seemed like a straightforward idea. However, due to the dynamic nature of GitHub a few obstacles arose. Which brings me to…

Problem 1 — Adding the button to the toolbar

Adding a button to the comment toolbar isn’t as simple as ‘when the page loads — insert my button’ — comment areas can appear dynamically e.g. when you edit a pull request description, it changes from a <div> to a <textarea>, without reloading the page.

Solution

My script is external to GitHub’s, so I can’t simply manipulate their ‘on-edit’ handler to include my GIF button. My solution to this was to use MutationObserver which allows me to watch the comment node, and perform an action when the DOM tree changes. In this case, I can check if the toolbar is displayed, then add my button.

Problem 2 — Loading GIFS for GitHub when changing page

I discovered that when changing between pages, my extension code wasn’t being executed. This is because GitHub uses a JavaScript library called pjax for navigating between pages. This means when you switch from a pull request description to the files view, they fetch the contents of the next page, and replace the current page contents with this:

When switching from “Conversation” to “Files changed” the contents of the page changes, without a reload — as you can see the GIF button isn’t loaded on the second page.

The Javascript for my Chrome Extension is executed when the page loads, and because a page load doesn’t occur, the code isn’t executed and the GIF button isn’t added to the toolbar.

Solution

Pjax emits a number of global events. When the new page is loaded and the page contents has been replaced, the pjax:end event is triggered. I listen for this event and when it occurs, execute the code to add the button to the toolbar.

Problem 3 — Getting the right image size

I am using Giphy’s API to interact with Giphy, they accept a search term and return the results. For each GIF that is returned, they provide a number of different URLs for the image of varying sizes. When dragging and dropping an image on an issue or pull request, they allow images up to 10MB, so I thought I could safely use the downsized_large version of the GIF, which is <8MB.

During testing, I discovered that occasionally I would select a GIF and it wouldn’t appear when posting. After some digging, I discovered that while they allow 10MB images to be drag and dropped, they only embed images up to 5MB (I couldn’t find this documented anywhere though…).

Solution

Initially, I solved the issue by using a different image rendition i.e. instead of downsized_large which may be >5MB, use downsized_medium which is <5MB. What I found was that for images that had a downsized_large version below 5MB, the medium version was noticeably lower quality, and we definitely do not want to sacrifice on quality!

For each image size that Giphy returns, they provide the file size in bytes, so my solution to this problem, and to ensure I embed the highest quality version of the GIF, I iterate over the different image sizes and embed the best quality under the 5MB GitHub threshold.

Overall I found building the extension to be a unique challenge. Not having access to the surrounding code meant I often had to dive into GitHub’s minified code and use tools that I wouldn’t usually use, to get around the restrictions faced from this.

It was also hugely satisfying to create a tool that saves me time everyday, and openly share this to help others (hopefully!) in the same way.

If you want to check out the extension, it’s available for Chrome and Firefox.