DEV Community: a-tonchev

Migrating from KOA to uWebSockets.js in less than 2 hours

a-tonchev — Thu, 29 Sep 2022 10:38:15 +0000

When developing own software, everyone wants to be creative and to make the best, coolest and fastest software.

While creating the ShopSuy shop system of JUST-SELL.online we want to create the fastest online shop possible. And the fastest software demands the fastest development stack.

I was using KOA as backend API for our software, then one day I had an idea to use websockets to reach additional performance.

KOA do not support Websockets by itself, so I tried to research for the best websockets available, this is how I landed on uWebSockets.js (uws)

I made also some benchmark on my existing server compared to uws and uws was around 4 times faster than KOA.

So I have decided to migrate from KOA to uws.

Well said, but the things are not so easy. I needed to figure out a way to reuse my KOA ctx and to adjust the routing. After a lot of thinking and reading I came to a solution, which implementation costs me less than 2 hours.

Okay lets start:

In KOA I had something like this:

const app = new Koa();
const router = new KoaRouter();

// CORS Setup
app.use(cors({
  credentials: true,
}));

// Setup some custom services and DB
app.use(async (ctx, next) => {
    await doSomething();
    try {
      await next();
    } finally {
      cleanup();
    }
});

// Setup another function
app.use(doSomethingElse);

// Thus I had my routes in KOA:
const routes = [
 {
   method: 'get',
   path: '/', 
   steps: [
     ctx => { ctx.body = 'Hello API!'; }, 
   ] 
 }, 
 { 
   method: 'post',
   path: '/users', 
   steps: [
     async (ctx, next) => { await doStepOne(); return next(); }, 
     async (ctx, next) => { await doStepTwo(); return next(); },
     async ctx => {
        const users = await getUsersFromDB();
        if(!users) { 
         ctx.body = 'Not Found'; 
         ctx.status = 401; 
         return; 
        }
        ctx.body = { users };
        return ctx.body;
     }
   ] 
 }, 
];

// Setup routes

routes.forEach(route => {
    router[route.method](route.path, ...route.steps);
})

app.use(router.routes());
app.use(router.allowedMethods());

const port = Number(process.env.PORT || 8080);
app.listen(port, () => {
  console.log(`Server running on port ${port}`);
});

Okay, until here is clear, now lets try to do the same with uws:

First thing would be to create custom ctx object, that will include all the functions you need in your KOA project.
This will do the setupContext function, which receives the uws req, res and the path of the route:

// If you want to use get params
const getParameters = (req, res, path) => {
  const params = {};

  if (req.getMethod() !== 'get' || !path.includes('/:')) return params;

  let paramsIndex = 0;

  for (const name of path.split('/')) {
    if (name[0] === ':') {
      params[name.substring(1)] = req.getParameter(paramsIndex);
      paramsIndex++;
    }
  }

  return params;
};

// And here we create our ctx
const setupContext = async (req, res, path) => {
  const queryString = req.getQuery();

  const ctx = ({
    state: {},
    body: '',
    params: getParameters(req, res, path),
    executeAfterFinish: [],
    request: {
      header: {},
      body: {},
      url: req.getUrl(),
      query: queryString ? qsToObject(queryString) : {},
    },
    userAgent: {
      _agent: {},
    },
  });

  // This function we need to simulate the finally calls 
  ctx.addToExecuteOnFinish = newFunction => ctx.executeAfterFinish.unshift(newFunction);

  // Setup Headers
  req.forEach((k, v) => {
    ctx.request.header[k] = v;
  });

  [ctx.request.body, ctx.request.rawBody] = await jsonParser(res) || [{}, ''];

  return ctx;
};

The jsonParser function you can find here:

https://github.com/a-tonchev/rest-api-boilerplate/blob/master/startup/startupHelpers/jsonParser.js

Which is based on this issue: https://github.com/uNetworking/uWebSockets.js/discussions/64

After we have our ctx, we can use now the full solution for the migration:

const app = uWebSockets.App();

// Creating of our new routes 
// Don't forget to rename the method 'all' to 'any' if you have such

const routes = [
 {
   method: 'get',
   path: '/', 
   steps: [
     async ctx => { ctx.body = 'Hello API!'; }, 
   ] 
 }, 
 { 
   method: 'post',
   path: '/users', 
   steps: [
     async ctx => { await doStepOne(); }, 
     async ctx => { await doStepTwo(); },
     async ctx => {
        const users = await getUsersFromDB();
        if(!users) { 
         ctx.body = 'Not Found'; 
         ctx.status = 401; 
         return; 
        }
        ctx.body = { users };
     }
   ] 
 }, 
];

routes.forEach(route => {
    const { path, method, steps } = route;

    app[method](path, (res, req) => {

      // In uws we need to handle onAborted events:

      let isAborted = false;
      res.onAborted(() => {
        console.error('ABORTED!');
        isAborted = true;
      });

      try {
        (async () => {
          // Basically this is the place where we can simulate all our app.use 

          // Here we setup our ctx
          let ctx = await setupContext(req, res, path);

          // and here we start, don't forget to remove all next()
          await doSomething(ctx);

          // This is the finally step, we push it in an array that will be executed after our request finish
          ctx.addToExecuteOnFinish(cleanup);

          await doSomethingElse(ctx); // remove next() inside doSomethingElse

          // all the steps:

          try {
            for (const step of steps) {
              await step(ctx);
            }

            ctx.status = '200';
          } catch (err) {
            const {
              statusCode: status,
              body,
            } = err?.errorData || {};

            ctx.status = status || 500;

            ctx.body = body || {
              ok: false,
              data: {},
              code: 500,
            };

            onError(err, ctx); // this is your custom error handling
          }

          if (!isAborted) {
            /* we need to use res.cork because we return from await -> https://unetworking.github.io/uWebSockets.js/generated/interfaces/HttpResponse.html#cork */
            res.cork(() => {
              res.writeStatus(`${ctx.status || 400}`); // The status should be always string in uws!
              setupCors(res, ctx.request.header.origin); // The cors need to be set after status, else we will get always status 200
              res.end(
                typeof ctx.body === 'object' ? JSON.stringify(ctx.body) : ctx.body,
              );
            });
          }

          // Clean-up functions
          for (const functionToExecute of ctx.executeAfterFinish) {
            if (functionToExecute.constructor.name === 'AsyncFunction') {
              await functionToExecute();
            } else {
              functionToExecute();
            }
          }

          ctx = null; // And the final cleanup
        })();
      } catch (e) {
        console.error(e);
      }
    });
  });
});

const port = Number(process.env.PORT || 8080);
app.listen(port, listenSocket => {
  if (listenSocket) {
    console.info(`Server running on port ${port}`);
  }
});

And this is the setupCors function:

const setupCors = (res, origin) => {
  res.writeHeader('Access-Control-Allow-Origin', `${origin}`)
    .writeHeader('Access-Control-Allow-Credentials', 'true')
    .writeHeader('Access-Control-Allow-Headers', 'origin, content-type, accept,'
      + ' x-requested-with, authorization, lang, domain-key')
    .writeHeader('Access-Control-Max-Age', '2592000')
    .writeHeader('Vary', 'Origin');
};

What we did:

We created our own ctx. Here you can rebuild easily by yourself everything that you need from your KOA project - userAgent, params, request, state etc...
We adjusted the routes
Move the app.use functions inside the route.forEach
Use regular await function instead of app.use(function)

And you don't need to change anything else in your whole project!

Thats it, you can see my whole uws + mongodb boilerplate project here:

https://github.com/a-tonchev/rest-api-boilerplate

We use the same approach in our Shop SaaS, here the demo:

https://demo2.shopsuy.com

Best Regards
Anton Tonchev
JUST-SELL.online

The simplest React mount/unmount animation with material UI and emotion

a-tonchev — Mon, 08 Nov 2021 14:17:26 +0000

Surely you want sometimes in react to animate an entrance and/or exit of unmounting component. Instead of using a library, there is a nice way to do it by yourself, just with material ui!

For this we will make use of the emotion css prop and the keyframes helper.

As of material ui we can just take the Box component

Our goal is to create an Animated component that can receive following props:
show: if the component is mounted or not
mountData: describing the entrance animation
mountData.keyframes: Standard css animation keyframes
mountData.time: Animation duration in seconds
mountData.type: Css animation type (e.g. linear, ease-out...)
unmountData: describing the exit animation
unmountData.keyframes: Standard css animation keyframes
unmountData.time: Animation duration in seconds
unmountData.type: Css animation type (e.g. linear, ease-out...)
unmountTimeout (optional): to provide a possibility for auto unmount the component after a timeout
setShow (optional): function to unmount the component, provided by the parent

If you don't provide the last two, the parent component will control the whole mount/unmount process.

And here is the solution:

import { Box } from '@mui/material';
import { useEffect, useState } from 'react';
import { css, keyframes } from '@emotion/react';

const defaultMountData = {};

const Animated = ({
  children,
  show,
  setShow,
  mountData = defaultMountData,
  unmountData = defaultMountData,
  unmountTimeout,
  ...rest
}) => {
  const [animationData, setAnimationData] = useState(null);
  const { time, type = 'linear' } = animationData || {};

  const animationCss = animationData?.keyframes ?
    css`animation: ${keyframes`${animationData.keyframes}`} ${time}s ${type}`
    : '';

  useEffect(() => {
    let mounted = true;
    let handler = null;
    let unmountHandler = null;

    if (show) {
      setAnimationData(mountData);
      if (unmountTimeout && setShow) {
        unmountHandler = setTimeout(() => mounted && setShow(false), unmountTimeout);
      }
    } else if (animationData) {
      const { time: unmountTime } = unmountData;
      handler = setTimeout(() => mounted && setAnimationData(null), unmountTime * 1000);
      setAnimationData(unmountData);
    }

    return () => {
      handler && clearTimeout(handler);
      unmountHandler && clearTimeout(unmountHandler);
      mounted = false;
    };

    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [mountData, unmountData, show]);

  if (!animationData) return null;

  return (
    <Box
      css={animationCss}
      component="div"
      {...rest}
    >
      {children}
    </Box>
  );
};

export default Animated;

We can not use default props for our default mount data, because it will cause all the time re-rendering.

Now in our component we place the mountData with the settings for entrance animation, the unmountData with settings for exit animation. As soon the show param become true, that will activate our Animated component entrance animation. After 4 seconds the exit animation will be played, and will set the shouldBeMounted variable to false, which will unmount the component:

const [shouldBeMounted, setShouldBeMounted] = useState(false);

<Animated
  show={shouldBeMounted}
  mountData={{
    keyframes: `
       0% {opacity: 0}
       100% {opacity: 1}
    `,
    time: 0.3,
  }}
  unmountData={{
    keyframes: `
      0% {opacity: 1}
      100% {opacity: 0}
    `,
    time: 0.8,
  }}
  unmountTimeout={4000}
  setShow={setShouldBeMounted}
>
  Text to hide with animation
</Animated>

If we don't want automated unmounting, we can just ignore the unmountTimeout and the setShow params. If we don't want entrance or exit animation, we can also just ignore the mountData/unmountData:

const [shouldBeMounted, setShouldBeMounted] = useState(false);

<Animated
  show={shouldBeMounted}
  unmountData={{
    keyframes: `
      0% {opacity: 1}
      100% {opacity: 0}
    `,
    time: 0.8,
  }}
>
  Text to hide with animation
</Animated>

Here, we control totally our Animated component from the parent, and we don't use any animation for the mount, we use animation only for unmount.

Well that's it!

This is a simple, fast and lightweight way to create mount animations just using css.

Best Regards
Anton Tonchev
JUST-SELL.online

Material UI 5 - the easiest way to migrate from makeStyles to emotion

a-tonchev — Thu, 16 Sep 2021 08:38:24 +0000

Material UI version 5 has cool new stuff, and also many breaking changes. The migration tool is also amazing, but the style migration might not be that easy. Migrating a huge project could be a real pain.

Fortunately, there is a way to make a new, easy way to simply migrate the existing structure to emotion. Lets start:

Styles Root

At first, don't forget to setup correctly the root styles, emotion's ThemeProvider should override the default Material designs:

import React from 'react';
import { ThemeProvider as MuiThemeProvider, StylesProvider } from '@material-ui/core/styles';
import { ThemeProvider } from '@emotion/react';

const theme = {
  background: 'linear-gradient(45deg, #FE6B8B 30%, #FF8E53 90%)',
};

const App = () => (
  <StylesProvider injectFirst>
    <MuiThemeProvider theme={theme}>
      <ThemeProvider theme={theme}>
        // All my components
      </ThemeProvider>
    </MuiThemeProvider>
  </StylesProvider>
);

export default App;

The custom hook

For the custom hook, we will make use of the framework agnostic @emotion/css library, that can generate and inject classes from objects. More here

Then, lets make a custom hook, that can rebuild our makeStyles:

import { useMemo } from 'react';
import { css } from '@emotion/css';
import { useTheme } from '@emotion/react';

const useClasses = stylesElement => {
  const theme = useTheme();
  return useMemo(() => {
    const rawClasses = typeof stylesElement === 'function'
      ? stylesElement(theme)
      : stylesElement;
    const prepared = {};

    Object.entries(rawClasses).forEach(([key, value = {}]) => {
      prepared[key] = css(value);
    });

    return prepared;
  }, [stylesElement, theme]);
};

export default useClasses;

This component will receive a object or a function with the styles, and create corresponding classes.

Then the last Step is - rework:

The old components

// TODO: Unwrap the function from makeStyles and rename useStyles
const useStyles = makeStyles(theme => ({
  paper: {
    marginTop: theme.spacing(8),
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
  },
  ...
}));


const TheComponent = () => {
 const classes = useStyles(); // useStyles from Material UI
}

will become

// TODO: Unwrap the object from makeStyles and rename useStyles
const styles = theme => ({
  paper: {
    marginTop: theme.spacing(8),
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
  },
  ...
});

const TheComponent = () => {
 const classes = useClasses(styles); // useStyles from custom hook
}

You can try also with pure object of classes:

The old component

// TODO: Unwrap the object from makeStyles and rename useStyles
const useStyles = makeStyles({
  paper: {
    marginTop: theme.spacing(8),
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
  },
  ...
});

const TheComponent = () => {
 const classes = useStyles(); // useStyles from Material UI
}

will become:

const styles = {
  paper: {
    marginTop: theme.spacing(8),
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
  },
  //...
};

const TheComponent = () => {
 const classes = useClasses(styles); // useStyles from custom hook
}

In summary:

We setup the ThemeProvider and StylesProvider in our root component
We create a custom hook useStyles
We get rid of the makeStyles and unwrap the styles from it
Rename useStyles e.g. to styles, because it is no more a hook
Replace useStyles call inside of the component with our useClasses hook, while we put the styles object/function as argument

And with just a little bit rework, we already use emotion :)

With this approach, we managed to migrate a 2-years Project in 1 hour.

If this simple function is not enough for you, like you need to use nested objects in the classes, typescript, withStyles or more, you can take a look at tss-react

Best Regards
Anton Tonchev
JUST-SELL.online

When I prefer not to use Regex ⛞

a-tonchev — Wed, 14 Apr 2021 15:30:39 +0000

Regex is surely very useful powerful tool, but it can very easily get complex and confusing.

In a big Project you can not avoid Regular Expressions, because there is not for any case alternative.

But there are some cases, that happens very often, where you might think – okay, I have to use regular expressions.

But there are some alternatives, that you might prefer to use:

Example – parse last part of URL

You have for example following link:

const link = 'http://www.google.com/m8/feeds/contacts/myemail%40gmail.com/base/nabb80191e23b7d9';

Now you would like to get the last part (which is an id) - nabb80191e23b7d9

If you make it with regex you would do something like this:

const result = link.match(/\/([^\/]+)\/?$/)[1];

And this will do the job. But the problem here is, you need to focus to understand the code, we can simplify the search with other approaches:

const result = link.substr(link.lastIndexOf('/') + 1);
// OR
const result = link.substr(-16);
// OR
const result = link.split('/').pop(-1);

And thus we will get the same result.

The last approach works on the same principle if we have something with dashes

here-is-my-id-nabb80191e23b7d9

here{SPLIT}is{SPLIT}my{SPLIT}id{SPLIT}nabb80191e23b7d9

And so on.

One thing here to mention is – regex is in the most of the cases slower. Not always, but mostly. Of course performance is not the most important thing in a project, especially in Client Side, it will be not noticable and probably it doesn’t matter, but the bigger benefits of no-regex examples is that we have more code readability and we want to cover more edge cases.

Search in HTML:

Now we want to parse all the link text in an HTML document as a string, e.g.:

const rawHtml = "<html><head><title>titleTest</title></head><body><a href='https://www.test1.com' mydata="13">test01</a><a href='https://www.test2.com'>test02</a><a href='https://www.test3.com'>test03</a></body></html>";

If we want to get all the text with a regex, we will end up with something like:

const regex =  /<a[^>]*>([^<]+)<\/a>/ig;
const result = rawHtml.match(regex).map(function(val){
return val.replace(/<\/?a[^>]*>/g,'');
});

But what happens if I add some tags inside of the link tag, e.g. bold text:

....<a href='https://www.test1.com' mydata="13">test01 with some <b>bold text</b> inside</a>....

Then my example is no more working, and I need to adjust it.

Another approach would be to use directly a DOMParser:

const doc = new DOMParser().parseFromString(rawHTML, "text/html");
const matches = [...doc.querySelectorAll('a')];
const result = matches.map(el => el.innerText);

So we will have the same result, and most important – we have clear code, and we can also extend the funcitonality. For example if we want to get the text only of links with data attribute mydata=”13”, we need to adjust the querySelector:

const matches = [...doc.querySelectorAll('a[mydata="13"]')];

We can parse any element, not only link. As soon we have a valid HTML – it will just work.

Validate URL:

As next we want to validate a URL, in regex I just copy this directly from stack overflow:

function validateUrl(string){
  return /(https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|www\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9]+\.[^\s]{2,}|www\.[a-zA-Z0-9]+\.[^\s]{2,})/.test(string);
}

Regular url like http://google.com or https://something.yahoo.de works fine,
But recently you can use also cyrillic (or other) characters in the domain, so a domain with the name:
http://имена.бг
would be identified as wrong URL.

Also IP domains with http://192.168.0.102 – the regex would identify it as an valid URL, but an invalid IP address, e.g.: http://392.168.0.102 , would be also identified as valid address.
The non-regex solution is to use an URL object
How would this work:

function validateUrl(string) {
    try {
        const url = new URL(string);
        if (url.origin !== 'null') return true;
    } catch (e) {
        return false;
    }
    return false;
}

This will validate all the mentioned edge cases, and also it is much cleaner and understandable solution.

Additionally it is easy to extend. For example if we want to parse only specific query parameter or if we want to set a query parameter, we could do something like:

let myUrl = new URL('https://google.com?test=1#someId');
myUrl.searchParams.get('test');
myUrl.searchParams.set('test2', 154);

we can easily also use the hash with myUrl.hash

Validate E-Mail Address

What do you think, how can we validate E-Mail Address without regex?

Well, right now I don’t know any better solution, so I would still use Regex.

But if you think about, we don’t really need to validate any possible E-Mail. If we have a System with E-Mail registrations, we would expect the user to receive a validation link on a existing E-Mail Address

Thats why instead of invest much time and effort in covering every possible edge case of the E-Mail Validation, it would be enough if we just have a simple regex validation, for example in the UI, just in case that the user makes a typo or forget the domain eding or something like this.

One exampe of such effort is this standard https://emailregex.com/

Well it works very nice for the most use cases, but I tryed it on cyrillic characters E-Mail, and it fails to identify a valid E-Mail. So it is also not optimal.

So, regex is cool, regex is nice and powerful, but not necessary the best in matching and replacing.

Flawless and Silent Upgrade of the Service Worker 🔌

a-tonchev — Tue, 06 Apr 2021 17:32:53 +0000

As many of you already know, the upgrading of the service worker gives us agony. Until now we always need to make some compromises. But what if I tell you, after a lot of struggling I figured out a way to update the service worker flawlessly?

No direct skipWaiting (which would break still running code, especially when code-splitting)
No confusing window.location.reload that makes bad user experience
No annoying pop-up window to tell the user to close all tabs and to refresh the page
No self-destroying service worker, no need to iterate around clients.

While accomplishing a flawless service worker update, we can solve these following problems:

❗ Need of all tabs to be closed, because old service worker is still in use by other tabs/windows
❗ Need of window.location.reload to get new service worker
❗ Need of User Interaction to update
❗ If the Service worker updates not fast enough, old HTML or old resources may still be present even after reload, so we would need again to force a reload

This Article is based on Create React APP (CRA) that has been generated with the cra-tempate-pwa, but the principle is of course the same for any Web App.

Okay, let’s start!

Step 1: Identify if new service worker is available

These can happen in 2 cases:

New service worker is being found and just installed
New service worker has already been installed, and now it is in the waiting state

Let’s use a global variable window.swNeedUpdate to know if there is a waiting service worker that needs installation. We can do this in our service worker registration (in CRA this would be the function registerValidSW of src/serviceWorkerRegistration.js):

Set window.swNeedUpdate = true; in the installingWorker.onstatechange event
Set window.swNeedUpdate = true; if registration in a waiting state has been detected

`serviceWorkerRegistration.js`



function registerValidSW(swUrl, config) {
  navigator.serviceWorker
    .register(swUrl)
    .then(registration => {
      if (registration.waiting && registration.active) {
        // WE SET OUR VARIABLE HERE
        window.swNeedUpdate = true;
      }
      registration.onupdatefound = () => {
        const installingWorker = registration.installing;
        if (installingWorker == null) {
          return;
        }
        installingWorker.onstatechange = () => {
          if (installingWorker.state === 'installed') {
            if (navigator.serviceWorker.controller) {
              // WE SET OUR VARIABLE ALSO HERE
              window.swNeedUpdate = true;

              if (config && config.onUpdate) {
                config.onUpdate(registration);
              }
            } else {
              //...
              if (config && config.onSuccess) {
                config.onSuccess(registration);
              }
            }
          }
        };
      };
    })
  //...
}

Step 2: Prepare cache storage name

The next thing we need is to make clear difference between the new and old cache storage.

In our service-worker.js (CRA: src/service-worker.js) we will use our own unique string, adding it into the cache name of the service worker. Here I am using a variable called REACT_APP_VERSION_UNIQUE_STRING from my .env file, but you can have any unique string you want, even static one. Just keep in mind that this variable should be unique and long, so that there are no mixed-up results when we search for it. And NEVER forget to change it when generating every new service worker!!!

We can setup our unique string and make use of the workbox-core setCacheNameDetails function:

`service-worker.js`



import { setCacheNameDetails .... } from 'workbox-core'; 

const CACHE_VARIABLE = process.env.REACT_APP_VERSION_UNIQUE_STRING;

setCacheNameDetails({
  prefix: 'my-project',
  suffix: CACHE_VARIABLE,
});

Step 3: Create own skipWaiting, which will work only if one client (tab/window) is available

It is not possible to get the number of all open tabs easily in JavaScript, but fortunately, the service worker knows how many clients it serves!

So, in the message-event listener we can create our own condition, let’s call it 'SKIP_WAITING_WHEN_SOLO':

`service-worker.js`



self.addEventListener('message', (event) => {
  // Regular skip waiting
  if (event.data && event.data.type === 'SKIP_WAITING') {
    self.skipWaiting();
  }

  // Our special skip waiting function!
  if (event.data && event.data.type === 'SKIP_WAITING_WHEN_SOLO') {
    self.clients.matchAll({
      includeUncontrolled: true,
    }).then(clients => {
      if (clients.length < 2) {
        self.skipWaiting();
      }
    });
  }
});

As you can see, when we send our SKIP_WAITING_WHEN_SOLO event, the skipWaiting method will be called only if there is 1 (or less) open clients!

When we look again at the problems above, we already solved the first one:

✅ Need of all tabs to be closed, because old service worker is still in use by other tabs/windows
❗ Need of window.location.reload to get new service worker
❗ Need of User Interaction to update
❗ If the Service worker updates not fast enough, old HTML or old resources may still be present even after reload, so we would need again to force a reload

Now when we have identified waiting service worker and when all tabs are closed, the next thing we need to do is to fire the skipWaiting SKIP_WAITING_WHEN_SOLO event on the right place.

Step 4: Send skipWaiting event when page get closed

What would be better place to fire the event than when page is closed or reloaded? In our serviceWorkerRegistration.js we add the beforeunload event, where we put our skipWaiting under the condition that new service worker is waiting to be installed:

`serviceWorkerRegistration.js`



const SWHelper = {
  async getWaitingWorker() {
    const registrations = await navigator?.serviceWorker?.getRegistrations() || [];
    const registrationWithWaiting = registrations.find(reg => reg.waiting);
    return registrationWithWaiting?.waiting;
  },

  async skipWaiting() {
    return (await SWHelper.getWaitingWorker())?.postMessage({ type: 'SKIP_WAITING_WHEN_SOLO' });
  },
};

window.addEventListener('beforeunload', async () => {
  if (window.swNeedUpdate) {
    await SWHelper.skipWaiting();
  }
});
// ...
}

To keep my code cleaner I used helpers like – SWHelper.

Now we also solved the next 2 problems:
✅ Need of all tabs to be closed, because old service worker is still in use by other tabs/windows
✅ Need of window.location.reload to get new service worker
✅ Need of User Interaction to update
❗ If the Service worker updates not fast enough, old HTML or old resources may still be present even after reload, so we would need again to force a reload

Okay, now if we close the Browser and open it again, we are all done. But there is only one problem – when we have waiting SW, and we have only 1 tab open, and we reload the tab, the service worker will get activated, but in the fast reload the old SW may still deliver us its old HTML which will cause fetch errors, since the old resources are no more available!

Step 5: Replace the cache response of the index.html request in the old service worker’s cache storage with the most-recent index.html

To reach this, we fully make use of the Cache.add() and the Cache.put() methods of the SW Cache API.

Now we will create the most important functionality of our Project. This Functions, simple said, copy all the content of index.html from our new service worker into our old service worker, and replace it. Isn’t it cool?

`service-worker.js`



const getCacheStorageNames = async () => {
  const cacheNames = await caches.keys() || [];
  let latestCacheName;
  const outdatedCacheNames = [];
  for (const cacheName of cacheNames) {
    if (cacheName.includes(CACHE_VARIABLE)) {
      latestCacheName = cacheName;
    } else if (cacheName !== 'images') {
      outdatedCacheNames.push(cacheName);
    }
  }
  return { latestCacheName, outdatedCacheNames };
};

const prepareCachesForUpdate = async () => {
  const { latestCacheName, outdatedCacheNames } = await getCacheStorageNames();
  if (!latestCacheName || !outdatedCacheNames?.length) return null;

  const latestCache = await caches?.open(latestCacheName);
  const latestCacheKeys = (await latestCache?.keys())?.map(c => c.url) || [];
  const latestCacheMainKey = latestCacheKeys?.find(url => url.includes('/index.html'));
  const latestCacheMainKeyResponse = latestCacheMainKey ? await latestCache.match(latestCacheMainKey) : null;

  const latestCacheOtherKeys = latestCacheKeys.filter(url => url !== latestCacheMainKey) || [];

  const cachePromises = outdatedCacheNames.map(cacheName => {
    const getCacheDone = async () => {
      const cache = await caches?.open(cacheName);
      const cacheKeys = (await cache?.keys())?.map(c => c.url) || [];
      const cacheMainKey = cacheKeys?.find(url => url.includes('/index.html'));
      if (cacheMainKey && latestCacheMainKeyResponse) {
        await cache.put(cacheMainKey, latestCacheMainKeyResponse.clone());
      }

      return Promise.all(
        latestCacheOtherKeys
          .filter(key => !cacheKeys.includes(key))
          .map(url => cache.add(url).catch(r => console.error(r))),
      );
    };
    return getCacheDone();
  });

  return Promise.all(cachePromises);
};

Here I exclude ‘images’ from the cache names and I also copy all the requests and their responses into the old service worker to cover some very rare theoretical possible edge cases (e.g. If the user has multiple tabs open with waiting service worker, installs from some of it the PWA, and goes immediately offline etc...)

The best place to call this functionality would be again in the “message”-event listener of the service worker, so we add there our newly created case:

`service-worker.js`



self.addEventListener('message', (event) => {
  // Regular skip waiting
  if (event.data && event.data.type === 'SKIP_WAITING') {
    self.skipWaiting();
  }

  // Our special skip waiting function!
  if (event.data && event.data.type === 'SKIP_WAITING_WHEN_SOLO') {
    self.clients.matchAll({
      includeUncontrolled: true,
    }).then(clients => {
      if (clients.length < 2) {
        self.skipWaiting();
      }
    });
  }

  // HERE COMES OUR NEWLY CREATED FUNCTION
    if (event.data && event.data.type === 'PREPARE_CACHES_FOR_UPDATE') {
    prepareCachesForUpdate().then();
  }

});

And the only thing left is to call this event, when we have installation of new service worker:

`serviceWorkerRegistration.js`



const SWHelper = {
  async getWaitingWorker() {
    const registrations = await navigator?.serviceWorker?.getRegistrations() || [];
    const registrationWithWaiting = registrations.find(reg => reg.waiting);
    return registrationWithWaiting?.waiting;
  },

  async skipWaiting() {
    return (await SWHelper.getWaitingWorker())?.postMessage({ type: 'SKIP_WAITING_WHEN_SOLO' });
  },

  // Method to call our newly created EVENT:
  async prepareCachesForUpdate() {
    return (await SWHelper.getWaitingWorker())?.postMessage({ type: 'PREPARE_CACHES_FOR_UPDATE' });
  },
};

function registerValidSW(swUrl, config) {
  navigator.serviceWorker
    .register(swUrl)
    .then(registration => {
      if (registration.waiting && registration.active) {
        window.swNeedUpdate = true;
      }
      registration.onupdatefound = () => {
        const installingWorker = registration.installing;
        if (installingWorker == null) {
          return;
        }
        installingWorker.onstatechange = () => {
          if (installingWorker.state === 'installed') {
            if (navigator.serviceWorker.controller) {
              window.swNeedUpdate = true;
              // WE FIRE THE EVENT HERE:
              SWHelper.prepareCachesForUpdate().then();
              if (config && config.onUpdate) {
                config.onUpdate(registration);
              }
            } else {
              //...
              if (config && config.onSuccess) {
                config.onSuccess(registration);
              }
            }
          }
        };
      };
    })
  //...

One more thing – when the new service worker get activated, we surely don’t need any more the old cache. To clean it up we simply follow this documentation:

`service-worker.js`



self.addEventListener('activate', event => {
  event.waitUntil(
    getCacheStorageNames()
      .then(
        ({ outdatedCacheNames }) => outdatedCacheNames.map(cacheName => caches.delete(cacheName)),
      ),
  );
});

Well that’s it, we covered all the cases, we solved all the problems, and we have a flawless service worker update. Now, when the user has a service worker the following will happen:

⚡ When the user refresh/close the page and there are no other tabs handled by the same service worker, or when the user closes all the browser, the new service worker will be activated. And this will happen for sure sooner or later.
⚡ If there are other open tabs, on refreshing one of them, the user will already see the new content, EVEN BEFORE the new service worker is activated.
⚡ The user will experience no popup, no reload and no errors while operating the App

Isn’t it great?

You can see an whole example project here:

https://github.com/a-tonchev/react-boilerplate

The Service Worker
The Registration File
The SWHelper

Best wishes,
ANTON TONCHEV
Co-Founder & Developer of JUST-SELL.online