DEV Community: Matteo Rigon

Looking at the new v-memo directive in Vue 3.2

Matteo Rigon — Thu, 25 Nov 2021 17:53:30 +0000

The release of Vue 3.2 introduced some new functionalities, mainly related to performance and optimisations. One of these features is a new directive called v-memo

What is v-memo?

v-memo, as the name suggests, is a new directive related to the memoization of parts of a template.
If you are not familiar with the term "memoization", wikipedia describes it as:

In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again

In Vue this description sounds really like what computed properties already do.
In fact v-memo can be seen as a computed property for parts of a template!

Using v-memo

v-memo accepts a single parameter, which should be an array of dependencies. The element that uses this directive and all its descendants will only be re-rendered when one of the dependencies change.
For example:

<div v-memo="[dep1, dep2]">
  ...
</div>

Note that if you don't provide dependencies , ie:v-memo="[]", you obtain the same functionality as v-once.

Examples

Since v-memo is mainly useful for performance reasons, one of the best scenarios where you'd want to use it is when rendering huge lists of items with v-for:

<div v-for="item in list" :key="item.id" v-memo="[item.id === selected]">
  <p>ID: {{ item.id }} - selected: {{ item.id === selected }}</p>
</div>

In this example we are telling v-memo to only re-render an item if it has been selected or deselected, all other items will be skipped entirely.
We don't need to include item.id in the dependency array since the sub-template of every item is already keyed, so it generates a separate sub-tree.
Another thing to keep in mind is that v-memo is only useful in a v-for if you are using some kind of interpolation. If for example you are rendering a list of components like <MyComponent v-for="item in list" :key="item.id" v-memo />, you are not going to benefit from v-memo as the diffing is made inside each component.

I've prepared an example on StackBlitz that shows visually how v-memo helps with performance in lists: https://stackblitz.com/edit/vue-v-memo

Incremental Static Regeneration on Cloudflare Workers

Matteo Rigon — Mon, 22 Nov 2021 17:08:35 +0000

I've been testing Cloudflare Workers for a bit and was immediately impressed by their performance, but one thing that really stood out for me was their extreme flexibility.
Lately, i've realised that with Workers it's really easy to achieve Incremental Static Regeneration.

What is Incremental Static Regeneration?

Incremental Static Regeneration, or ISR for short, is a technique first introduced by Vercel to improve build times for large static websites with a lot of pages.

Instead of rendering every page upfront at build time, you render pages on demand when they are requested, and then persist the response along with the rest of the site assets, effectively serving static pages after the first render.

This is a really cool feature that allows Jamstack sites to scale indefinitely.

How do we achieve ISR on Cloudflare Workers?

The real star of the show are not Workers per-se, but rather Workers KV.
Let's read their official description:

Workers KV is a global, low-latency, key-value data store. It supports exceptionally high read volumes with low-latency, making it possible to build highly dynamic APIs and websites which respond as quickly as a cached static file would.

To be honest, this description is not really helpful in describing how awesome KV is. To me, this seems just like a key-value store that applications and websites *may* need, but looks more like a niche tool.

In reality, KV is more like a distributed storage system like S3, but optimised to work at the edge.
In fact, you can store any type of data in KV, and Workers actually use KV to store and serve static assets.

After figuring out how useful KV is, an idea popped into my head: this is a great way to achieve ISR!

A Workers example with ISR

After a bit of theory, lets see some code:

export default {
    async fetch(request, environment, context) {
        const url = new URL(request.url);

        // Remove leading slashes
        const key = url.pathname.replace(/^\/+/, '');

        // Try to serve a static asset from KV
        try {
            const asset = await environment.__STATIC_CONTENT.get(key)
            if (asset) {
                return new Response(asset)
            }
        } catch (err) {
            // ignore errors and fall back to app rendering
        }

        // Fall back to app rendering
        try {
            // This part is framework-specific.
            // Your favourite framework will render the page
            // based on the request path
            const rendered = await render(request);

            if (rendered) {
                // ISR is achieved here:
                // on successful renders we store the response in KV.
                // Subsequent requests will be served from the store
                if (rendered.status >= 200 && rendered.status < 300) {
                    context.waitUntil(
                        environment.__STATIC_CONTENT.put(key, rendered.body)
                    );
                }

                return new Response(rendered.body, {
                    status: rendered.status,
                    headers: rendered.headers,
                });
            }
        } catch (e) {
            return new Response('Error rendering route: ' + (e.message || e.toString()), {
                status: 500
            });
        }

        return new Response('Not found', {
            status: 404,
        });
    }
};

Hopefully the code is self-explanatory, but let's summarize the key points:

We check if the asset is already in the KV store. If it is, we return it.
If we did not find the asset in KV, we render the page and store it.
On the next request for the same page, it will be served from KV.

As you can see, we achieved ISR with this really simple Workers code.

A few notes:

Please do not use this code for production. Serving static assets is a bit more complicated than this, as you have to carefully set response headers to obtain the best possible caching behaviour on browsers. To serve static assets properly i suggest using this library https://github.com/cloudflare/kv-asset-handler
You can pass a third argument to the KV put method to provide a TTL or expiration date to re-render static pages after a certain amount of time. I highly suggest giving your static pages a limited lifetime, otherwise if content changes you need to purge KV keys manually (either through the dashboard or via API)
__STATIC_CONTENT is a special KV namespace that is always available to all Workers and is used to store static assets served by your application. For Cloudflare Pages there is a similar namespace called ASSETS, although it is exposed with a different API and i'm still figuring out if it has a method for writing.

Beyond simple ISR

The code sample above only shows a simple version of ISR, but we can actually go further:

Selective ISR

We can store rendered pages selectively on KV, making our website fully hybrid.
Think about an e-commerce website with a blog: we can apply ISR only to the blog pages since their content never changes, and use normal SSR for product pages since their content may change frequently ( stock quantity, prices )

Stale while revalidate

If our content changes frequently, but we still want the benefit of hitting a static page, we can apply a stale while revalidate (SWR) logic: before returning a page from the store, we can re-render that page and store the new content on KV.
We still return the stale version, but the next request will find the updated version already stored.

When implementing this technique we can also use two micro-optimisations:

A TTL logic that re-renders a stale page only every X seconds, depending how often our content changes. We can use KV metadata to store when the page was rendered.
Avoid the longer response penalty of re-rendering by leveraging the waitUntil method.

Sample SWR implementation:

const SWR_TTL = 60 * 1000 // Our static pages will be re-rendered every 60 seconds

// This function renders a page and stores it to KV with additional metadata
const renderAndStorePage = async (request, environment, context, key) => {
    try {
        // This part is framework-specific.
        // Your favourite framework will render the page
        // based on the request path
        const rendered = await render(request);
        if (rendered) {
            if (rendered.status >= 200 && rendered.status < 300) {
                context.waitUntil(
                    environment.__STATIC_CONTENT.put(key, rendered.body, {
                        metadata: {
                            createdAt: Date.now()
                        }
                    })
                );
            }

            return new Response(rendered.body, {
                status: rendered.status,
                headers: rendered.headers,
            });
        }
    } catch (e) {
        return new Response('Error rendering route: ' + (e.message || e.toString()), {
            status: 500
        });
    }

    return null
}

export default {
    async fetch(request, environment, context) {
        const url = new URL(request.url);

        // Remove leading slashes
        const key = url.pathname.replace(/^\/+/, '');

        // Try to serve a static asset from KV
        try {
            const result = await environment.__STATIC_CONTENT.getWithMetadata(key)
            if (result && result.value) {
                if (
                    // TODO: Determine if request is for a page
                    (!result.metadata || Date.now() - result.metadata.createdAt >= SWR_TTL)
                ) {
                    context.waitUntil(
                        renderAndStorePage(request, environment, context, key)
                    )
                }
                return new Response(result.value)
            }
        } catch (err) {
            // ignore errors and fall back to app rendering
        }

        // Fall back to app rendering
        const response = await renderAndStorePage(request, environment, context, key)
        return response || new Response('Not found', { status: 404 })
    }
}

Demo

I've created a small example application that uses ISR on Cloudflare Workers.

https://sveltekit-isr.reego.workers.dev

It is made with Svelte Kit, you can find the source code here.
Every page has a top red bar ( or bottom if you are reading from a smartphone) that shows when the page was rendered and for how long it is stored.

References & links

Using Github discussions as your blog engine

Matteo Rigon — Sat, 06 Nov 2021 14:59:21 +0000

When i first thought about having a personal blog, i started wondering how i wanted my authoring experience to be like, and although there are plenty of great tools, i still wanted to find something smart and creative.

I found out that GitHub discussions are really powerful and their API gives us (almost) all the right tools to create a complete blog engine.
In fact my own blog https://reego.dev/ is completely powered by GitHub discussions!

🔍 Initial research

After evaluating a few blog solutions, i thought: "I'll just use GitHub and version my posts as Markdown files".

The authoring experience is pretty straightforward: create a Markdown file in your repository and push it. You can even create files directly from the GitHub UI, and you also get a nice Markdown preview.

Although this method works, i still wanted something better.

Versioning Markdown files on a repository didn't feel cool to me, but GitHub still has a few alternatives that kept me interested.

At first, i thought about using issues as blog posts: they have a title, a Markdown editor, labels (which are tags in every aspect ), comments, reactions, and a good search API.

Unfortunately, issues miss something critical for a blog engine: everyone can create an issue on a public repo. 😱

After some research, i wasn't able to find a way around this problem without involving complex actions and hooks, so i looked at a similar alternative: discussions.

✅ The right tool for the wrong job

GitHub discussions share all the cool things that issues bring, plus a few more. Lets do a quick recap:

A title
a Markdown editor with preview
labels (tags)
comments
reactions
powerful search
writing permissions
categories
upvotes
pinning
subscribe for updates
decent mobile authoring experience with the GitHub mobile app
infinite integrations through actions

After a bit of tinkering i was able to create a simple blog engine by following these simple steps:

1️⃣ Edit discussion categories

Discussion categories are important for our goal:

They are mandatory, so you need at least one, even if you don't plan on using categories in your blog;
You need to edit for each category their "Discussion format" and select "Announcement".

When setting a category as announcement, only maintainers of the repository can create discussions in that category, and if all your categories are set as announcement, the "New discussion" button will disappear for everyone besides maintainers.

2️⃣ Create our first post

To query our post we have to use its internal id, which is not visible through the default GitHub UI, and would also give us a non-pleasant URL format, ie: /blog/D_kwDOGN2Rdc4AN6ar.

To use pretty URLs we have to be a bit creative: the method i chose is to add a frontmatter section in the body of my posts. GitHub Markdown preview does not complain about it, so it's an effective way to allow us to add metadata to our posts.

Using the frontmatter section, we can add a slug property that will serve as the search term to fetch our post. (I've also added another frontmatter property that serves as a short description of the post)

Note that the uniqueness of the slug is entirely up to us. As long as our blog does not have hundreds of posts it won't be a problem.

This is what our first post looks like in Markdown:

---
slug: our-first-blog-post
description: "Writing our first blog post as a GitHub discussion"
---

## This is a post
How cool is that?

3️⃣ Query our post using the GitHub API

We can query our post with a simple Graphql query (REST API is not available for new GitHub features like discussions):

query ($query: String!) {
    search(query: $query, type: DISCUSSION, first: 1) {
      edges {
        node {
          ... on Discussion {
            title
            body
            createdAt
            updatedAt

            category {
              id
              name
            }

            labels(first: 10) {
              edges {
                node {
                  id
                  name
                  color
                }
              }
            }
          }
        }
      }
    }
 }

Our query variable will contain the following string:

const repo = 'reegodev/reego.dev'
const slug = 'our-first-blog-post'
const variables = {
  query: `"slug: ${slug}" in:body repo:${repo}`
}

This query basically searches the first discussion that contains the slug of our post in the body and is included in a specific repo.
After running this query, we should be able to retrieve our post and render it using our favorite Markdown parser.

Don't forget to create a personal access token with all the "repo" permissions to send along as a bearer token

4️⃣ Embed discussion comments ( optional )

To embed discussion comments directly into our articles i've found an amazing project: Giscus.
It fetches comments using the GitHub API, and lets your visitors post directly from your website with their GitHub account.
Their website allows you to create the Giscus configuration by answering a few questions, mine ended up being this:

<script src="https://giscus.app/client.js"
      data-repo="reegodev/reego.dev"
      data-repo-id="R_kgDOGTk7pw"
      data-mapping="number"
      data-term="{ post.number }"
      data-reactions-enabled="1"
      data-emit-metadata="0"
      data-theme="dark_dimmed"
      data-lang="en"
      crossorigin="anonymous"
      async>
</script>

After embedding this little snippet, comments will just show up, it's that easy!

🚀 A great potential?

Fetching a single post only scratches the surface of what we can achieve using discussions as our blog engine.
There are many things that we can do with the GitHub API which i have not covered in this post:

Fetching the list of posts ordered by creation date to populate our blog index
Fetching pinned posts to show at the top of our blog index or homepage
Fetching posts by tag to provide tag archives

If you are interested in digging deeper into other functionalities you can browse the source code of my blog here

I hope this post was an interesting read!
Cheers!