DEV Community: Jérôme Pott

Weekend Hack: Patreon Pledges Calculator

Jérôme Pott — Thu, 26 Aug 2021 18:28:10 +0000

Last weekend I coded a simple web app. It lets users visualize how much money they've pledged to each creator they've supported on Patreon.com

link: https://patreon-pledges-calculator.netlify.app
repo: https://github.com/mornir/patreon-pledges-calculator

Surprisingly, it is not possible to get that information from the official website. One can only view its billing history. However, from that history data, it's possible to calculate the total amounts of pledges per Patreon creator.

The data is delivered through a /bills endpoint in the JSON format. My first thought was to the Patreon API and have the users authenticate with their Patreon account. For that I needed create a Creator account, which I did. But then I realized that I could only get access to bills/payments made to my account.

This actually makes sense: billing data are private and sensitive and shouldn't be exposed to all Patreon creators. My guess is that the main purpose of the Patreon API is to let creators manage their supporters (for example for gated content).

So I decided to just let users dump their JSON payload in a textarea 😆
It does the job and users don't need to worry about privacy (btw I should probably mention on the web page that all data are processed by the browser).

Tech Stack

I used Vue 3 with Vite. I kept to the good ol' Options API, as I'm not a fan of the new Composition API. Anyway, in the Vue 3 docs, the Options is still taught first and the Composition is said to be reserved to big and complex application 🤷‍♂️

Since it's just a one page website, I thought that this time I could just go with Vanilla CSS, but it seems that I've already developed a severe addiction to tailwindcss to the point that I use it anywhere and anytime. 🍹
I especially love how easy it was to create a nice list animation using Vue List Move Transitions and Tailwind utilities classes while still caring about the user's motion settings (prefers-reduced-motion).

<transition-group
  move-class="motion-safe:duration-1000 motion-safe:ease-in-out">
</transition-group>

What else? Well I just love playing with Cypress. Seeing those tests passing just feels me with joy. So I added a few test cases for good measure. 🧪

And that's it! Try it out here if you have a Patreon account: https://patreon-pledges-calculator.netlify.app/

Weekend project: creating a media viewer

Jérôme Pott — Tue, 10 Aug 2021 15:41:33 +0000

Try it out: https://media-viewer.netlify.app/
Source code: https://github.com/mornir/media-viewer-ts

Introduction

I was unhappy with the media viewer applications available on Windows. After searching for a few hours, I couldn't find any program that fulfilled my short list of requirements:

Reads both images and videos
Navigates between media with keyboard or mouse wheel
Autoplays video, preferably in a loop
Works locally (direct read from the disk, no upload to server)

So I thought I could just code my own application.

Electron or not?

I'm a front-end developer, which limits my possibilities. Since I needed read access to the disk, my first thought was to use Electron. I've never worked with Electron before and actually I've been avoiding it so far. My guess is that PWA or another tech is going to replace it in the short to medium term. So I was not too eager to learn how to build apps with Electron in 2021.
While doing some research about Electron, I came across this Electron application. It was exactly what I needed, except that it couldn't read videos.😫

However, the same author also published a great npm package which had more capabilities, among other reading video files.🥳

Remembering hearing about the new File Access API, I told myself why not just build a website?

webkitdirectory vs File Access API

At first I thought that using the File Access API was the only way to read the content of a folder. But actually the webkitdirectory attribute on the <input type="file"> element allows just that! So a basic input tag with the webkitdirectory attribute is exactly what I needed.

I think that the File Access API is more for advanced usages, like letting users save changes directly back to the disk (see for example this text editor demo)

createObjectURL

Media files are to be read locally, directly from the disk. But I still needed some sort of URL for the src attributes of img and video tags. First I thought about converting images to base64, but this is a expensive process and it doesn't work for videos. Like stated in this post, the right way is with URL.createObjectURL. This method creates a temporary local URL that can be used by the src attribute.

The lifespan of the URL is bound to the HTML document. When the tab is closed, the URL is removed from memory. However it's best practice to free up memory as soon as the URL is no longer needed, using the URL.revokeObjectURL method and passing it the blob URL. In my case, I call it once images and videos have loaded or when the gallery is closed.

Vite & Typescript

I've always used Vite exclusively for Vue 3 projects, and I was pleasantly surprised to see that it works also great for "pure" TypeScript (vanilla-ts Vite template). From now on, I will use Vite for all my front-end projects, even when I'm not using Vue.

Try it out: https://media-viewer.netlify.app/
Source code: https://github.com/mornir/media-viewer-ts

Sanity Backup Function with GitHub Actions and Artifacts

Jérôme Pott — Fri, 02 Apr 2021 16:18:21 +0000

Warning: In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.

TL;DR

https://github.com/sanity-io/github-action-sanity#backup-routine

Introduction

Sanity is a hosted content platform that offers many features going beyond what we expect from a traditional CMS. One of their core focus is the developer experience. Thanks the Sanity CLI, it takes only two commands to bootstrap a project and deploy it to a free subdomain. Data are stored safely and in multiple copies on Google Cloud servers. Thanks to the document history, we can restore our documents to a previous state. However, deleted documents and datasets cannot be recovered.

Even if those scenarios are unlikely to happen, it is worth creating a simple backup routine, just in case. And the method I'm going to show you here is easy to set up, won't cost you any money, and doesn't require you to register with a 3rd party service (I assume that all my readers have a GitHub account🙃).

Ways to backup Sanity datasets

There are three ways to backup datasets:

cURL request to an export URL endpoint
Using the Sanity CLI
Using the @sanity/export npm package

In an another blog post, I explained how to use the @sanity/export npm package inside a serverless function to back up content to Google Drive or Dropbox:

Use Netlify cloud function to back up data to Google Drive

Jérôme Pott ・ Sep 13 '19

#webdev #javascript #tutorial #serverless

There's however an easier way: GitHub Actions (GA). Here are their advantages:

Backup files are stored alongside your studio code.
They only require a few lines of YAML config.
They support CRON jobs.
They are cheap (execution time + storage).
We can make use of the GitHub ecosystem (notifications for failed workflows, access management, etc.)

Going full onboard with GitHub Actions

There is a GitHub Action that wraps the Sanity CLI. Basically, it means that we can run sanity dataset export inside our GA workflow.
Before we can export the dataset, we need to generate a read token from the Sanity project dashboard and store it as a secret in the GitHub repository.

This is how the first workflow step looks like:

       - name: Export dataset
        uses: sanity-io/github-action-sanity@v0.2-alpha
        env:
          SANITY_AUTH_TOKEN: ${{ secrets.SANITY_AUTH_TOKEN }}
        with:
          args: dataset export production backups/backup.tar.gz

Then we need to upload the generated backup file so that it will be available for download as a workflow artifact. For this, we use the upload-artifact action and we specify the same path as above: backups/backup.tar.gz.

By default, this step passes even if GitHub cannot find our generated backup file. That is why I recommend setting the if-no-files-found option to error.

And here's the details of the step:

- name: Upload backup.tar.gz
uses: actions/upload-artifact@v2
with:
  name: backup-tarball
  path: backups/backup.tar.gz
  # Fails the workflow if no files are found; defaults to 'warn'
  if-no-files-found: error

In addition to running the backup routine on a schedule, you also add an option to trigger the backup process manually from the GA dashboard. This can be useful in various situations, e.g. right after content editors added a large amount of data, or right before manipulating datasets.

Here's an example of a workflow triggered manually or by a CRON job:

on:
  schedule:
    # Runs at 04:00 UTC on the 1st and 17th of every month
    - cron: '0 4 */16 * *'
  workflow_dispatch:

Conclusion

We now have set a solid backup routine in place. You can of course tune the frequency of the backups to your needs. Make sure to also read the latest information about pricing, size limits and file retention from GitHub. For example, as of writing this, backup files are automatically deleted after 90 days on public repo. I personally think that 90 days is long enough, even too long maybe. If you want to keep backups files for a shorter time, you can do so in the repository settings under Actions.

Finally, if you would like to see the workflow described in this post along with the generated artifacts, you can visit this page: https://github.com/mornir/movies-studio/actions/workflows/main.yml

Sanity.io: Get the most out of your content

Sanity.io is a platform to build websites and applications. It comes with great APIs that let you treat content like data. Give your team exactly what they need to edit and publish their content with the customizable Sanity Studio. Get real-time collaboration out of the box. Sanity.io comes with a hosted datastore for JSON documents, query languages like GROQ and GraphQL, CDNs, on-demand asset transformations, presentation agnostic rich text, plugins, and much more.

Don't compromise on developer experience. Join thousands of developers and trusted companies and power your content with Sanity.io. Free to get started, pay-as-you-go on all plans.

?? noopener, noreferrer, nofollow ¿¿

Jérôme Pott — Sun, 21 Mar 2021 07:59:32 +0000

TL;DR

noopener
It's no longer necessary to write rel="noopener" because noopener is now the default behavior in all modern browsers.

noreferrer
I couldn't find any example where I would want to use this keyword. If you know about one, please share it below.

nofollow
Great for user generated content, combined with the new ugc keyword: rel="nofollow ugc"

Introduction

I've never been 100% clear about the difference between the values of the rel attribute on <a> tags. I decided to do some research and take some notes. Here is a summary for myself and anybody interested. Please do post a comment below if I'm wrong about anything and I'll update the post accordingly.

noopener

External links with target=blank open in a new tab. By default, that new tab has access to window.opener, which points to the origin page. The newly opened website has access to that object and can even change the value of window.opener.location. Yes, it can force the origin page to navigate to a new URL. The worst part is that the user may not even notice the programmatic navigation because the new tab is focused by default.

Imagine a user scrolling through his Facebook thread. He sees an interesting article teaser and clicks the external link that opens in a new tab. Once he's done reading the article, he goes back to the Facebook tab. Strangely, Facebook is asking for his credentials again. He naively enters them again and falls into the trap: when he opened the article, his Facebook page was programmatically navigated to another website that pretends to be Facebook. This method of deceiving users and stealing their information is called tabnagging.

Adding the keyword noopener prevents the opened external tab from accessing window.opener.
Why is this noopener not the default behavior you may ask? Well, it is now in all in all modern browsers. You can test it yourself with this web experiment. However, since the change is very recent, it doesn't hurt to keep it around a little longer, especially since most of the time it is outputted by default by tools like CMS or components libraries.

But this update to browsers is good news for new web developers who will never have to worry about this security vulnerability.

noreferrer

The noferrer keyword prevents access to window.opener (exactly like noopener), but also prevents the HTTP Referer header from being sent to the linked website.

While it has no impact on SEO, it affects the web analytics of the linked website. Visits from your website to the linked website will be counted as direct traffic in referral traffic (instead of showing your website as the source). As a webmaster, I want to appear in the analytics of the websites I link to. When they see traffic from my website, they will most probably check it out and maybe share the page on social media, follow me or even decide to return the favor by linking back to my website.

So write rel="noreferrer" for outgoing links when you don’t want other sites to know that you are linking to them. However I cannot think of any concrete example.

Finally, you obviously shouldn't use the noreferrer keyword on internal links as it will mess up your analytics reports.

The reason you may find this keyword recommended in best practices is because noopener is not supported by Internet Explorer, thus noreferrer is used on external links to prevent tabnagging.

What about user privacy?
Sharing full URL paths with external websites is not good for user privacy and it's not useful for analytics.
Here, you should turn to the referrer policy, by setting it to strict-origin-when-cross-origin. In some web browsers (e.g. Firefox v87), strict-origin-when-cross-origin is already the default value.
This topic is however out of the scope of this blog post and I strongly encourage you to read this excellent article:
https://web.dev/referrer-best-practices/

nofollow

Spiderbots crawl websites, collect and follow all links they encounter. If you don't want crawlers to follow certain links, you can add nofollow. Keep in mind that it's only a hint: the spiderbots may choose to ignore the directive and use nofollow links for rankings

When dealing with user-generated content, it's complicated to check all the external links that are posted. Some links may lead to websites with a bad reputation and this will hurt your SEO ranking. This is where the nofollow keyword comes in handy. You can also use the new ugc keyword, but not all spiderbots understand it, so keep both keywords: rel="nofollow ugc". You can see an example of it on any links posted in the comment sections of css-tricks.com.

You can also use nofollow for pages on your website that you don't want to be indexed, but I think it's better to use the robots.txt file rather than to add nofollow on links that point to those pages.

Sources

What rel="noreferrer noopener" Mean and How it Affects SEO

The State of Nofollow, UGC, & Sponsored Link Attributes in 2020

How Google's Nofollow, Sponsored, & UGC Links Impact SEO

Links to cross-origin destinations are unsafe

What rel="noreferrer" Does and How to Remove It

The Difference Between Nofollow and Noreferrer, and Why it Matters

Webhooks with Serverless Function

Jérôme Pott — Sat, 13 Mar 2021 12:23:40 +0000

In this blog post, I'm going to show you how I set up a serverless function on Cloudflare Workers that reposts messages originally published on Habitica's chat to a Discord channel

Introduction

Habitica is a great platform for building good habits and boosting productivity. Its social aspect is also one of its key features. Users can form parties in order to hold each other accountable. Every party has its own simple chat page where users can discuss and where system messages are posted (skills used, damages dealt, quests started, etc.). But when it comes to creating a social space for chatting and talking, Discord is currently the best free solution out there. So my party and I moved to a Discord server. The problem is that system messages are still posted on Habitica.

That is why I looked into a way to automatically repost those messages to a dedicated Discord channel. And it turned out that it is quite easy to set up thanks to the flexible webhooks provided by both Discord and Habitica.

Step 1: Create a Discord Bot

From Discord's official instructions:

Open your Server Settings and head into the Integrations tab:
Click the "Create Webhook" button to create a new webhook!
You can edit the avatar and the name of the webhook
Choose what channel the Webhook posts to.
You can copy the Webhook URL

Step 2: Create a Serverless Function

Habitica cannot post directly to Discord. We need an intermediate. No-code solutions like Zapier are neat, but here we need more fine-grained control over the request in order to format the messages in the way we like and serverless functions are ideals for this use case.

There are many different cloud function providers out there, but for this project, I wanted to try out Cloudflare Workers. Cloudflare Workers have two serious advantages over other providers: they are incredibly cheap and their start-up time (cold start) is near-instant, not that we need those features for the current project.

Cloudflare also provides a simple yet convenient online code editor to code the serverless function. Since our code won't be complex, we'll write our function directly inside the online editor. Here's the complete code:

async function handleRequest(request) {
  try {
    // See below the structure of the data object
    const data = await request.json()

    // Only repost system messages
    if(data.chat.uuid === "system") {

      // Discord expects a JSON payload that looks like this { content: 'hello world'}
      const content = { "content": data.chat.text }
      await fetch(DISCORD_WEBHOOK_URL, {
        body: JSON.stringify(content),
        method: "POST",
        headers: { "Content-Type": "application/json" },
      })
    }
    return new Response('OK')
  } catch(error) {
    console.error(error)

        // Habitica always expects a 200 response, otherwise it will disable the webhook
    return new Response('OK')
  }
}

The body of the post request coming from the Habitica webhook will look like this:

{
  "group": {
    "id": "XXXXX-c888-4dbf-aa0e-fc317c9c8f8c",
    "name": "super_squad "
  },
  "chat": {
    "flagCount": 0,
    "flags": {},
    "_id": "03e9b0d6-XXX-442a-9659-fde24aec2842",
    "id": "03e4b0d6-XXX-442a-9659-fde24aec2841",
    "text": "mornir casts Earthquake for the party.",
    "unformattedText": "mornir casts Earthquake for the party.",
    "info": {
      "type": "spell_cast_party",
      "user": "mornir",
      "class": "wizard",
      "spell": "earth"
    },
    "timestamp": "2021-03-10T17:00:40.141Z",
    "likes": {},
    "uuid": "system",
    "groupId": "5f38dbe06649-555-aa0e-fc317c9cbf8c"
  },
  "webhookType": "groupChatReceived",
  "user": { "_id": "5454544ea-134d-4e37-XXX-310351b35729" }
}

DISCORD_WEBHOOK_URL is the Webhook URL we got in step 1, stored here as an environment variable:

Step 3: Create a Habitica Webhook

The official UI for creating webhooks, found on the settings page, is a bit lacking compared to what is available on the Habitica API. We can only add and delete URLs, but in our case, we want to listen to a specific event occurring in a specific chat room. That is why I used an alternative editor for Habitica webhooks, which includes all of the webhook options that are missing from the main site.
Website: https://robwhitaker.com/habitica-webhook-editor/
Documentation: https://habitica.fandom.com/wiki/Habitica_Webhook_Editor

The newly created hook will then appear on our Habitica account settings page:

The result

Voilà! We now have a working Habitica bot that reposts system messages!

Of course, there are much more things we can do! Here are some ideas:

Link abilities and bosses to their corresponding wiki page or bosses
Send warning if member deal too much damage to its party

Cloudflare Workers let us also store data inside a database. Having information that persists between function invocations opens new exciting possibilities!

My personal experience with XState

Jérôme Pott — Fri, 01 Jan 2021 12:17:31 +0000

Dan Abramov

@dan_abramov

State machines are great, so why aren’t we rewriting all of our async/await code to them?

04:37 AM - 31 Dec 2020

Over the Christmas holiday, I dove into finite state machines because I was intrigued by its popularity. I built a couple of small apps using XState with React hooks, Vue 2 and Vue 3 (composition API), using TypeScript for every project.

I was seduced by the concept of finite state machines. For example, in my project with Vue 2 I was dealing with multiple intricate states, and I was eager to clear things out thanks to XState. It took me a while to get a grasp on how to use that library, which has a large surface area and is not easy to get started with. I took a course on Udemy, which provided me with a solid foundation.

However, I quickly found out that XState doesn't play well with Vue 2 and that I would need to use Vuex anyway. . My original thought was to replace Vuex with XState and I don't see the point of having to state management solutions.

Then I built a second, smaller project with Vue 3 and its composition API. This time, the integration of XState was smooth and I was able to manage my data globally thanks to XState context. Since the project was quite small, I can't really tell if this approach would scale well in a larger codebase.

The experience with React Hooks was very similar to Vue 3 Composition API. I also would like to say that XState integrates very well with TypeScript.

In conclusion, I think that XState is not a good fit for the websites I usually build for clients, which are JAMstack websites with simple state logic. But it's true that XState forces developers to think of all the possible outcomes and a seemingly simple state logic can actually hide complex workflows and possible paths. However, covering all those paths takes time, and time is money for the client. It's sad, but it's not rare that I have to build forms where in case of an error I just log it to the console.

However, if I had more time, I wouldn't implement XState, but rather add a bug tracking solution (LogRocket, Sentry, Bugsnap, etc.) or write E2E tests.

I'm persuaded that XState is the perfect tool for specific applications, but it definitely doesn't make sense to use it every time. For example, I find the TodoMVC example on the XState website to be incredibly complex and convoluted.

More opinions on XState on Reddit

Change the favicon color in dark mode! 🤯

Jérôme Pott — Mon, 09 Nov 2020 13:44:24 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1321083538494676994-642'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1321083538494676994&theme=dark" }

Favicon using a light theme

Favicon using a dark theme

Building my first web extension

Jérôme Pott — Sun, 25 Oct 2020 09:30:38 +0000

Since I've learned that web extensions speak the same languages as websites (HTML, CSS and JavaScript), I've always wanted to give it a try. This post is less a tutorial and more a summary of my experience.

Getting started

Getting started is indeed very easy:
https://css-tricks.com/how-to-build-a-chrome-extension/

I was able to quickly get something working, however, I also quickly faced some limitations that required me to set up a build pipeline in order to:

use npm modules
work with promises (browser APIs use callbacks)
have my extension automatically work both in Chrome and Firefox
have hot module replacement (HMR)
use Vue components and TailwindCSS
in short: have my dev environment as close a possible to my usual environment.

Fortunately, I found this awesome plugin that takes care of all the above-mentioned points.
This plugin scaffolds a web extension project structure and includes the essential webextension-polyfill.
All I had left to do with to set up TailwindCSS and I was ready to code.

Debugging web extensions

I didn't find how to use the Vue devtools extension for debugging, but in my case, logging to the console was sufficient.

To see the console logs when debugging the popup:

Chrome: Open dev tools, right-click inside the popup and select "inspect"
Firefox: Click the inspect button on the screen where you added your extension as a temporary extensions [image]

For the settings page, you can set options_page directly to options.html, which will open it as a full page.

You can also open the popup as a normal web page by typing its URL: chrome-extension://your_extension_id/popup.html

What about testing?

Thanks to the simplicity of Cypress, I've started to add tests to my projects. However, Cypress currently cannot visit web extension.

Then I found a great blog post about testing web extensions with Jest and Puppeteer. The showcased extension is even built with Vue.

Thanks to that post, I was able to quickly set up Jest. However, I quickly realized that the History API I was using was not mocked by the jest-webextension-mock library🙄

What I ended up doing is to only unit test the main functions with Jest. As fixtures for the tests, I exported a sample browsing history as JSON.

The post later mentioned E2E testing with Puppeteer. I tried to set it up but ran into errors from the Jest integration. At that point, I told myself that I shouldn't spend more time on that topic and move on to finally publishing my extension.

Publishing my extension

Chrome Web Store

The developer dashboard seemed to have recently been redesign. I found it very easy to navigate. There are many contextual info-bubbles that provide useful information. The whole process was very straightforward. I just had to fill out all the required information and pay the entrance fee of $5 to submit my extension for review. Two days later, it was published.

Link to Chrome store page: https://chrome.google.com/webstore/detail/track-it/kjdclicjmhibgokfflkhfccdillnkfbk

Add-ons for Firefox

At Firefox, the submission process was also easy and the review also only took two days. Unlike Chrome, I had to upload the source code. I am actually surprised that Chrome didn't ask for it. Maybe paying the fee with a credit card number provided enough insurance.

Link to Firefox store page: https://addons.mozilla.org/en-US/firefox/addon/track-it/

Now go build your own extension!

Don't fret too much about the fact that there are probably extensions that will be similar/better than yours. With that kind of thinking, you'll never get started. If this doesn't help, take it as a learning exercise.

See my extension: it tracks the time since the last visit to websites... There are plenty of apps that do a similar job and boast more features. But it solved a specific need I had and I use it daily.

You check its source code here:
https://github.com/mornir/track-it

Cover photo by Aron Visuals

How to handle content previews from Sanity in Nuxt

Jérôme Pott — Sun, 16 Aug 2020 10:28:49 +0000

Introduction

In the Jamstack, pages are generated at build time. The static assets can then be deployed to a CDN network and served quickly to the visitors. However, this approach means that the pages cannot be built by the server on the fly, for example when content editors want to preview their content before publishing it.

So how can we solve that problem? Well, this is still a domain where innovation is currently happening, but a few solutions already exist. The easiest solution is to simply generate a preview deploy, so basically rebuild the whole website on a test URL. This approach is only viable if rebuild time is very short. Incremental builds would be the solution here, but we're not there yet.

Another approach is to take advantage of the fact that our statically generated Nuxt website hydrates into a full-blown single page application. We can then use JavaScript on the client side to dynamically fetch the content from the CMS. Thankfully, Nuxt > v2.13 makes our lives easy with its new and shiny preview mode. ✨

Enabling preview mode in Nuxt (> v2.13)

Create a plugin named preview.client.js with the following content:

// plugins/preview.client.js
export default function ({ query, enablePreview }) {
  if (query.preview) {
    enablePreview()
  }
}

Yes! That's it! Now if the URL contains the query param ?preview=true, the enablePreview method will be invoked. Nuxt will then "discard" the data coming from the server and calls nuxtServerInit, asyncData and fetch on the client side.
To test the preview mode locally, you need to run nuxt generate and then nuxt start. You can now see in the network tab that Nuxt makes calls to the API when the preview query parameter is set.

Previewing brand new pages

By brand new pages, I mean pages that have never been deployed. We don't want Nuxt to show the 404 page to the content editor when he/she wants to preview a brand new page.

There's a SPA fallback that we can activate by setting generate.fallback to true in nuxt.config.js. Now Nuxt won't default to a 404 and will try to render the page by making an API call to the CMS.

But we still want to show the 404 page when normal users of the website visit such pages. The validate hook was designed for this situation.
What I usually do is store all slugs in Vuex (via the nuxtServerInit action) and check against the store in the validate hook if the page exists. However, don't forget to provide a "escape hatch" for the preview mode:

validate({ params, store, query }) {
    // If FALSE redirect to 404 page
    return (
      query.preview === 'true' || store.state.moviesSlugs.includes(params.slug)
    )
  }

Generating the target URL in the CMS

In Sanity, content editors can open in a new tab the target URL of the page they want to preview or they can display it inside an iframe directly in the Studio.

Opening the preview in a new tab

Follow these instructions and add the content below to the file you created.

export default function resolveProductionUrl(document) {
  // Only show the preview option for documents for which a preview makes sense.
  if (document._type === "movie") {
    return `https://nuxt-sanity-movies.netlify.app/${document.slug.current}/?preview=true`
  }
  return undefined
}

Showing the preview inside an iFrame

Create a JS file with the following content and add it as a new part in sanity.json, in the same fashion you did above.

import React from "react"
import S from "@sanity/desk-tool/structure-builder"

const url = "https://nuxt-sanity-movies.netlify.app/"

const WebPreview = ({ document }) => {
  const { displayed } = document
  const targetURL = url + displayed.slug.current + `/?preview=true`

  return (
    <iframe
      src={targetURL}
      frameBorder={0}
      width="100%"
      height="100%"
    />
  )
}

export const getDefaultDocumentNode = ({ schemaType }) => {
  // Conditionally return a different configuration based on the schema type
  if (schemaType === "movie") {
    return S.document().views([
      S.view.form(),
      S.view.component(WebPreview).title("Web Preview"),
    ])
  }
}

export default S.defaults()

WebPreview is a React component (Sanity is a React SPA), but otherwise the code is just JavaScript and should be easy to follow for Vue developers. You can always refer to Sanity's extensive documentation.

Handling draft preview

You will notice that drafts are not fetched. The reason is that draft documents don't appear on the API to unauthenticated users. In order to preview drafts, the easiest way is to use auth cookie. When content editors log into the CMS, an auth cookie is automatically set by Sanity in their browser. If the Sanity client was initialized with withCredentials set to true, the cookie will be passed along with each request. And don't forget to allow credentials for your API point in the Sanity Dashboard.

const client = sanity({
  projectId: 'xxxxxxx',
  dataset: 'production',
  useCdn: false,
  withCredentials: true, // Add this line
})

The problem now is that both versions will be returned: the published document and the draft. So if there's a draft, we'll get an array with two objects and using the default alphanumeric ordering, we don't know which version comes first. That is why we need to filter the result by _updateDate in our Nuxt page to be sure to get the draft first.

// _slug.vue
  const movie = await $sanity.fetch(
        "*[_type == 'movie' && slug.current == $slug] | order(_updatedAt desc)[0]",
        {
          slug: params.slug,
        }
      )

Be careful with content validation when previewing drafts

Validation rules set in the Sanity Studio do not affect drafts. So make sure that empty required fields don't break the front end preview. The easy way guard against this is to add some v-if directives where code might break.

One important information that we should check for beforehand is the slug field. If this field isn't set, we should show no preview options.

Disable the Open preview option in the document context menu:

if (!document.slug?.current) {
   return undefined
}

For the iframe, the best way is to simply show a custom HTML page:

if (!document.slug?.current) {
    return <h1>Please set a slug to see a preview</h1>
}

Already done!

What I like the most about this whole approach is that we only had to make a few edits to our pages or Vue components. The need to add a filter to get the draft first is a but unfortunate, but I couldn't find a better way.
Another interesting detail I noticed is that once the enabePreview method has been called, the Nuxt app stays in preview mode after navigating to different pages. So a content editor can preview his blog post and then navigate to the blog listing page to see how his post teaser looks like.

Going the extra mile 🏃

Preview banner with $nuxt.refresh

In our current implementation, content editors need to reload the page (= reinitialize the whole Nuxt app) when they want to refresh the preview.
When the preview is opened in a new tab, this is not an issue, but when it's opened inside the iframe in the Sanity Studio, we don't want content editors to reload the whole CMS or have to close and reopen the iframe (and thus losing their scroll position on the page).

In Nuxt v2.9.0, a nifty feature was quietly added and was only properly documented later: the $nuxt.refresh context helper. Basically, it allows us to call asyncData (and fetch) on the client side, without doing a full reload.

This gave me the idea of showing a banner when the preview mode is activated. That banner contains a button which invokes $nuxt.refresh. Content editors can click that button to refresh the preview.

Here's a GitHub repo with an example about how to implement such a banner. I had to wrap the banner inside client-only tags because otherwise there would be a mismatch between the client and the server node tree and the hydration would break.

Another built-in property that is useful for our banner component is $nuxt.isPreview, which returns true if we're in preview mode. It means that we can easily show our banner conditionally in this way:

<PreviewBanner v-if="$nuxt.isPreview" />

Real-time preview (the holy grail?)

In Sanity, every edit is saved in real-time and the Sanity client even comes with a listen method to react to content changes. You can set up the listener in the mounted hook of the page to be previewed.

  mounted() {
    if (this.$route.query.preview)
      this.$sanity
        .listen('*[_type == "movie" && slug.current == $slug][0]', {
          slug: this.$route.params.slug,
        })
        .subscribe((update) => {
      this.movie = update.result
        })
  }

However, this method doesn't retrieve the references of the fetched document. If your document has no references, the Sanity listener is perfect. Otherwise one possible solution would be to call $nuxt.refresh in the subscribe callback:

.subscribe((update) => {
    this.$nuxt.refresh()
 })

But I would advise against that, for four reasons:

Do content editors really need a real-time preview? As a web developer, I'm excited about the real-time preview, but I personally doubt that it's very useful in practice.
It could get expensive (financially and computationally). While the Sanity listen method uses WebSockets, our implementation with $nuxt.refresh will fire additional HTTP requests at every keystroke in the Studio.
In my implementation, the content shown in the front end was always on step/update behind. (This can probably be fixed.)
I prefer using the lightweight PicoSanity client, which doesn't support the listen method.

Glad to hear your feedback on this

What are your thoughts about the preview banner? Are you already using the new Nuxt preview mode? How do usually handle previews from Sanity in your Nuxt apps? What do you think of a real-time preview for content editing? I personally have never used Sanity as a content editor, so it's hard for me to judge.
Share your opinion and experience in the comment section below!

All the code snippets are taken from the following repositories. The Studio uses the sci-fi movies test dataset offered by the Sanity CLI when initializing a new project.

mornir / movies-web

🍿 Simple Nuxt (full static) + Sanity with preview mode

mornir / movies-studio

🎬 A Sanity Studio initialized with the sci-fi movies dataset

How to add Mapbox to your Nuxt static site

Jérôme Pott — Thu, 11 Jun 2020 16:45:17 +0000

In this blog post, I'm going to show how to display a Mapbox map in a Nuxt static app using the official Mapbox GL JS library.

In my experience I wouldn't reach for a Vue plugin. Such plugins often end up introducing an additional layer of complexity. When something doesn't work, you don't know if it's because you used incorrectly the plugin or the underlying Mapbox library and you need to check two documentation.

As for the plugin docs, they are usually either lacking or redirecting to the official Mapbox docs. Plus those plugins tend to be abandoned after awhile.

Finally, as you will see, it's not complicated to work with the Mapbox GL JS library. It's just JavaScript™

Installing and initializing

1。Install the npm package: npm install mapbox-gl
2。Link to the CSS stylesheet in the the head of the page where the map will be used (no need to load the Mapbox CSS globally if it is only used on one page).

head: {
      link: [
        {
          rel: 'stylesheet',
          href: 'https://api.mapbox.com/mapbox-gl-js/v1.10.0/mapbox-gl.css',
        },
      ],
  },

3。Import the module in the mounted hook of your page or component.

mounted() {
    const mapboxgl = require('mapbox-gl')
})

4。Initialize the map with your access token and the options you want. As for the style, you can either create your own in the amazing Mapbox Studio, use one of the default styles or choose among the publicly available styles.


    const map = new mapboxgl.Map({
      accessToken: 'YOUR_TOKEN',
      container: 'map', // <div id="map"></div>
          style: 'mapbox://styles/mapbox/streets-v9', // default style
          center: [-21.9270884, 64.1436456], // starting position as [lng, lat]
          zoom: 13
   })

Adding markers with popups

Further down in your mounted hook, you can add markers with popups.
Tip: You can use HTML for the content of the popup.

yourMarkersArray.map((marker) => {
    const LngLat = [marker.location.lng, marker.location.lat]
    const popup = marker.description
    new mapboxgl.Marker()
        .setLngLat(LngLat)
        .setPopup(popup)
        .addTo(map) // Initialized above
})

Real-world example

I made this map for a client: https://www.gemuese-lieferdienst.ch/depots/karte/

The repository is private, but here's a gist with the relevant source code: https://gist.github.com/mornir/9e85e65caba46e55269302e8a134e04e

Closing words

I hope this post was useful to you. Don't hesisate to reach out in the comments below if something is not clear or if you know a better/simpler approach.

Go make awesome maps now!

Source of hero image: https://www.flickr.com/photos/mapbox/23757790495

Truly Responsive Grid with CSS Grid

Jérôme Pott — Mon, 01 Jun 2020 08:17:15 +0000

This article describes really well how to make a responsive grid with CSS Grid:

How to make your HTML responsive by adding a single line of CSS

Per for Scrimba ・ Jun 12 '19

#html #css #cssgrid

But we can add one final ingredient to make that CSS line even better.

In the article, the minimum width of the grid items is set to 100px. This means that if the availabe size of the grid container is narrower than 100px, the grid items will overflow. This is quite unlikely to happen with a minimum width of only 100px. But the higher that number, the more likely the columns is to overflow on small viewports.

Cutting edge CSS to the rescue!

Instead of having to resort to a media query, we can use: the CSS function min(), which is now widely supported.

.container {  
    display: grid;  
    gap: 1rem;  
    grid-template-columns: repeat(auto-fill, minmax(min(300px, 100%), 1fr));
}

min() accepts one or more values and returns the smallest value. As soon as the full width of the columns is narrower than 300px, the columns will observe the 100% CSS declaration and shrink below 300px.

For a better understanding of the issue and of its solution with the min() function, I highly recommend reading this article:
https://evanminto.com/blog/intrinsically-responsive-css-grid-minmax-min/

Nuxt, Netlify and the trailing slash

Jérôme Pott — Sun, 24 May 2020 15:46:06 +0000

Introduction

I recently noticed that by default Netlify redirects routes that don't end with a slash to their slash equivalent: for example www.example.com/about → www.example.com/about/ Netlify docs

This only happens to pages served directly by Netlify, in other words, pages served on the first load. As you know it, Nuxt then hydrates into a SPA and Vue Router takes care of the navigation. However, as soon as you refresh the page, you will be redirected to the URL with a trailing slash.

Negative Impact

If you don't use a trailing slash for both your internal links and your sitemap, the default redirection by Netlify can have some unwanted consequences. I can think of two:

Performance: I didn't measure it myself, but a comment on the Gatsby repository reports a delay of 100-300 ms, and even of 1s on a slow network. By the way, when doing a lighthouse audit on the page without the trailing slash, you'll get a warning about the redirection.
SEO: Google may be confused by the two URLs. Its crawler will index the routes with a trailing slash because of the Netlify redirect, but then will also index the routes without the slash because of the sitemap (by default, the Nuxt sitemap module doesn't add trailing slashes). If you don't use canonical links, the crawler might consider the content as duplicates. Fortunately in all my projects, I saw from the Google Search Console that the crawler was smart enough to discard one version. But SEO is too important to rely on the cleverness of Google.

Solution

How to solve this issue? First let's get this out of the way: it doesn't make any difference whether we use a trailing slash or not. What's important is to be coherent. So is it a matter of taste? At first I would have said yes. But actually I personally realized that when browsing websites, I really don't pay much attention to the URL, let alone to the presence of that slanted bar.

I would say that it's more a matter of tooling: don't fight the tooling! In our case, we want to choose one version, but Netlify can only force the trailing slash and not the opposite (at least I didn't find how, but at least you can still disable the forced redirection to the trailing slash).

Adding a trailing slash to our internal links

Now we need to update all our internal links with a trailing slash. Depending on the size and the complexity of the project, it's likely that we miss a couple. But no worry, even without a trailing slash, the navigation will still work as expected. By default, Nuxt handles both versions. However, for new projects, I recommend enforcing the trailing in nuxt.config.js:

router: {
    trailingSlash: true,
},

When developing, we'll now be able to easily spot nuxt-link without a trailing slash, because they will return a 404.

Editing our sitemap

Then we need to take care of our sitemap. We're in luck again! There's a trailingSlash property which can be set to true:

sitemap: {
    hostname: 'https://www.mywebsite.com',
    trailingSlash: true,
},

Voilà! Now we've fully committed ourselves to the trailing slash. 🤗
Don't hesitate to correct me in the comments if I said something inaccurate. 🙊

A little reminder

I take the opportunity to remind my fellow devs that the following properties are not needed for the sitemap module when using nuxt generate:

setting cacheTime. This option has no effect in static mode.
setting routes to the same value as generate.routes. By default, the sitemap module will use the dynamic routes defined in generates.routes.

Sources

Preventing 301 redirects on URLs with no trailing slashes (Netlify)
Hero image by Noora AlHammadi