Dynamics in a static site

January 28, 2019

Photo by chuttersnap

Decompose it!

To tell the truth, medium like tooltip was implemented not to allow you to quote me in twitter (I can hardly believe somebody would ever do that). But to provide functionality for reporting typos/mistakes (at least it is useful for me).

"Why did you even created* tweet feature* thought it wasn't you original goal?" you might ask.

Well it's because of my passion to introduce everything very gradually. E.g. I prefer creating several small commits to single bigger one. And I encourage you to do the same, cause it'll make it much easier:

  • for others to review your code
  • to explore git history eventually

But small commits doesn't mean you won't get any benefits until the last commit. And they shouldn't break anything, leaving you codebase in some intermediate state. Quite the opposite, every single commit should make you app/lib/whatever better: extend api (new feature), fix and issue, etc.

The same thing with features you implement. Try to decompose them as much as possible: the smaller increment you produce, the faster you deliver it, the faster you get feedback, the better quality of product you build.

Let's get down to business

So what I mean by "functionality for reporting typos/mistakes": I want to add an action to tooltip developed in previous article, that will open dialog with form for submitting mistake.

  1. The easiest part would be to just append button to tooltip. That is how it'll look:

Typo action

  1. Now we should implement dialog. There is plenty of ready solutions for dialogs (like react-modal, also lots of UI libraries offer them), but I would like to give a try to the one from reach-ui developed by Ryan Florence. Its api is pretty straightforward, so I won't show an example with it (you can easily find it on its site). But I'd like to mentioned that to animate it I used react-spring, as I did for tooltip (and you can also find an example of using them together). Here is source code of my dialog and result:

Typo dialog

  1. The last but not least thing we should implement is backend which will receive out submissions and put it somewhere .

A in JAMStack stands for...

Wait... How static site should deal with dynamic data? Is it even possible?

Sure! Nothing stops me from using some database and API (service) to communicate with it, but:

  • I don't want to complicate infrastructure of my site Currently I am using only github pages
  • I don't want to pay for infrastructure Moreover it mostly won't be used
  • I don't want to develop back office to manage submissions
  • I want to be fancy

So I decided to use github issues as a storage and google cloud functions as a service. This allows me to address all issues above:

  • The only new thing I'll introduce is GCP function which is created in a couple of clicks
  • Unlike VMs or any other platform types, you pay only while your code runs Also GCP offers 2 million calls for free, and I probably won't be able to go beyond this limit
  • GitHub has a neat way to manage issues
  • 😎

Time to share some code, here is my cloud function:

const axios = require('axios')
const querystring = require('querystring')

const github = axios.create({
  baseURL: 'https://api.github.com',
  headers: { 'User-Agent': 'blog-typo-issue-creator' },
  auth: {
    username: 'kitos',
    // always use environment variables for sensitive data
    password: process.env.GH_TOKEN,
  },
})

exports.createIssue = async (request, response) => {
  let { title, link, source, suggestion } = request.query

  try {
    let {
      data: { html_url },
    } = await github.post('/repos/kitos/kitos.github.io/issues', {
      title: `Typo in blog post "${title}"`,
      body: `
There is a typo post [${title}](${link}).
### Source:
${source}
### Suggestion:
${suggestion}
      `,
      assignees: ['kitos'],
      labels: ['blog:typo'],
    })

    response.status(200).send({ url: html_url })
  } catch (e) {
    console.error(e.message)
    response.status(500).send(e.message)
  }
}

Pretty straightforward, right?

But you might wondering why I decided to use github api via cloud function instead of direct call. Well, I expect that not all my readers have github account and they wouldn't like to create one to submit a typo. Also later this functionality might become a part of something bigger (remember my passion to decomposition? 😏).

Integration

The last thing we should accomplish is to call our function when user submits form. It shouldn't cause any difficulties except same origin policy: gcp function domain is like

https://gcpRegion-your-app-id.cloudfunctions.net/function-name and browser would allow to make such request.

Fortunately we have CORS mechanism which allows us to tell browser that it can use our resource (cloud function) from a different domain (

www.nikitakirsanov.com). And it's to implement it using GCP (official docs): you should add special response headers:

exports.createIssue = async (request, response) => {
  ...
  response.set('Access-Control-Allow-Origin', "https://www.nikitakirsanov.com")
  response.set('Access-Control-Allow-Methods', 'GET')
  ...
}

That's it! To see a demo just select any text in this or any other article:

Read next