Forem: Darren Jennings

Personal Gifs as a Service

Darren Jennings — Wed, 08 Jul 2020 20:05:47 +0000

I realized that generating random gifs, while wildly amusing, is not very
personal. I also love using emojis 😅 but find them also to not be very
personal. I wanted a way to communicate to my coworkers and friends, but also I
wanted them to be able to see my ridiculously good-looking face 😝

The result: "darren gifs as a service"

Now I can call upon the internet (like zeus calling for lightening ⚡️) at any given moment to render a personalized, hand-crafted gif.

Here's a view into what it looks like when invoking the alfred function in slack:

Creating your own gif service

Create Your Gifs
Upload it to a publicly accessible location e.g. GitHub
Add a Netlify redirect to a Netlify site
Invoke the url from anywhere

Create Your Gifs

Gifs can be created with a few services these days. The key is to optimize them so they're not too big. I use Giphy Cam which allows me to easily take gif selfies and add little effects to make them
more fun like text or sparkles.

I then tried to find a service that optimizes them. I found gifsicle which optimizes gifs for space. My face is nice, but does it really need to be 10MB?

yarn install gifsicle
yarn gifsicle --batch --optimize=200 --colors 256 <gif>.gif

Upload the Gifs to a Publicly Accessible Location

I upload all my gifs to a GitHub repo. The optimization in the previous step is important here so that you don't store too much... You can easily store these in any CDN such as cloudinary or S3. The key here is that you want to be able to remember the name of your gifs so name them short and sweet like "yw.gif" for "you're welcome" or "no.gif", "yes.gif".

Keep the gif url of your publicly accessible gifs handy. You will need it in your next step.

https://raw.githubusercontent.com/darrenjennings/darren-gifs/master/gifs/

Add a Netlify Redirect to a Netlify Site

Redirects in netlify are dead simple (and free). If you have an existing domain or Netlify site (did I mention they're free?) then you can add a redirect file in the root of the deployed site. Grab your gif
url and put it as the target of your redirect:

dist/_redirects

https://guuu.io/gifs/:name  https://raw.githubusercontent.com/darrenjennings/darren-gifs/master/gifs/:name.gif  301

Now I can access a gif on GitHub via a netlify redirect:

https://guuu.io/gifs/yay

becomes:

https://raw.githubusercontent.com/darrenjennings/darren-gifs/master/gifs/yay.gif

Note:
If your site has a build process, you will need to make sure that the _redirects file is in the same directory as your built site, e.g. /dist

Here's the file on my site for reference:
guuu.io/_redirects

Invoke the URL

I am a big fan of Alfred after watching
John Lindquist stream about Alfred workflows. I added a small workflow that allows me to type d <gif_name> into my search bar which will paste the url wherever my computer cursor is. This allows me to react very quickly like the giphy slackbot but it works in any venue (Discord, Slack, Messages, Texting, etc.). Most everyone has access to the internet so it works well this way to host my own gifs and the previews even follow the redirects correctly. I also append a timestamp as a query param because sometimes slack won't unfurl a link that it's seen before, but I want to spam my coworkers with my gif even if they've seen it.

I also find that my domain is short enough that I can easily type it out letter by letter, so even if I don't have an Alfred workflow I can usually call upon the links from memory. https://guuu.io/gifs/beautiful

Check out my GitHub repo to see the source, and all my gifs and a copy of the alfred workflow

Data Fetching using Vue Hooks

Darren Jennings — Tue, 11 Feb 2020 15:24:06 +0000

Canonical URL: https://guuu.io/2020/data-fetching-vue-composition-api/

I discuss data fetching in Vue - where it stands today, and how a library like swrv can solve some common problems utilizing stale-while-revalidate caching.

Data fetching in an app can be a bit convoluted. If you're making XHR requests, you might see low latency from your high speed network connection or your low latency local network. You can emulate network conditions, but optimizing for speed can be an afterthought. While you want to empathize with your user base, implementing a frontend caching layer to speedup data fetches is usually low priority, especially if you reason that most of your users have high-speed connections / powerful devices.

Fetching Data in Vue

Traditionally in Vue, you might fetch your data in the mounted hook, sometimes called "render then fetch"

<template>
  <div :key="user.username" v-for="user in users">
    {{ user.username }}
  </div>
</template>

<script>
export default {
  name: 'Users',
  data() {
    return {
      users: []
    }
  },
  mounted() {
    fetch('/api/users')
      .then(res => res.json())
      .then(myJson => {
        this.users = myJson
      })
  }
}
</script>

There are many options now in how a developer might go about
fetching data, so even if you are triggering a fetch at different points in the render
lifecycle, your application typically will be constrained by the eventual inconsitent and cascading network latency.

For example if we also want to show all users with a link to their profile, e.g. a <UserProfile> component, the profile page will then need to fetch data from both the user and the user profile endpoints.

<UserProfile> component being loaded

This is common in RESTful endpoints when an endpoint doesn't support
eager relations, specify join
fields, or if you are not using GraphQL
which is able to specify multiple return entities. The subsequent mounting and
network cost blocking the render could get expensive.

<template>
  <div v-if="profile">
    <img class="avatar" :src="profile.avatar" />
    <div>{{ profile.user.username }}</div>
    <div>{{ profile.twitter }}</div>
  </div>
  <div v-else>
    <Loading />
  </div>
</template>

<script>
export default {
  name: 'UserProfile',
  props: {
    username: {
      type: String,
      required: true
    }
  },
  data() {
    return {
      profile: null
    }
  },

  mounted() {
    fetch(`/api/user/${this.username}`)
      .then(res => {
        return res.json()
      })
      .then(user => {
        fetch(`/api/user/${user.id}/profile`)
          .then(res => {
            return res.json()
          })
          .then(profile => {
            this.profile = {
              ...profile,
              user
            }
          })
      })
  }
}
</script>

This gets a bit ugly and is not reactive in the event that username changes. Let's clean it up a bit with the @vue/composition-api to keep the data flowing and utilize the new vue setup function.

<template>
  <div v-if="profile">
    <img class="avatar" :src="profile.avatar" />
    <div>{{ profile.user.username }}</div>
    <div>{{ profile.twitter }}</div>
  </div>
  <div v-else>
    <Loading />
  </div>
</template>

<script>
import { ref, watch } from '@vue/composition-api'

export default {
  name: 'UserProfile',
  props: {
    username: {
      type: String,
      required: true
    }
  },
  setup(props) {
    const profile = ref([])

    // when props.username changes, vue's reactivity automatically
    // registers the change and re-triggers the data fetch.
    watch(() => {
      fetch(`/api/user/${props.username}`)
        .then(res => res.json())
        .then(user => {
          fetch(`/api/user/${user.id}/profile`)
            .then(res => res.json())
            .then(profile => {
              profile.value = { ...profile, user }
            })
        })
    })

    return {
      profile
    }
  })
}
</script>

Now that we have the data flowing, there is still a cost to rendering this component. If a user navigates away, then returns, the component will fetch the data all over again, even though the user just saw the data! This becomes frustrating for end users who are at the mercy of their network speeds.

Caching the Response

Have you ever clicked a "back" link in a web application and the data that you just saw is now taking an obscene amount of time to refetch? The browser can sometimes help with cache headers, and browser history cache, but in modern applications the server side rendered portion of our pages are only a segment of a user's navigation lifecycle. We need a multi-pronged caching strategy so that our dynamic pages, with client-side fetching, can be consistently fast and always online.^[1]

Stale-while-revalidate

Stale-while-revalidate (SWR) is a cache invalidation strategy popularized by HTTP RFC 5861.

If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).

The key here is "not blocking". In our earlier example, the <UserProfile> component would fetch from /api/users, then /api/users/:id/profile, always assuming that new fetches were fresh. This is a good thing, since users always want to see the latest data. However, this blocked the rendering of data until a response was received, even if a user had seen the response recently.

A SWR caching strategy would allow users to see stale data first while fetching, giving an eventually consistent UI.

Profile immediately returns from cache on the left, then once the fetch finishes,
then the new image/twitter handle is updated.

In the component, you might want to cache a response in a global store or localStorage. Here's our component might work:

import { ref, watch } from '@vue/composition-api'

export default {
  name: 'UserProfile',
  props: {
    username: {
      type: String,
      required: true
    }
  },
  setup(props, { root }) {
    const profile = ref([])

    function getFromCache(key) {
      return root.$store.getters['cache/getCacheItem'](key)
    }

    const cacheKey = `${props.username}-profile`

    watch(() => {
      // get STALE content and set data
      profile.value = getFromCache(cacheKey)

      // WHILE-REVALIDATE and go fetch the data anyways,
      // producing immediately cached results, with an
      // eventually consistent UI.
      fetch(`/api/user/${props.username}`)
        .then(res => res.json())
        .then(user => {
          fetch(`/api/user/${user.id}/profile`)
            .then(res =>  res.json())
            .then(profile => {
              profile.value = {
                ...profile,
                user
              }
              root.$store.dispatch('cache/setCacheItem', {
                key: cacheKey,
                profile
              })
            })
          })
        })

      return {
        profile
      }
    })
  }
}

This helps us get the strategy correct, but we'd like to have a library do this for us, so that we can have a simpler api while continuing to add new features: in-flight de-duplication, library agnostic fetching, error handling, loading states, different caching strategies, polling, onFocus revalidation etc.

Introducing swrv

swrv is a library using @vue/composition-api hooks for remote data fetching. It is largely a port of swr. Our example can be refactored:

import fetcher from './fetcher'
import useSWRV from 'swrv'

export default {
  name: 'UserProfile',
  props: {
    username: {
      type: String,
      required: true
    }
  },

  setup(props) {
    const { data: user, error: error1 } = useSWRV(
      `/api/users/${props.username}`,
      fetcher
    )
    const { data: profile, error: error2 } = useSWRV(
      () => `/api/users/${user.value.id}/profile`,
      fetcher
    )

    return {
      profile
    }
  }
}

In this example, the Vue Hook useSWRV accepts a key and a fetcher function. key is a unique identifier of the request, and here it is the URL of the API. The fetcher accepts the key as its parameter and returns the data asynchronously. The key can also be a function, with its own dependencies. The second useSWRV hook actually has a dependency on the response from the first hook. swrv will handle this by watching dependencies inside the key function and re-validate when these change. This is helpful for avoiding unnecessary fetches, and also reacting to key changes, in the event you'd like to pass in query params such as pagination/filtering.

useSWRV here returns 2 values: data and error. When the request (fetcher) is not yet finished, data will be undefined. And when we get a response, it sets data and error based on the result of fetcher and rerenders the component. This is because data and error are Vue
Refs, and their values will be set by the fetcher response. The fetcher function can be any asynchronous function, so you can use your favorite data-fetching library.

Features

swrv handles some of the more complex feature sets, such as:

in-flight promise de-duplication in the event that a page loads the same data in multiple components.

Deduplication

focus and page availability revalidation events for when a user switches tabs or clicks away during the browser session. This helps with an app feeling consistently up to date, or "alive", all while being customizable to what the data source requires. e.g. expensive requests might want to limit as many fetches as possible.
interval polling, to check if data has been updated, all while still serving from cache, and stops polling if user is offline or the window is not active.
prefetching, or "warming" the cache - useful for when you anticipate a user's actions like hovering over a link or preloading common page data.
custom caching strategies - by default cache is in-memory, but can be customized to use localStorage for better offline experiences. swrv manages the cache store, and provides ttl mechanisms for eviction.
pagination. here is a short demo of using pagination in swrv

For more information on swrv and it's features, check out the
Github Repository.

1. Guillermo Rauch - 2019 in Review

How to Migrate to Vue 2.6

Darren Jennings — Sat, 17 Aug 2019 17:23:48 +0000

I recently migrated our static vue app at work from 2.x -> 2.6. Here are some notes that might help you:

Update your dependencies to 2.6

yarn add vue-template-compiler@^2.6.10 vue@^2.6.10

Using Vuepress with Vue 2.6

When Vuepress and Vue are in the same package.json, there are some package version conflicts to note. If you have Vuepress ^1.0.2, you will see this kind of error:

Error:

Vue packages version mismatch:

- vue@2.6.10
- vue-server-renderer@2.5.22

To resolve this, we can use a feature of yarn.

Yarn Resolutions

Yarn comes with a feature called Yarn Resolutions. This allows you to state explicit versions inside your package.json when a package needs to resolve to a specific version.

Remove vue, vue-template-compiler, and if you happen to have them in your dependencies or devDependencies (probably unlikely), remove vue-server-renderer and @vuepress/core. Then add a resolutions field to your package.json:

"resolutions": {
  "vue": "^2.6.10",
  "vue-template-compiler": "^2.6.10",
  "vue-server-renderer": "^2.6.10",
  "@vuepress/core": "1.0.2"
},

Update Your Slot Template Syntax

While the slot syntax got much simpler, it's fully backwards compatible. This is not a necessary change, but I recommend trying it out on your components using slots.

Here is a renderless component that passes in some toggling functionality:

<!-- ❌ Old way -->
<KToggle>
  <template slot-scope="{ isToggled, toggle }">
    <KButton @click="toggle">
      {{ isToggled ? 'toggled' : 'not toggled' }}
    </KButton>
  </template>
</KToggle>

<!-- ✅ >= 2.6 -->
<KToggle v-slot="{ isToggled, toggle }">
  <KButton @click="toggle">
    {{ isToggled ? 'toggled' : 'not toggled' }}
  </KButton>
</KToggle>

Here's an example with named slots:

<!-- ❌ Old way -->
<Header>
  <template slot="title">
    <h1>User 2</h1>
  </template>
  <template slot="actions" slot-scope="{canEdit}">
    <a v-if="canEdit" href="/users/2/edit">Edit</a>
  </template>
</Header>

<!-- ✅ >= 2.6 -->
<Header>
  <template #title> <!-- or v-slot:title-->
    <h1>User 2</h1>
  </template>
  <template #actions="{canEdit}"> <!-- or v-slot:actions="{canEdit}"-->
    <a v-if="canEdit" href="/users/2/edit">Edit</a>
  </template>
</Header>

Check Components using Render Functions

Return values of slots are now always guaranteed to be a array or undefined. This bit me recently so one thing I'm doing now is testing multiple versions of Vue to catch bugs like this.

const Child = {
  render(h) {
    // in >2.6 this will always return an Array or undefined. Before, you could
    // get a single VNode or an Array of multiple VNodes and you would need to do
    // extra validations on the slots.
    return this.$scopedSlots.default({})
  }
}

There are some other changes in 2.6, but in this article I wanted to focus on what I found helpful to know, and write the article that I would have wanted to read when I was migrating to 2.6.

Links:

Evan You article on 2.6 release link
docs on slots link
gist explaining scoped slots return value

Thanks to the core team for helping me out:

sodatea for the prior art in the vue-cli repo.
Edd Yerburgh for prior art with testing multiple versions of vue.