DEV Community: Chris How

Some notes on SharedWorkers

Chris How — Sun, 03 Nov 2024 09:01:36 +0000

I recently needed to implement a shared worker in a project. Though they are super useful, there wasn't much info to be found in the usual places, so here are some pointers that might help searchers from the mysterious future.

Background

SharedWorkers are a special class of WebWorker that can be shared across multiple tabs, windows or other (regular) web workers.

In my application, I needed a process which would poll for new application events (for example, a customer completing a purchase), and show a notification (using the Notifications API) to logged in administrators (or more specifically, those logged in administrators who had chosen to receive notifications).

An administrator could have the application open in several tabs or windows, so it would be wasteful to have each tab polling for new events. I only wanted one notification per event, regardless of the number of open tabs or windows.

SharedWorker to the rescue! Each of the open tabs or windows shares a single worker, which polls in the background, and shows just one notification per new event.

Creating a shared worker with Vite

The first challenge was loading the shared worker in my Vite-based setup.

If you're running Vite in dev mode, Vite serves the script from a different domain and port (eg http://[::1]:5173/), which won't work, because shared workers must obey the same-origin policy.

I tried various Vite workarounds for web workers:

The official Vite web worker method doesn’t work for shared workers due to the same-origin policy requirement.
Blob URLs aren't supported for shared workers.
Inlining the worker as a base64 string doesn’t work because the browser treats them as different workers: fine for web workers, but not for shared workers.

In the end, I created a new route to serve the script either from the resources directory in dev, or the build directory in staging and live environments.

Route::addRoute('GET', '/notifications-shared-worker.js', function () {
    // If in dev environment, send the file from the resources folder
    if (app()->environment('local')) {
        return response()->file(resource_path('js/notificationWatcherWorker.js'), ['Content-Type' => 'text/javascript']);
    } else {
        // Otherwise, send the file from the public folder
        return response()->file(public_path('build/assets/notificationWatcherWorker.js'), ['Content-Type' => 'text/javascript']);
    }
});

I then create the shared worker with that route as the URL:

const worker = new SharedWorker('/notifications-shared-worker.js');

Debugging the Shared Worker

You'll quickly find that any syntax or runtime errors in your shared worker don't appear in your devtools. Nor do any console log/warn/info calls.

This one is easy, paste chrome://inspect/#workers into your URL bar, find the shared worker and click on 'inspect'. Now you have a devtools window just for the shared worker.

Communicating back to the main tab or window

To communicate back to the ‘parent’ tab, use the port.postMessage method, as described in the MDN SharedWorker documentation.

However, the example code only allows communication with the most recent ‘parent’ tab/window because it overwrites the communication port reference each time a parent connects.

Instead, store an array of ports, and add each new port to the array when a new ‘parent’ connects.


const ports = [];

onconnect = (e) => {
    // Get the port for this new connection
    const port = e.ports[0];
    // Add it to our array of ports
    ports.push(port);
...
}

Then, send a message to all the parent pages like this:

ports.forEach(port => port.postMessage({ 
    message: "Hello, world!", 
    flavor: "vanilla" 
}));

SQLite, case sensitivity, and Laravel testing

Chris How — Thu, 21 Dec 2023 13:01:43 +0000

Imagine you have a bunch of records like this:

$cars = [
  [
    'model' => 'Countach',
    'registration' => '7075GHX'
  ],
  [
    'model' => 'Mini',
    'registration' => '9643tls'
  ],
  [
    'model' => 'Mustang',
    'registration' => '8862MBA'
  ]
];

Your user can search for cars by registration. It doesn't matter whether they search for 8862MBA or 8862mba, they're going to find the Mustang, right?

Yes, that's right. In MySQL, and in MSSQL at least. But then, when you write your tests, you find that you don't necessarily find the Mustang. Because you're using SQLite as your testing database, and SQLite uses case-sensitive matches.

You may have already found that the 'where' filter in Laravel collections is case-sensitive, so though you can query the database successfully in a case-insensitive manner, you can't then filter the resulting collection the same way (though here's a simple Collection macro that provides case-insensitive filtering).

So you're left with the icky situation that a where in an Eloquent query works differently to a where in a Collection, except where it doesn't.

So I guess you can try remember to/get your team to always remember to change the case of this kind of supplied data before storing it in the database (😂) or get them to use raw SQL in where clauses (eg ->whereRaw('UPPER(REGISTRATION) = ?', strtoupper($registration)) 💀).

SQlite supports a collate clause in its CREATE TABLE syntax, but this isn't supported in Laravel's Database schema driver for SQLite.

If there is any interest, I may look into implementing it.

A better way to build autoplaying feature videos.

Chris How — Sun, 22 Oct 2023 10:02:57 +0000

As part of the team working the website for self-driving AI company Wayve, we needed a neat way to present an auto-playing video that:

Retained interactivity without asking much of the user
Started playing at the right time so the user didn't miss the beginning
Was a bit "stickier" than just a straight-up embedded video would be.

So we implemented an auto-playing "zoom-on-scroll" element.

Notice how the video of the London street scene automatically zooms to fill the window and starts playing when scrolled into view:

The video also sticks around a while as you scroll, drawing the user's attention to it. It's not a massive drag to get past it; you don't have to click anything to dismiss it. You just scroll a bit further and the video "un-zooms" and stops playing.

I've seen similar effects on other sites, but given that we were in a post-Internet Explorer world, I had an opportunity to implement it using modern techniques, leading to less jank, less code, and smoother animations.

So let's have a look at the steps needed to implement such a feature.

Step 1: Has the user scrolled the video into view?

The first step is to know when the user scrolls the video element into the viewport.

In the bad old days, we would calculate the vertical position of the video element, keep track of how far down the user has scrolled the page by trapping the scroll event, working out whether our video element was inside the viewport, and recalculate everything when the window was resized, or dynamic elements were added or removed from the page.

But now we can use the Intersection Observer API, which has been available on all modern browsers since 2019.

Here is an example of this pattern in use:

Stepping through this example, we first set the options for the observer. We're only interested in the threshold option: how much of the element must be inside the viewport for the observer to consider the element as inside.

We're going to plump for 1: consider the element to be 'inside the viewport' when 100% of it is inside the viewport (as opposed to — say — 75%).

const options = {
  threshold: 1 // 100% of element is in viewport
};

Next we're going to add the callback for the intersection observer: what to do when an intersection change is observed.

const callback = (entries) => {
  entries.forEach(entry => {
    // Add class 'in-view' to element if
    // it is within the viewport
    entry.target.classList.toggle('in-view', entry.intersectionRatio === 1);
    });
};

Next we are going to create an intersection observer with those options and that callback action:

const observer = new IntersectionObserver(callback, options);

Note that this observer can observe any number of video elements, there's no need to create an observer for each element you want to observe; you can simply attach the same observer to as many video elements as you like.

Here we're just going to attach it to one element for simplicity, the element with the id observed:

observer.observe(document.getElementById('observed'));

Step 2: Start the video playing

Now we want to automatically start and stop the video as the user scrolls it into view.

This is especially handy where you want a video to play without requiring the user to do anything onerous, but you don't want to start autoplaying when the page loads, as the user would miss the start of the video (it's below 'the fold'!)

So we're going to tweak the callback that's supplied to the Insersection Observer:

const callback = (entries) => {
  entries.forEach(entry => {
    // Find the video element inside this container
    const videoElement = entry.target.getElementsByTagName('video')[0];

    const isWithinViewport = entry.intersectionRatio === 1;

    // Add class 'in-view' to element if
    // it is within the viewport
    entry.target.classList.toggle('in-view', isWithinViewport);


    if(isWithinViewport) {
      // Play the video if it's within the viewport      
      videoElement.play();
    } else {
      // Pause the video if not
      videoElement.pause();
    }
    });
};

Step 3: Zoom the video

This is going to be a CSS-only solution: super fast and jank-free.

What we're going to do is to use sticky positioning on the video container element, and it with in an element which is taller than the viewport height.

If we make the wrapper twice the viewport height, you will have to scroll two 'pages worth' to get past the video.

So the wrapper will have the following style:

.observed-wrapper {
  height: 200vh; /* 200% viewport height */
}

Then we're going add some rules for the video container, and override the margin when the video container element has the 'in-view' class:

.observed {
  position: sticky;
  top: 0px;
  height: 100vh;

  margin-left: 5rem;
  margin-right: 5rem;

  transition: all 0.2s; /* Use CSS transitions to animate */
}

/* When video is 'in view' */
.observed.in-view {
  margin: 0; /* Remove the side margins */
}

And a similar deal for the video element:

video {
    position: absolute;
    top: 3em; /* top spacing */
    left: 0;
    width: 100%;
    height: calc(100% - 6em); /* bottom spacing */
    object-fit: cover;
    transition: all 0.2s; /* Use CSS transitions to animate */
}

/* When video is 'in view' */
.observed.in-view video {
    /* No top spacing, and fill viewport */
    top: 0; 
    height: 100%;
}

Here's how that looks in action:

And there you go: fast, jank-free, with butter-smooth transition animations.

You can play with the real thing on the Wayve homepage.