Forem: Gert Glükmann

How to Get Videos to Work in Safari With Gatsby and Service Workers

Gert Glükmann — Tue, 18 Feb 2020 08:59:48 +0000

Adding service workers to a site breaks videos in Safari and iOS devices

I was making a website where hero components have videos, and before adding gatsby-plugin-offline, everything was working fine. I did some browser testing and all browsers seemed fined, videos were fine. Then I decided that it’s time to add the service worker and to make the website installable and work offline. I added the plug-in and tested everything with Chrome and Android. Everything as it should be! But then I opened it with my iPad and saw that videos are not playing at all, not even loading.

That seemed odd as videos were implemented with the <video> HTML tag and they were standard MP4 files. Luckily, I had only added the service worker, so I started suspecting it had something to do with that.

I came across Jeremy Keiths’ article where he describes how he had the same problem. He refers to a solution and a more in-depth explanation in a post by Phil Nash. It looks like Safari needs service workers to support byte-range requests to play media. As the documentation for Safari says:

“HTTP servers hosting media files for iOS must support byte-range requests, which iOS uses to perform random access in media playback.”

They both went with different approaches to a solution. Phil fixed the service worker to cache video files, but Jeremy opted for always loading videos from the network and never caching them.

I’m going to show you how to implement both solutions with gatsby-plugin-offline.

Get Videos From the Cache

gatsby-plugin-offline uses Workbox for generating service workers. Luckily, Workbox already has an advanced recipe for how to serve videos and audio. This is exactly how we’ll implement it. We’ll just have to append it to the service worker generated by Gatsby.

First, we need to add attribute crossOrigin="anonymous" to our HTML <video> tag:

<video src="movie.mp4" crossOrigin="anonymous"></video>

Second, we create a file that will be appended to the generated service worker file. Let’s name it sw-range-request-handler.js. We’ll put that into the root folder of our project.

Content of this file will be:

// Add Range Request support to fetching videos from cache
workbox.routing.registerRoute(
  /.*\.mp4/,
  new workbox.strategies.CacheFirst({
    plugins: [
      new workbox.cacheableResponse.Plugin({ statuses: [200] }),
      new workbox.rangeRequests.Plugin(),
    ],
  }),
  'GET',
);

We match all requested MP4 files and use CacheFirst strategy to search for video files from the cache. If there isn’t a cache match, then the file will be served from the network.

If you look at the example from Workbox advanced recipes, you’ll see that the usage of plugin functions are a bit different. That’s because as of now, gatsby-plugin-offline uses Workbox v.4, but the example is for v.5.

You’ll see that we didn’t import any functions from Workbox, either. That’s because we only append our file content to the generated service worker file, where all those plugins are already added to the workbox object.

When gatsby-plugin-offline updates to v.5 of Workbox, we’ll need to update how we use the plugins:

// Add Range Request support to fetching videos from cache
workbox.routing.registerRoute(
  /.*\.mp4/,
  new workbox.strategies.CacheFirst({
    plugins: [
      new workbox.cacheableResponse.CacheableResponsePlugin({
        statuses: [200],
      }),
      new workbox.rangeRequests.RangeRequestsPlugin(),
    ],
  }),
  'GET',
);

Now we need to use the appendScript option in gatsby-plugin-offline config to append our file to the service worker. Add the options object to gatsby-config.js:

{
  resolve: `gatsby-plugin-offline`,
  options: {
    appendScript: require.resolve(`./sw-range-request-handler.js`),
  },
},

Now running gatsby build command and looking into public/sw.js file, you’ll see that at the very end is our code. Showing videos in Safari and iOS devices will work again after the service worker is updated.

But this caches all our videos to Cache API storage, and when you have a lot them or they’re big files, then it’s probably not a very good idea to take that much space from the user’s device. And are the videos really that important when the user is offline?

Get Videos From the Network

To never cache videos to storage and only get them from the network, you need to overwrite the Workbox config. That can be done by overwriting the workboxConfig object inside the options object.

First, we should still add the crossOrigin="anonymous" attribute to our HTML <video> tag:

<video src="movie.mp4" crossOrigin="anonymous"></video>

Second, we modify the gatsby-config.js file to overwrite the existing workboxConfig:

{
  resolve: `gatsby-plugin-offline`,
  options: {
    workboxConfig: {
      runtimeCaching: [
        {
          urlPattern: /.*\.mp4/,
          handler: `NetworkOnly`,
        },
      ],
    },
  },
},

We use NetworkOnly strategy to get our MP4 file. It will never be searched from the cache.

But be aware that our code now overwrites the default caching for gatsby-plugin-offline. It would be better to add it to the existing list of caching options so that everything else will still be cached, and with the right strategies.

Conclusion

At first, it can be very confusing to understand why videos are not playing when the page has service workers, but these two solutions should fix that. This problem doesn’t occur only when using Gatsby, and there are solutions for those other situations, too.

If you’re using Workbox, then look at their advanced recipes. If you’re using pure service worker implementation, then look at Jeremy Keith’s article “Service Workers and Videos in Safari” or the post by Phil Nash, “Service Workers: Beware Safari’s Range Request.” They give a more in-depth explanation about that problem.

Thanks.

Create Multilingual Web Pages With Gatsby, WordPress, WPML, and ACF

Gert Glükmann — Tue, 28 Jan 2020 18:26:57 +0000

Bring your site to the world

Gatsby page with English and Estonian content from WordPress

Gatsby is a great static-site generator to use today. Its ecosystem is really large, and you get a lot out of the box. Getting Lighthouse maximum scores is almost default with Gatsby. Anyone who is working with WordPress and wants to separate the CMS and the website itself should at least try to create something with Gatsby. It is really easy to use, and the documentation is very straightforward.

Gatsby is using GraphQL for getting data from local files or from external endpoints. If you want use it with WordPress for getting pages, posts, media, ACF fields, etc., you don’t have to manually figure it out. There’s a library that creates schema from the WordPress REST API to GraphQL and it’s backed by Gatsby. It’s WPGraphQL, and there’s a Gatsby plugin, gatsby-source-wordpress, to connect your WordPress site to. It’s using that connector library underneath.

This piece expects you have WordPress set up with WPML and ACF plugins activated. It also expects you have the gatsby-source-wordpress plugin set up in gatsby-config.js. In the example repository, you can see how I connected to WordPress from Gatsby.

The Problem: Changing the Language in GraphQL

There’s only one problem. Lets say you’re creating a page with only one view, and this will be on the root URL //your-site.domain/. Now, you’ll need to create the same page in a different language that’ll sit in the //your-site.domain/et URL — just like when using standard WordPress. How do you do it using WPML in Wordpress and creating pages with Gatsby?

The WordPress REST API endpoint gets you content for the default language. Example: //your-site.domain/wp-json/wp/v2/pages is in your WPML default language. You can switch languages by adding the ?lang=et parameter, but with GraphQL you can’t add parameters like that. You’ll have to add it as a filter to the query. The GraphQL schema in Gatsby doesn’t have that filter for WMPL. We have to add it ourselves.

Creating Pages in Gatsby

I have created a page in WordPress with the slug homepage and with the ACF fields title and description.

ACF fields in WordPress

Make sure every page with a different language has the same slug because WordPress creates new slugs for different languages. When I created a new page in the Estonian language, WordPress created the slug homepage-2. You could, of course, query it with its ID, too, but it’ll be easier to query data for that page with a known slug. You’ll see later where we’re going to use it.

Creating pages in Gatsby is usually done by adding new JavaScript files to the src/pages folder with the name that’ll be the route. Like the about.js file would have /about as its URL. When you’re creating pages from WordPress, you’ll have to create them during the build time. You’ll need to open gatsby-node.js and use the createPages function that Gatsby provides.

For our case, we’ll need to create a separate page for all languages. Our index page will have the URLS / for English and /et for the Estonian language.

const path = require(`path`)

const languages = [
  {
    path: "/",
    code: "en_US", <- taken from WPML language codes
  },
  {
    path: "/et",
    code: "et",
  },
]

exports.createPages = async ({ actions: { createPage } }) => {
  const HomepageTemplate = path.resolve("./src/templates/Homepage.js")

  languages.forEach(lang => {
    createPage({
      path: lang.path,
      component: HomepageTemplate,
      context: {
        lang: lang.code,
      },
    })
  })
}

We’ve created an array with languages that match our WordPress WPML setup. This will be looped over, and one page will be created for each language with a given path.

You can see there’s a template file from ./src/templates/Homepage.js. This will be the template that has our index-page components inside — just like when you’d add a new page inside the src/pages folder.

Next, as you’d think, we’ll have to create that template file. Create the folder templates inside ./src, and inside it, create a file named Homepage.js.

import React from "react"
import { Link } from "gatsby"

import Layout from "../components/layout"

const HomepageTemplate = () => {
  return (
    <Layout title="Title">
      <p>Description</p>

      <Link to="/">English</Link>
      <Link to="/et">Estonian</Link>
    </Layout>
  )
}

export default HomepageTemplate

The hardcoded texts Title and Description will be replaced with the texts from WordPress a bit later.

If you run gatsby develop, then you can switch between those two views. But right now, the content is exactly the same.

Getting Data from WordPress

In your Homepage.js file, add the following GraphQL query before export default HomepageTemplate. Make sure to add graphql to import from gatsby as the named import.

import { graphql, Link } from "gatsby"

...

export const query = graphql`
  query {
    wordpressPage(
      slug: { eq: "homepage" }
    ) {
      acf {
        title
        description
      }
    }
  }
`

export default HomepageTemplate

Here you can see we’re querying a WordPress page with slug that equals "homepage" and two ACF fields — title and description — that we had set up in WordPress. The query result is added to your HomepageTemplate component as the prop data.

const HomepageTemplate = ({
  data: {
    wordpressPage: {
      acf: { title, description },
    },
  },
}) => {

...

With object destructuring, we have title and description ready to use inside our React component. We can change our HTML.

<Layout title={title}>
<p>{description}</p>

Now if you run it in your browser, it shows text in the default language and switching between those pages will still not change anything yet again. We’ll get to that now.

Adding Content in Other Languages to the WordPress REST API So GraphQL Can Create Schema

Switching pages doesn’t change the language because the WordPress REST API is only giving out data in one language, and we’ll have to change that.

First, look at the WordPress REST API //your-site.domain/wp-json/wp/v2/pages, and you can see only one object with content in the default language there. But we’ll need to have both languages there in different objects.

For that, you’ll need to open your currently active theme code, located at ./wp-content/themes/example-theme/. Open the file functions.php, and add the following lines there.

add_action('rest_api_init', function () {
  if (defined('REST_REQUEST') && REST_REQUEST) {
    // Add all WPML language translations to rest api when type is page
    add_action('parse_query', function ($q) {
      if ($q->query_vars['post_type'] == 'page') {
        $q->query_vars['suppress_filters'] = true;
      }
    });
  }
});

This trick is taken from wmpl.org forum. Now if you look at the WordPress REST API, //your-site.domain/wp-json/wp/v2/pages, you can see there are two objects with different languages.

That means GraphQL can now create schema for both languages.

Before we can start using it inside our React component, we need to be able to get the current language code, too. If you look closely into the REST API response, you’ll see that title and description are in different languages inside different objects, but there’s no way to get the language code.

For that, you’ll need the WPML REST API plugin activated inside WordPress. For us, it adds wpml_current_locale to the REST API response. This way we can know which language to query from GraphQL.

Getting Texts in the Right Language From GraphQL

If you look at the gatsby-node.js file, you can see in our languages array, we have code defined for each language. This code is exactly the same as wpml_current_locale. If you look at where we’re using the createPage function, you’ll see we’re giving the context as the property with that code.

createPage({
  path: lang.path,
  component: HomepageTemplate,
  context: {
    lang: lang.code, <- sending language code to GraphQL query
  },
})

We’ll get this as a GraphQL variable inside Homepage.js, where we’re going to make the query.

Update the Homepage.js GraphQL query with the following code.

export const query = graphql`
  query($lang: String) {
    wordpressPage(
      slug: { eq: "homepage" }
      wpml_current_locale: { eq: $lang }
    ) {
      acf {
        title
        description
      }
    }
  }
`

$lang is the language code we sent with the context from the createPage function. We pass it to query the filter as equal to wpml_current_local.

And we’ve done it!

Now if you run it in a browser, it shows the text in English, and when switching it to a different language, title and description are going to change.

Conclusion

This solution is pretty standard for creating pages with Gatsby and getting data from Wordpress, but that one little trick inside the WordPress theme functions.php is what matters to get data for all available WPML languages.

Thanks.

Here’s a link to the example repository.

Validating Our Idea With Google Design Sprint 2.0

Gert Glükmann — Tue, 28 Jan 2020 15:24:04 +0000

When you have an idea for an app but you are not sure how valid it is, how to estimate it quickly and with low costs?

We had an idea for an app, but weren’t sure how to approach it. We had looked at competitors and wanted to do it differently and better. The idea wasn’t something very revolutionary so we needed to be sure our soon-to-be users and service providers actually need it.

We had heard about Google Design Sprint and thought we should give it a go: validate our idea and come out with a prototype to test on real users before starting to create the real app.

This article is about how we did it — I suppose it goes a bit differently every time.

Google Design Sprint 2.0 (GDS)

GDS is a four day sprint with different roles, a lot of discussions and research. Every day has a specific focus and outcome.

4 days of Google Design Sprint 2.0. Photo from invisionapp.com

It is crucial to include every role you have in your group. Every person with a different role and background has a distinctive perspective on how things should work. Roles can vary depending on who you are working with — product manager, product owner, developer, analyst, tester, designer, UX person, sales person, you name it — just one role you really can’t be without is someone who can make a clickable prototype that is used to present on the fourth day to real users.

Google Design Sprint is usually done from Monday to Thursday, but we needed to pause our everyday work and find a time that suited everyone, so we went with from Saturday to Tuesday.

Our team consisted of a product manager, developer, marketing person, two business managers and a designer.

First day — Saturday

Usually design sprint needs some preliminary analysis to figure out who are your personas (users who would use your app) and create some user flows, but we didn’t have time to do it beforehand. We had only done some discussions about our idea, talked about it with some of our acquaintances that worked in that field and thought about business model. Only thing we did for this design sprint was buying stickers with different colours. 👏

So we started off with gathering ideas. We mapped out all possible scenarios and user groups. We didn’t limit ourselves with anything, every idea was a possibility. We tried to think about every feature or flow our app should do. For advanced user or one time visitor, didn’t matter. For the scope of MVP or very far fetched and complicated features, didn’t matter. We just wanted to get it all out there — no limits.

Our hub in a meeting room with ideas

To be sure we have thought about our idea from every angle, we had a MethodKit for Startups to help us. This kit is a set of cards that have keywords on and we tried to answer them or find a solution. This helped to pay attention to the possible danger zones, legal limitations or even how the marketing should be and how the user should even find us.

After all these discussions and research, everyone took some time to think it through and we started drawing our ideas as they should look in the app.

First day ended with a lot of drawings of different flows. Everyone tried to visualize how they saw the user flows or some specific features. However, it was not obligatory to draw all the possible views of the app, just the few one had in their mind.

Second day — Sunday

We had gathered again the next morning and began the day with drawing new ideas everyone had come up with while being away and fixed all the drawings to our glass wall. Usually the next step would be for everyone to look at other ideas and mark the most liked features with dots or stars, but we just looked at drawings to understand what others had thought of.

Next step was for us to start deciding what we should keep and what not. Especially for our prototype and for MVP. We started cutting parts of drawings out and gluing them together with duct tape to make user flows. This took most of the day, as new ideas came and erupted with ease. Nevertheless, at the end of the day we managed to agree on the main user flows.

Adding solutions to the glass wall

After our flows were ready, we had to prepare texts that would be used in the prototype. This is always a challenge, especially as we decided to not use English and use our native Estonian language instead.

Second day resulted with one mayor flow ready for prototyping in the third day.

Third day — Monday

The activities of the third day didn’t insist on the whole group being together in one place. Everyone took some up tasks to deal with separately or in a small group. Like figuring out the payment system, making more market research or as for our designer, she started prototyping our user flows into Figma.

Everyone who had some friends or acquaintances who they could talk to and show our prototype, set up meetings for user testing.

We also needed to create a questionnaire for user testing, but we didn’t know how much of the prototype will be ready at the end of the day. Luckily Figma is a collaboration tool and we could see almost live how much is done from the shared link. But it was hard to create it and we pretty much abandoned it. Our designer finished at 8pm in the evening, we had enough views to show the next day.

Fourth day — Tuesday

In the morning we did some updates to prototype and after lunch everyone went their own way to their meetings they had set up the day before. We didn’t have a questionnaire to ask the same questions but everyone did it themselves.

At the end of the day we should have got together to discuss the feedback and make conclusions, but we did it the next day.

Conclusion

We are going forward with our idea, we got a lot of great feedback and knowledge about what users want. Next step is to put together the scope of MVP.

All-in-all we highly recommend this approach to validate and confirm whatever idea you have. This 4-day event not only puts your idea to the test, but also strengthens the relations between your teammates. It is guaranteed that you will learn something new about someone or something. Timewise it is definitely a sprint, as its name claims to be, but actionwise more of a marathon.

Thanks.

Edited by Mare Hunt, Marilin Moor & Kaur Esnar

Let Users Know When You Have Updated Your Service Workers in Create React App

Gert Glükmann — Sat, 04 Jan 2020 14:18:42 +0000

Show an alert component when you have pushed a new service worker, allowing the user to update their page right away

Create React App (CRA) is great for developing progressive web apps (PWAs). It has offline/cache-first behaviour built in. It’s not enabled by default, but you can opt in. It uses service workers and has a lot of pitfalls you can read about from official docs.

This piece is going to show you how to trigger an alert (or toast or actually whatever component you want) when you have updated your service worker. Usually, this will be when your app has some new updates and you want the user to see them right away.

This piece assumes you have a new project made with CRA. If you don’t, you can do it easily with:

npx create-react-app my-app

Registering a Service Worker

If you navigate to src/index.js you find on the last line:

serviceWorker.unregister();

Switch it to:

serviceWorker.register();

And registering a service worker is pretty much done. If you deploy your app to an HTTPS-enabled site, it’ll be cached.

Remember that service-worker implementation in CRA works only in production. You can make sure it works by checking the offline checkbox from the Chrome DevTools Network tab and reloading your page.

It still shows your app!

Is your updated Service Worker not visible?

Now comes the harder part. You add or change code in your app and deploy — but users aren’t seeing your updates. As the docs state:

The default behavior is to conservatively keep the updated service worker in the “waiting” state. This means that users will end up seeing older content until they close (reloading is not enough) their existing, open tabs.

What if you want users to see your new updates without having to close all tabs? CRA is providing that option, too.

In the src/serviceWorker.js is a function named registerValidSW that provides access to service-worker updates and success events via callbacks and also prints information about these events to the console. This is how you know when to show that the app is cached for offline use or there’s a newer version available.

The registerValidSW function takes in two arguments — the second one is the one we’re interested in. config can be an object that has onSuccess and onUpdate callbacks in it. You should wonder now how and where could we make such an object?

If you look where registerValidSW is called, you see that it comes from export function register(config). This is the very same function that we saw on the last line in src/index.js. Now, we’re back in our own code and we could do something like:

serviceWorker.register({
  onSuccess: () => store.dispatch({ type: SW_INIT }),
  onUpdate: reg => store.dispatch({ type: SW_UPDATE, payload: reg }),
});

When those functions are called, they dispatch a function, and you can do whatever you want with them, like show a message.

With onSuccess it’s easier — you can just show the alert somewhere on your page. Perhaps it says, “Page has been saved for offline use.”. With onUpdate, you want to let the user know there’s a newer version available, and you can add a button with “Click to get the latest version.”.

Showing a user alert when page is first time saved for offline use

In the above example, I used Redux store to dispatch an action, and I have store set up with:

const initalState = {
  serviceWorkerInitialized: false,
  serviceWorkerUpdated: false,
  serviceWorkerRegistration: null,
}

Now when dispatching SW_INIT type action, we change serviceWorkerInitialized state to true and can use this selector inside any React component.

In my src/App.js (or any other component), we get it from store with Redux Hooks:

const isServiceWorkerInitialized = useSelector(
  state => state.serviceWorkerInitialized
);

And we can show an Alert when it is true:

{isServiceWorkerInitialized && (
  <Alert text="Page has been saved for offline use" />
)}

^{Alert when Service Worker is installed}

Showing the user an alert and a button when a new version of Service Worker is available

Using the same pattern, we show alert components when service workers have been updated.

{isServiceWorkerUpdated && (
  <Alert
    text="There is a new version available."
    buttonText="Update"
    onClick={updateServiceWorker}
  />
)}

This time we add an onClick function that’ll be triggered when clicking on the “Update” button inside the alert component. Because we want user to click on a button and get a new version of the app.

All the magic is inside updateServiceWorker function that we are going to create.

This example is using CRA v3, which has a little addition generated inside the public/service-worker.js file. (If you’re using an older version of CRA, I’ve created a solution for that, too — just write to me.)

skipWaiting is a function that forces your new service worker to become the active one, and next time the user opens a browser and comes to your page, they can see the new version without having to do anything.

You can read more about skipWaiting from MDN. But this just forces your service worker to be the active one, and you see changes only next time. We want to ensure the user has a new version right now. That’s why we have to call it and then refresh the page ourselves — but only after the new service worker is active.

To call it, we need an instance of our new service worker. If you scroll back up to where we registered the service worker, you can see the onUpdate function had an argument called reg. That’s the registration object, and that’s our instance. This will be sent to the serviceWorkerRegistration property in the Redux store, and we can get our waiting SW from serviceWorkerRegistration.waiting.

This will be our function that’s called when the user presses the “Update” button inside the alert:

const updateServiceWorker = () => {
  const registrationWaiting = serviceWorkerRegistration.waiting;

  if (registrationWaiting) {
    registrationWaiting.postMessage({ type: 'SKIP_WAITING' });

    registrationWaiting.addEventListener('statechange', e => {
      if (e.target.state === 'activated') {
        window.location.reload();
      }
    });
  }
};

Because the service worker is a worker and thus in another thread, to send any messages to another thread we have to use Worker.postMessage (MDN). Message type is 'SKIP_WAITING' as we saw from generated public/service-worker.js file.

And we create an eventListener that waits for our new service-worker state change, and when it’s activated, we reload the page ourselves. And that’s pretty much it.

Now the user can see there’s a newer version available, and if they want, they can update it right away.

^{Alert when new Service Worker is available}

Conclusion

I think it’s good to let the user decide if they want a new version right away or not. They have the option to click on the “Update” button and get the new version or just ignore it. Then, the new version of the app will be available when they close their tabs and open your app again.

Thanks.

Here’s a link to the example repository.