Forem: Marsel Akhmetshin

Storybook: Stories for Smart Components

Marsel Akhmetshin — Thu, 15 Aug 2024 20:42:26 +0000

Note: This article is intended for advanced users familiar with Storybook. I will explain how to create Storybook stories for complex and feature-rich components.

Motivation

The ideal Storybook stories for components are those built around “dumb” components, where you can control the props (properties) through the Storybook interface. This approach works well for component libraries, but what if we need to create a Storybook story for a component that is integrated with application state, fetches data from a router, makes backend requests, and supports multiple languages? At first glance, it might seem impossible to fit such a component into Storybook, but what if I told you that it’s actually very much achievable?

Decorators and Addons Mechanism

Before we dive in, let’s take a look at two Storybook mechanisms that help extend its capabilities.

Decorators
Decorators are simple functions that take a Story as input, meaning the component we want to display in Storybook, and return a modified version of that Story. Inside a decorator, we are expected to make the necessary modifications to the Story and return the result of these changes. If a side effect needs to be executed, the decorator can simply return the original Story that was passed in.

Let’s take a closer look at the decorator below:

// decorators.js
import React from 'react';

export const withBackground = (Story) => (
  <div style={{ padding: '20px', backgroundColor: '#f0f0f0' }}>
    <Story />
  </div>
);

Here we can wrap our story in a div with padding: 20px and backgroundColor: #f0f0f0. This will affect the display of our components wrapped in this decorator in Storybook.

Now, let’s see how it can be applied to our story:

import React from 'react';
import { withBackground } from './decorators';
import { Button } from './Button';

export default {
  title: 'Example/Button',
  component: Button,
  decorators: [withBackground]
};

To apply the decorator specifically to our Button component, we pass our withBackground decorator, which we defined earlier, to the decorators property in its story description.

As a result, when rendering our Button in Storybook, our component will have padding and a background as well.

Earlier, I mentioned "specifically for our component". The fact is that decorators can be both personal and global. This means that we can apply a decorator to all our stories in Storybook.

Let’s look at how we can do this:

//.storybook/preview.js
import React from 'react';
import { withBackground } from './decorators';

const previewConfig = {
  //...
  decorators: [withBackground],
  //...
};

export default previewConfig;

It's pretty simple: open the .storybook/preview.js file and add our withBackground decorator function to the decorators property in the Storybook configuration. After this, all components will automatically be wrapped in this decorator, adding padding and a background.

Addons
Addons in Storybook are extensions that add extra functions and capabilities for working with components in Storybook. They enhance the development and testing process by offering tools for interaction, customization, and visualization of components.
Later in this article, we will look at the main addons that help us display our smart components in Storybook, as well as how to configure them. There is no universal way to configure all addons, so I will explain how to do this using specific addon examples.

Integration of a Story with the Application Store: An Example with Redux

Let’s explore how we can set up state management around our Story using Redux as an example. The decorator mechanism will help us achieve this. Let’s go through it step by step.

Step 1: Define a Simple Reducer

const reducer = (state = {}, action) => {
  switch (action.type) {
    case 'INITIALIZE_STATE':
      return { ...state, ...action.payload };
    default:
      return state;
  }
}

This is straightforward: we handle an action with the type INITIALIZE_STATE and merge its payload with our current state.

Step 2: Create a Decorator to Wrap the Story with a Redux Context

Next, let’s create a decorator that will wrap our Story in a context and also initialize the state for our component:

import React from 'react';
import { Provider } from 'react-redux';
import { createStore } from 'redux';

export const withReduxState = (initialState) => (Story) => {
  const store = createStore(reducer);

  useEffect(() => {
    store.dispatch({ type: 'INITIALIZE_STATE', payload: initialState });
  }, [initialState]);

  return (
    <Provider store={store}>
      <Story />
    </Provider>
  );
};

Here’s what’s happening:

We create our Redux store using the reducer defined earlier.
We then initialize the store with some initial data using store.dispatch and the INITIALIZE_STATE action.
Finally, we wrap our component (Story) with the Redux Provider, passing the store as a prop to ensure the component has access to the Redux state.

Step 3: Apply the Decorator in a Story Component

Now, let’s see how we can apply this decorator in a story for a component:

// Button.stories.js
import React from 'react';
import { withReduxState } from './decorators';
import { Button } from './Button';

export default {
  title: 'Example/Button',
  component: Button,
  decorators: [withReduxState(initialState)]
};

This is similar to the example with the background decorator, but with one key difference: withReduxState is a function that returns a decorator with initialState in its scope. This approach is especially useful when you want to create different stories for a single component in various states.

In this example, we’ve demonstrated how to use decorators to integrate the Redux state manager into Storybook. I’m confident that a similar approach can be successfully applied with other state managers, allowing you to easily manage the state of components in various scenarios.

Integration of a Story with React Router

Now let’s consider a situation where the behavior of a component depends on the current URL in the browser's address bar. For example, the component should be displayed in red at location /path1 and in green at location /path2. How can we implement such behavior in Storybook? The storybook-addon-remix-react-router addon will help us achieve this.

Setting Up the Plugin in the Project
First, let’s enable the plugin in our Storybook configuration:

// .storybook/main.ts
export default {
   //...
  addons: ['storybook-addon-remix-react-router'],
  //...
}

To do this, add the name of the addon to the addons property in the .storybook/main.ts file.

Configuring the Plugin in a Story

Now, let’s move on to our UserProfiles.stories.js file and set up virtual routing for our component:

import { withRouter, reactRouterParameters } from 'storybook-addon-remix-react-router';

export default {
  title: 'User Profile',
  component: UserProfile,
  decorators: [withRouter],
  parameters: {
    reactRouter: reactRouterParameters({
      location: {
        pathParams: { userId: '42' },
      },
      routing: { path: '/users/:userId' },
    }),
  },
};

To create a router context around our component, we need to export the component and wrap it in the withRouter decorator. Then, in the story’s configuration, we need to pass the router settings to the parameters property.

It’s important to note that parameters is an object where properties are passed to the addon. Each addon has its own parameter key for accessing its settings, and in our case, it’s parameters.reactRouter.

Let’s take a closer look at the reactRouter settings:

  //...
  parameters: {
    reactRouter: reactRouterParameters({
      location: {
        pathParams: { userId: '42' },
      },
      routing: { path: '/users/:userId' },
    }),
  },
  //...

Using reactRouterParameters({...}), we created a configuration and added the following parameters:

location.pathParams.userId — This describes the current location where the component is situated. When the component accesses the router and tries to get the userId parameter, it will receive the value 42.
routing.path — This describes the virtual route where our component is located. In the browser, one location will be displayed, but the component will behave as if it is on the route /users/:userId. This allows us to add virtual routes for components whose visual representation depends on routing.

Enabling the Router Globally
We’ve covered setting up a virtual router for a specific component and an individual story. But what if we want to set up a virtual router globally for all stories? This is also possible — just navigate to the .storybook/preview.js file and configure it similarly.

// .storybook/preview.js
export default {
  decorators: [withRouter],
  parameters: {
    reactRouter: reactRouterParameters({ ... }),
  }
}

The principle is the same as in the story settings: define the reactRouter parameter and pass the router configuration to reactRouterParameters({ /* ... */ }).

An attentive reader might ask: why add a new plugin when you could simply implement a decorator that wraps the story in a router? Indeed, that could be done, but there are two advantages to using the plugin.

First, installing the plugin is much faster and simpler than developing your own solution. Second, plugins have an important advantage — they can integrate into the Storybook interface, making them particularly convenient to use:

The storybook-addon-remix-react-router plugin adds a tab to the Storybook interface where you can see navigation events and the current route of your component.

In this section, we’ve thoroughly covered how to configure a story using virtual routing for your component. This allows you to easily test components that depend on routes. If you want to learn more about the features and settings of this addon, we recommend checking out the detailed documentation available at the following link: storybook-addon-remix-react-router.

Request Mocking

In this section, we will explore how to intercept requests in component stories and respond with the desired data. For this, we'll use the msw-storybook-addon.

Setup
The first thing we need to do is run the following command:

npx msw init public/

Why is this necessary? This command will create a public folder and place a Service Worker there, which will be used to intercept requests.
After loading the Service Worker, you need to configure it to run in Storybook globally. To do this, open the .storybook/preview.js file and follow these steps:

import { initialize, mswLoader } from 'msw-storybook-addon'

initialize()

const preview = {
    //...
  loaders: [mswLoader],
}

export default preview

The initialize function sets up and starts the Service Worker, while mswLoader acts as a loader that waits for the Service Worker to be ready and then applies the request handlers, which we’ll discuss shortly..

💡 Note: .storybook/preview.js is a global config applied to each story individually. This means the config is applied from scratch each time a story is opened.

Now that we’ve configured our addon, let's enable it inside a story:

import { http, HttpResponse } from 'msw'
import { Profile } from './profile'

export const SuccessBehavior = {
    component: Profile
  parameters: {
    msw: {
      handlers: [
        http.get('/user', () => {
          return HttpResponse.json({
            firstName: 'Neil',
            lastName: 'Maverick',
          })
        }),
      ],
    },
  },
}

As mentioned before, each addon has its own parameter through which settings are passed. For msw-storybook-addon, this parameter is parameters.msw. Inside this parameter, you need to specify handlers, which act as request interceptors.
In our example, we intercept a GET request to the /user URL and return a response in JSON format. Similarly, you can handle other types of requests, such as POST, return only an HTTP status, or even simulate a response delay of several seconds.

💡 Note: The msw-storybook-addon is a wrapper around the mswjs library. You can learn more about the capabilities of mswjs here: MSW Documentation.

In this section, we thoroughly explored how to set up request interception in Storybook for your stories using the msw-storybook-addon. This addon allows you to create realistic scenarios for component interactions with APIs, making the testing and development process more efficient. You can configure request handlers for various types of HTTP requests, simulate server responses, and even model response delays. This is particularly useful for testing component behavior under different conditions. For more detailed information and full documentation on this addon, you can visit: msw-storybook-addon.

Switching Story Languages from the Storybook Interface

We’ve already covered the main addons; now let's look at a scenario where you need to switch the component's language directly in the Storybook interface. This method is excellent for most client-side translation solutions.

The first thing we need to do is define our new language switcher, which will be available in the Storybook interface:

export const preview = {
  // ...
  globalTypes: {
    locale: {
      name: "Locale",
      description: "Language",
      toolbar: {
        icon: "globe",
        items: [
          { value: "en", title: "English" },
          { value: "fr", title: "French" },
        ],
      },
    },
  },
  //...
};

Let's break down what's happening here:

First, we define a new global variable locale in the globalTypes section.
Second, we configure its display settings.

This configuration includes a toolbar, meaning that the switcher will be displayed in the Storybook toolbar. We also specified that the switcher's icon is a globe, and added a list of languages to which the component's story can be switched.
This is what it will look like:

Now that we’ve set up the switcher in the Storybook interface, let's see how to make the component respond to language changes. A decorator mechanism will help us with this:

const langDecorator = (Story, context) => {
  const locale = context.globals.locale;

  useEffect(() => {
    i18n.changeLanguage(locale);
  }, [locale]);

  return <Story />;
};

Note the second parameter of the decorator function — context. It allows us to access the global variable globals.locale, which stores the currently selected language. We then use this value to pass it, as shown in the example, to i18n or any other translation library to update the interface language.

In this section, we thoroughly explored how to extend the functionality of the Storybook interface by adding support for language switching in components. This approach makes it easy to test and showcase multilingual components by switching languages directly from the Storybook interface. Such a setup makes the development and testing process more convenient and flexible, especially if your project supports multiple languages.

Bonus: Module Federation Support in Storybook

It's hard to imagine a situation where you need to render micro frontends in Storybook, but I will still tell you about an addon that adds such support. This is an excellent example of how powerful addons can be and how they enable even the most atypical tasks in Storybook.
Enabling Module Federation support is quite simple. To do this, you need to install the @module-federation/storybook-addon. Let's start configuring it:

// .storybook/main.ts
export default {
  //...
  addons: [
    {
      name: "@module-federation/storybook-addon",
      options: {
        moduleFederationConfig: moduleFederationConfig(),
      },
    },
  ],
  //...
};

Connecting the addon for Module Federation support is really simple. The moduleFederationConfig needs to be the same configuration used in your webpack config. You can learn more about Module Federation here: Webpack Module Federation.
Documentation and the plugin itself can be found at the following address: @module-federation/storybook-addon.

💡 Note: It may be obvious, but I must mention that for this plugin to work, Storybook needs to be built using webpack.

Conclusion

In this article, I demonstrated how advanced methods can be used to work with more complex components in Storybook that are integrated with application state, routing, and APIs. I explained how decorators and addons help adapt Storybook for testing such components. We covered examples of integration with Redux and React Router, as well as request mocking and language switching. Additionally, I touched on the possibility of supporting micro frontends with Module Federation. In the end, Storybook proves to be a powerful tool that can be configured for a wide range of use cases, making the development and testing process more flexible and efficient.

🧠 Unraveling Macrotasks and Microtasks in JavaScript: What Every Web Developer Should Know 💯

Marsel Akhmetshin — Wed, 24 Apr 2024 18:41:28 +0000

Event Loop

Let's remember how the web browser event loop works. Event Loop consists of three main components:

JavaScript engine – a component that executes JavaScript code and provides access to the Web API
Web APIs – browser interfaces such as fetch, timers, and other functions
Event queue – a data structure that accumulates UI events and Web API-initiated events, such as fetch execution results

It goes like this:

Code Execution: First of all, the synchronous code on the call stack is executed until the Stack is emptied
Event Queue Checks: After the call stack is emptied, Event Loop checks the event queue. For example, fetch has ended or we have subscribed to some UI Event like click, and this event was discarded
**Pushing Events onto the Stack: **If there are pending tasks in the Event Queue, Event Loop pushes them onto the call stack for execution
Repetition: This process continues in a loop, processing events and executing asynchronous tasks To better understand how it works, let's look at the diagram below:

First, we execute the fetch request
This task is moved from the stack to the Web API
Next, the browser executes the request and returns the execution results to the queue, in some of its internal representation
Next, the Event Loop places the fetch results on the stack, where it is processed by the JS engine

💡Please note that Event Loop is not part of the JavaScript engine

Microtasks and Macrotasks

Before we look at the code examples, let’s define clearly what we mean by microtasks and macrotasks:

Microtasks are deferred tasks that have a higher priority than macrotasks. Examples of microtasks are:
- Operations with promises (e.g., Promise.then(), Promise.catch(), fetch, etc.)
- Mutation queue operations (e.g., the ones used in the MutationObserver API to observe DOM changes)
- Operations associated with queueMicrotask() – a function for explicitly adding microtasks
Macrotasks are deferred tasks with lower priority than microtasks, e.g.:
- Timers handling (setTimeout, setInterval)
- User input events handling (e.g., clicks, scrolling)
- AJAX requests execution

Asynchronicity in the Web Browser

Let's look at the two types of asynchronous behavior available in a web browser:

WebAPI asynchrony. Let's look at how fetch will work. We execute a fetch request, or rather the JS engine executes it; then the request is passed to the Web API side, while the main browser thread continues to work. After the fetch request is finished, the Web API returns the execution results to the queue, and then these execution results will be picked up by EventLoop and processed by the JS engine.
Asynchrony of JS code (pseudo asynchrony). What do you think will happen if we take a function that loops from 0 to 1,000,000,000, and then wrap it in a promise? That’s right, this will make the browser freeze. Why? The thing is, by wrapping the code in a promise, we are only asking the browser to postpone the execution of this code until the browser’s queue is processed. Wrapping synchronous code in a Promise or running it through queueMicrotask only puts our code almost at the end of the queue. Why almost? We'll examine this further below. > 💡Is there a way to execute JS code asynchronously and in a separate browser thread? Yes, it is possible with the use of the Web Worker API. You can read about them here:

Web Workers: Revolutionizing Web Performance and User Experience

Marsel Akhmetshin
Marsel Akhmetshin

Marsel Akhmetshin

Follow

Mar 14 '24

Web Workers: Revolutionizing Web Performance and User Experience

#webworkers #sharedworkers #webdev #frontend

47 reactions
Comments 1 comment

5 min read

An Example with Macrotasks

Macrotasks are tasks like timers (setTimeout, setInterval) and they are scheduled to run consecutively.

console.log('Start');

setTimeout(() => {
  console.log('Macrotask completed');
}, 0);

console.log('End');

In this example, the output order will be as follows:

Start
End
Macrotask completed Even if setTimeout has a delay of 0 milliseconds, its callback will not be executed immediately but will be scheduled as a macrotask and executed at the end of the execution priority.

An Example with Microtasks

Microtasks include, among others, Promises and handlers associated with them.

console.log('Start');

Promise.resolve().then(() => {
  console.log('Microtask completed');
});

console.log('End');

In this case, the execution order will look like this:

Start
End
Microtask completed

Since microtasks have higher priority than macrotasks, the Promise callback is executed immediately after the current execution loop completes, but before the next event loop, even if there are already macrotasks in the Event Loop.

Combined Example: Microtask + Macrotask

Let's now take a look at a combined example that includes both microtasks and macrotasks:

console.log('Start');

setTimeout(() => {
  console.log('Macrotask completed');
}, 0);

Promise.resolve().then(() => {
  console.log('Microtask completed');
});

Promise.resolve().then(() => {
  console.log('Microtask 2 completed');
});

console.log('End');

The execution order will be as follows:

Start
End
Microtask completed
Microtask 2 completed
Macrotask completed

This example shows that microtasks (here, promises) are executed before macrotasks (here, timers), even if they were scheduled later in the code. This highlights their priority in the Event Loop.

💡 Note the order of priority: first, all microtasks will be executed, and only then the macrotask will be taken for execution.

An Example with Page Rendering

When I wrote that the one macrotask is executed after all the microtasks, I simplified things a bit. In reality, page rendering may occur after the microtasks are executed. If you use requestAnimationFrame, these calls can be executed before the macrotask execution begins. The browser tries to insert requestAnimationFrame into the nearest rendering. All calls to requestAnimationFrame try to happen approximately every 16.67 ms, but strictly after all microtasks are executed. Let's look at the example below:

console.log('Synchronized start');

//A macrotask with setTimeout
setTimeout(() => {
  console.log('Macrotask 1: setTimeout');
}, 0);

//A macrotask with setTimeout
setTimeout(() => {
  console.log('Macrotask 2: setTimeout');
}, 0);

//A microtask with Promise
Promise.resolve()
   .then(() => {
     console.log('Microtask 1: first promise completed');
   });
   .then(() => {
     console.log('Microtask 2: second promise completed');
   });

//First requestAnimationFrame to update animation
requestAnimationFrame(() => {
  console.log('First requestAnimationFrame: animation update');
});

//Second requestAnimationFrame to update animation
requestAnimationFrame(() => {
  console.log('Second requestAnimationFrame: animation update');
});

console.log('Synchronized end');

The output order will be as follows:

Synchronized start
Synchronized end
Microtask 1: first promise completed
Microtask 2: second promise completed
First requestAnimationFrame: animation update
Second requestAnimationFrame: animation update
Macrotask 1: setTimeout
Macrotask 2: setTimeout

We were lucky, and the rAF calls were completed before the macrotasks. If we run this code again, the order of rAF and microtasks may get swapped.

Example with a Macrotask Calling a Microtask

console.log('Script start');

setTimeout(() => {
  console.log('Macrotask: setTimeout');

  //A microtask created inside a macrotask
  Promise.resolve().then(() => {
       console.log('Microtask: processing a promise inside setTimeout');
  });
}, 0);

Promise.resolve().then(() => {
  console.log('Microtask: processing the first promise');
});

console.log('End of script');

The output order will be as follows:

Script start
End of script
Microtask: processing the first promise
Macrotask: setTimeout
Microtask: processing a promise inside setTimeout

Here it is worth noting the situation when a microtask is created inside a macrotask. Until the macrotask executes its callback, the browser won’t know there is a microtask inside of it.

Event Loop Contexts

In this part, I want to focus your attention on isolated contexts with their own event loops:

Web browser main context
Iframe
Web Worker Each of these elements has its own unique event loop that does not overlap with the others. With Web Workers, everything is quite straightforward: a task is sent to the worker and is processed independently of the main browser thread.

With Iframe, the situation is a little more complicated. Although Iframe has its own event loop, it does not have a separate thread of execution. This does not mean, however, that a costly task in the Iframe will cause the main browser tab to freeze; only the iframe will freeze, and the main tab will continue to work even though the browser will notify the user that something is stuck.

The Philosophy of Microtasks and Macrotasks

Until 2015, the standard did not include microtasks, and until 2014, it did not include Web Workers. And requestAnimationFrame appeared only in 2011. Developers had to be content with the asynchrony based on macrotasks or Timer API. Considering all this, macrotasks were and still are a powerful tool.

The overall setup is this: no macrotasks, no rAFs, no Web Workers, and no party. Imagine that you need to calculate something complex on the client, or you want to do custom animations that cannot be done through CSS, and you need to do it in such a way that the browser window is not blocked yet the task is completed. The browser has no multi-threading, we only have a single-threaded EventLoop. How should we deal with such a situation? We break the task into several subtasks and execute them one by one, gradually freeing up the process for rendering, events, and queries.

Let's look at an example:

function processArrayInChunks(array, chunkProcessingTime) {
    let index = 0;
    const startTime = Date.now();

    function processChunk() {
        const chunkStartTime = Date.now();

        while (index < array.length && (Date.now() - chunkStartTime < chunkProcessingTime)) {
            // A processing example: increase each element of the array by 1
            array[index] += 1;
            index++;
        }

        if (index < array.length) {
            console.log(`Processed ${index} elements so far...`);
            setTimeout(processChunk, 1000); // Schedule the next chunk immediately after the current one
        } else {
            console.log(`Completed processing ${array.length} elements in ${Date.now() - startTime} ms`);
        }
    }

    processChunk();
}

// Creating a large array
const largeArray = new Array(1000000).fill(0);

// We start processing the array, limiting the execution time of the subtask to 17 milliseconds
processArrayInChunks(largeArray, 17);

What do we have here?

processArrayInChunks gets the array and the processing time of each subtask. It initiates the process of dividing the task into parts.
processChunk is called recursively via setTimeout. It processes one part of the array at a time, limiting the execution time to a specified duration (chunkProcessingTime).
The loop exit condition is determined when the current index reaches the end of the array. Once completed, the total processing time is displayed.

💡 To slow down the execution of the task, we had to run setTimeout at intervals of a second.

Thanks to processing one macrotask at a time, we achieved background task execution that doesn’t block the page.

Absolutely the same logic applies to browser events. The developer subscribes to some event, and it is obvious it will change the DOM state; after the changes, the browser process will be freed (for example, rendering will occur), and then it will take the next macrotask.

💡 By the way, yes, browser UI events are also macrotasks.

To summarize the above: macrotasks are a powerful browser mechanism designed for the “manual” non-blocking execution of large tasks. And by “big,” I mean “take a large task and break it down into small subtasks.”

requestAnimationFrame

The standard is evolving, and now it includes requestAnimationFrame designed to optimize rendering and save developers from performing custom complex animations using the Timer API.
Its core idea is to ask the browser to schedule a visual change on the nearest frame. And not just one change, but all rAFs that can be executed in the next frame. Let's look at an example:

let lastTimestamp = Date.now();

function heavyTask() {
  const start = Date.now();

  const workloadPeriod = Math.random() * 10;

  while (Date.now() - start < workloadPeriod) {
    // Artificial loading
  }
  console.log("Heavy task is finished!");
}

let frame = 0;
const runFrame = () => {
  frame++;
  console.log("frame", frame, Date.now() - lastTimestamp);

  lastTimestamp = Date.now();

  if (frame < 10) {
    requestAnimationFrame(runFrame);
  }
};

requestAnimationFrame(runFrame);

for (let i = 0; i < 50; i++) {
  setTimeout(() => {
    requestAnimationFrame(() => {
      console.log("rAF from a macrotask", Date.now() - lastTimestamp);
    });
    heavyTask();
  }, 0);
}

Let's break down what this code does. We launch our rAF, which is not loaded in any way for the frame log. Ideally, it is expected to run every 17ms. Next, through the loop, we create 50 macrotasks that stop our event loop for 0 to 10ms. We also display the frame number in the console and track the difference with the previous frame. This example demonstrates how the browser schedules rAF execution.

Let's first clarify what this code does. We run our rAF, which is not loaded in any way for the frame log; ideally, it is expected to run every 17ms. Further in the loop, we create 50 macrotasks that stop our event loop from 0 to 10ms. We also display the frame number in the console and track the difference with the previous frame. We need this example to demonstrate how the browser schedules the execution of rAF.

In the browser console we will see something like this:

frame 1 - rAF was processed 2ms after the start of our code execution
Heavy task is finished! - 15 macro tasks completed
frame 2 - 104ms have passed since the last rAF
rAF from a macrotask - caused by 15 rAF with an interval of 0ms
Heavy task is finished!- 18 macro tasks completed
frame 3 - 105ms have passed since the last rAF
rAF from a macrotask - caused by 18 rAF with an interval of 0ms
Heavy task is finished! - 16 macro tasks completed
frame 4 - 102ms have passed since the last rAF
rAF from a macrotask - caused by 16 rAF with an interval of 0ms
Heavy task is finished! - 19 macro tasks completed
frame 5 - 102ms have passed since the last rAF
rAF from a macrotask - caused by 19 rAF with an interval of 0ms
Heavy task is finished! - 20 macro tasks completed
frame 6 - 104ms have passed since the last rAF
rAF from a macrotask - caused by 20 rAF with an interval of 0ms
Heavy task is finished! - 12 macro tasks completed
frame 7 - 64ms have passed since the last rAF
rAF from a macrotask - caused by 12 rAF with an interval of 0ms
frame 8 - 0ms has passed since the last rAF
frame 9 - 13ms have passed since the last rAF
frame 10 - 17ms have passed since the last rAF

Let me explain the console output a little. Each setTimeout calls a rAF and a heavy task blocking the event loop. Once the browser realizes that enough rAFs have been accumulated for rendering, it attempts to apply the changes that were requested via rAF from setTimeout. Judging by the log, the browser was able to execute 15-20 microtasks before executing rAF requests, and on average, the browser scheduled the accumulated rAF calls every 100ms.

What conclusion do we draw from this? First, the browser strives to execute rAFs in the next frame (meaning every 17ms), and secondly, we clearly see that the browser is trying to schedule as many tasks as possible before the next rAF call and tries to put as many rAF calls initiated by macrotasks as possible into one frame.

💡 Let me emphasize here that this example illustrates the basic aspects of browser interaction with requestAnimationFrame. In practical use, calls to requestAnimationFrame involve operations that affect the DOM and consume CPU resources. This may cause the browser to try to combine multiple changes into a single render cycle, but may also delay certain DOM changes until the next frame to optimize performance.

Microtasks

Further along the timeline, the standard incorporates microtasks designed to optimize the browser rendering process and collect the maximum number of application state changes that will subsequently affect the DOM, and only then perform rendering.

💡 The deal here is that the browser rendering process is a very expensive and complex operation. Browser developers optimize it as much as possible; for this, additional event loop actors appear in the standard, such as rAF and the concept of microtasks.

To prove that rendering will be completed after all macrotasks have been executed, let's run the code below:

Promise.resolve("Data loaded").then((message) => {
    console.log(message);
  requestAnimationFrame((timestamp) => {
    console.log('Animation for:',message, timestamp);
  });
});

Promise.resolve("Settings loaded").then((message) => {
    console.log(message);
  requestAnimationFrame((timestamp) => {
    console.log('Animation for:',message, timestamp);
  });
});

Promise.resolve("User data loaded").then((message) => {
  console.log(message);
  requestAnimationFrame((timestamp) => {
    console.log('Animation for:' ,message, timestamp);
  });
});

The output order will be as follows:

Data loaded
Settings loaded
User data loaded
Animation for: Data loaded 9516312.2
Animation for: Settings loaded 9516312.2
Animation for: User data loaded 9516312.2

As you can see, all rAF calls were executed after microtasks and also have the same timestamp. This tells us that in our case, the browser has scheduled the animation (the accompanying DOM changes) in the next page refresh cycle.

At the end of this block, I would like to once again highlight the differences between microtasks and macrotasks:

The browser executes all microtasks in a row and then proceeds to rendering and to macrotasks
Microtasks are executed without any delays, as, for example, can happen with the Timer API (minimum delay of 4ms)
Macrotasks are executed according to the following principle: one macrotask occupies the process, after which the event loop must be unlocked for other tasks, and only after that the next macrotask will be taken – in case there is one, naturally
Microtasks have a guaranteed order of execution. That is, if you decide to postpone some tasks using microtasks, they will be executed exactly in the order in which they were created. You might be wondering, what's with the fetch API? Fetch is a promise, which means it’s a microtask, which means it must be executed according to the order in which the microtasks are called! When you use fetch to make an HTTP request, it works asynchronously, returning a promise. This promise is not a microtask in itself, but it will be added to the microtask queue after the request completes (the result is received or else the request fails).

console.log('Script start');

// Asynchronous request via fetch
fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json())
  .then(data => {
    console.log('Data received:', data);
  })
  .catch(error => {
    console.error('Request error:', error);
  });

// Adding a microtask
queueMicrotask(() => {
    console.log('Executing microtask');
});

// Setting a timer with a delay of 0 milliseconds
setTimeout(() => {
    console.log('Executing macrotask (setTimeout)');
}, 0);

console.log('End of script');

Script start
End of script
Fetch call
Executing microtask (queueMicrotask)
Executing microtask (setTimeout)
Microtask then(response => response.json())
Microtask then(data => ...)
Miscotask catch(error => ...)

Here we can see that, even though fetch was called before the macrotask, the result of the request was processed after the macrotask was executed

Conclusion

In this article, we explored the differences between macrotasks and microtasks, and also touched a little on page rendering. Understanding the differences in tasks and their priorities helps developers create more performant, responsive, and reliable web apps, as well as effectively manage asynchronous operations and events.

🔓 Webauth Unlocked: An In-Depth Exploration of Advanced Authentication Solutions

Marsel Akhmetshin — Mon, 15 Apr 2024 21:09:55 +0000

Introduction

What is WebAuthn?

WebAuthn (short for Web Authentication) is an open web authentication standard developed by the World Wide Web Consortium in collaboration with the FIDO Alliance. This standard allows users to log on to websites and applications without using passwords, making the process more secure and easy. Instead of conventional authentication methods such as passwords or one-time codes sent via short messages or emails, WebAuthn uses biometric data (e.g., fingerprints or facial recognition), hardware security keys (e.g., USB tokens), or PIN codes.

How does it work?

The core principle behind WebAuthn is asymmetric cryptography and interaction between the user device, browser, and server. The authentication process using WebAuthn consists of two main steps: registration and authentication.

Registration

When a user registers on a website or application, a pair of keys is created: a public and a private. Here's how it works:

Registration request: As a user registers or adds a new authentication method, the website sends a request to the user’s browser asking it to initiate WebAuthn registration.
Key generation: A pair of unique keys (public and private) for this website or app is created on the user’s device. The private key stays securely stored on the device and never leaves it; the public key is meant to be sent to the server.
Registration with the server: The public key, along with some extra information such as authentication device data, is sent back to the server for registration. The private key remains on the user's device and is never shared.

Authentication

When a user logs on to the website or app, the authentication process is initiated:

Auth challenge: The server initiates authentication through the browser by sending a challenge to be signed with the user's private key.
User confirmation: To confirm authentication, the user must perform an action using their authentication device, e.g. entering a PIN code, using biometrics, or pressing a button on a hardware key.
Call signing: The authentication device creates a signature with the user's private key, based on the received call.
Signature verification: The signed response is then sent to the server where it is verified against the public key associated with the user account. Successful signature verification proves that it was generated with the correct private key stored on the user's device.

This process guarantees a high level of security since successful authentication requires the physical presence and action of the user on the device on which their private key is stored. Keys are associated with a specific website, which prevents them from being used on other resources if compromised.

Formats Description

Registration

A user opens our website and enters an email or another user ID into the input field, then presses ‘Register’; after that, we make a request where we send to the backend this email or another user ID that they entered. In the backend response, we receive the following data:

const publicKey = {
    challenge: new Uint8Array([117, 61, 252, 231, 191, 241, ...]),
    rp: { id: "acme.com", name: "ACME Corporation" },
    user: {
      id: new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26]),
      name: "jamiedoe",
      displayName: "Jamie Doe"
    },
    pubKeyCredParams: [ {type: "public-key", alg: -7} ],
  }

Let's look at the structure of our authorization data configuration:

challenge – a one-time token generated for our session by the backend. This token is necessary to prevent replay attacks or, in other words, to prevent attackers from intercepting our request and executing it again, pretending to be us. *rp – the relying party. The object contains:
- id – the relying party's domain; it cannot be different from the current page domain.
- name – a human-readable name of the relying party, e.g. a company name.
user – the object with user data:
- id – a unique ID generated for the user. It is not recommended to use email, login, and other identifiers that may be valid outside the service on which registration takes place.
- name – a human-readable account identifier; it can be email or login. Conventionally, there could be the line “marsel.akhmetshin@example.com (Some company)”
- displayName – a user-friendly account name, for example, username or surname: “Marsel Akhmetshin”. Designed to make it clear to the user what kind of account this is. Can be an empty string.
- pubKeyCredParams – an array of public key types and encryption algorithms supported by the server. The structure of an array element consists of two fields: type and alg, where type is always “public key”, and alg is one of the following values in this list, but it is recommended to use at least
  - 8 – (Ed25519)
  - 7 – (ES256)
  - 257 – (RS256)

Above, we broke down the minimum configuration for creating a valid user public key. Later in the article, we will look at additional fields.

💡 Please note that all configuration properties of the ArrayBuffer type are data in binary representation

Once we have created the public key on the client device, we send it to the backend. A little later we will look at how it is created on the client. The result will look like this:

PublicKeyCredential {
    id: 'ADSUllKQmbqdGtpu4sjseh4cg2TxSvrbcHDTBsv4NSSX9...',
    rawId: ArrayBuffer(59),
    response: AuthenticatorAttestationResponse {
        clientDataJSON: ArrayBuffer(121),
        attestationObject: ArrayBuffer(306),
    },
    type: 'public-key'
}

💡 Please note that the public key will be sent once and only upon registration.

Let's look at the structure of Credentials that will be sent to the backend:

id – this is the authorization data ID that will be transmitted to our service during authentication. Using this ID, we can match our authorization request with the public key on the backend.
rawId – the same as id, only in binary representation.
response
- clientDataJSON – JSON with client parameters.
  - type – a field that contains the line “webauthn.create”, which means that the user is being registered.
  - origin – a URL from which the user registration request was made. If the request was made from an iframe, then the iframe’s origin will be used.
  - challenge – one-time token preventing replay attacks.
- attestationObject – flags, authenticator certificate data, and the user’s public key, which will be needed to confirm the validity of the user’s signature during authorization. The data is transmitted in binary format CBOR (Concise Binary Object Representation). > 💡 Don't worry, we'll talk about flags and certificates later in this article.

Below is a diagram describing the registration process:

Source: https://w3c.github.io/webauthn/#sctn-usecase-registration

Authorization (authentication)

During authorization, the user enters a login, which is then sent to the server, and the server returns the credentialId for this login, if present. Next, on the client, we create a user signature request configuration for the previously registered public key:

const publicKeyCredentialRequestOptions = {
    challenge: Uint8Array.from(
        randomStringFromServer, c => c.charCodeAt(0))
}

Let's look at the structure of our configuration:

challenge – one-time token preventing replay attacks. Yes, only challenge is required, this is enough to start the authorization process.

Next, the following object will be sent to the backend:

PublicKeyCredential {
    id: 'ADSUllKQmbqdGtpu4sjseh4cg2TxSvrbcHDTBsv4NSSX9...',
    rawId: ArrayBuffer(59),
    response: AuthenticatorAssertionResponse {
        authenticatorData: ArrayBuffer(191),
        clientDataJSON: ArrayBuffer(118),
        signature: ArrayBuffer(70),
        userHandle: ArrayBuffer(10)
    },
    type: 'public-key'
}

What does it consist of:

id - the same as credentialId
rawId - the same as id only in binary representation
response
- authenticatorData contains rpID, flags, key usage counter (increases each time the key is used), and authenticator extensions.
- clientDataJSON - the same browser data as during registration: origin, challenge, and type – except that during authorization it contains the value “webauthn.get”
- signature – signature generated by the private key on the client/device side. It is needed to check whether it matches the public key.
- userHandle – an optional array that stores the user.id passed to the user object during registration.
type – always “public-key” Below is a diagram describing authorization: Source: https://w3c.github.io/webauthn/#sctn-usecase-registration
General Implementation

Registration

We've reviewed the formats, and now let's look at how registration and authentication are handled in code. Once we have received the configuration of our authorization credentials, we need to pass them to the navigator.credentials.create method

const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions
});

On the client we call navigator.credentials.create and we pass our credentials configuration to the publicKey property.

To check if the WebAuthn API is supported by the browser, you can access window and its PublicKeyCredential property, the value of which must not be undefined.
Next, having created our credentials, we must send them to the backend. On the backend we need to parse the received credentials:

First, we must perform a basic verification of the validity of the challenge – that it is relevant, the correctness of the domain from which the user creation request is being made, and at the very end, we must check if the request type is correct; in our case it is registration, and we expect that the type will be “webauthn.create"

// decode the clientDataJSON into a utf-8 string
const utf8Decoder = new TextDecoder('utf-8');
const decodedClientData = utf8Decoder.decode(
    credential.response.clientDataJSON)

// parse the string as an object
const clientDataObj = JSON.parse(decodedClientData);

console.log(clientDataObj)
/*
{
    challenge: "p5aV2uHXr0AOqUk7HQitvi-Ny1....",
    origin: "https://webauthn.guide",
    type: "webauthn.create"
}
*/

Example from https://webauthn.guide/

Next, we need to parse our attestationObject. The data is compressed in CBOR format, so we will need a CBOR decoder.

const decodedAttestationObj = CBOR.decode(
    credential.response.attestationObject);

console.log(decodedAttestationObject);
/*
{
    authData: Uint8Array(196),
    fmt: "fido-u2f",
    attStmt: {
        sig: Uint8Array(70),
        x5c: Array(1),
    },
}
*/

Example from https://webauthn.guide/

Of the attestationObject, we are most interested in the authData property; let's take a closer look at it. Below is a diagram of what contains authData: AuthData is a byte array containing the following data:
RP ID Hash: SHA-256 hash of the resource identifier (Relying Party ID, usually the domain) for which the key is created.
Flags: A byte indicating various attributes of the operation. We'll deal with this later.
Signature Counter: A 4-byte value that the authenticator increments by one each time it is used to generate a claim. This prevents replay attacks.
Attested Credential Data: This section is present if the AT flag is set. It contains the following elements:
- AAGUID (Authenticator Attestation GUID): A 16-byte identifier showing the authenticator model.
- L (key length): A 2-byte value indicating the length of the key following it.
- Key: The user's public key generated by the authenticator for this site. The key format depends on the cryptographic scheme used.

In this list, Attested Credential Data interests us the most. This is where our user’s public key is located, which must be kept on the backend.

Next, let's look at how we can extract this key:

const {authData} = decodedAttestationObject;

// get the length of the credential ID
const dataView = new DataView(
    new ArrayBuffer(2));
const idLenBytes = authData.slice(53, 55);

idLenBytes.forEach(
    (value, index) => dataView.setUint8(
        index, value));

const credentialIdLength = dataView.getUint16();

// get the credential ID
const credentialId = authData.slice(
    55, 55 + credentialIdLength);

// get the public key object
const publicKeyBytes = authData.slice(
    55 + credentialIdLength);

// the publicKeyBytes are encoded again as CBOR
const publicKeyObject = CBOR.decode(
    publicKeyBytes.buffer);

console.log(publicKeyObject)
/*
{
    1: 2,
    3: -7,
    -1: 1,
    -2: Uint8Array(32) ...
    -3: Uint8Array(32) ...
}
*/

Example from https://webauthn.guide

Below I describe in detail what is happening here, but there is no need to look into it too much since our main goal is to get the public key

So, what's happening in the code?

Extracting authData: The authData variable is obtained from the decoded attestation object, which is a byte array containing the authenticator data.
Obtaining Credential ID Length:
- A DataView is created on top of a new ArrayBuffer 2 bytes long. DataView is used to easily read and write typed data into ArrayBuffer.
- A 2-byte slice is extracted from authData, starting from the 53rd byte. The slice contains information about the length of the credential identifier.
- These bytes are written to the DataView, and then the length of the credential ID is obtained as a 16-bit unsigned integer (a value between 0 and 65,535) using getUint16.
Obtaining the Credential ID:
- Using the known length, the part containing the credential identifier itself is extracted from authData, starting from the 55th byte to 55 + credentialIdLength.
Obtaining the public key:
- The remainder of authData after the credential identifier is supposed to contain the public key, encoded using CBOR.
Decoding the public key:
- The resulting public key byte array (publicKeyBytes) is decoded from the CBOR format to obtain the public key object.
The public key object output:
- The console displays the public key object, where the keys denote the parameters of the key, for example, 1 for the key type, 3 for the algorithm, 1 for the curve (in the case of ECDSA), 2 and 3 for the X and Y coordinates of the public key in the case of ECDSA or the N and E components for RSA.

In the final output, publicKeyObject contains the decoded public key. Each key in the object denotes a specific public key attribute:

1 indicates the key type (for example, ECDSA),
3 denotes the encryption algorithm,
1 can indicate the elliptic curve used,
2 and 3 typically represent components of the public key, such as coordinates for ECDSA.

All that remains is to associate this credentialId, public key, with our internal userId and save it in the database.

Authorization

Now let’s talk about how authorization via WebAuthn is implemented.

It all starts with the backend sending us a challenge. This is the minimum set to obtain a signature and credentialId from the client and send it to the backend for authorization.

const publicKeyCredentialRequestOptions = {
    challenge: Uint8Array.from(
        randomStringFromServer, c => c.charCodeAt(0)),
}

const assertion = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions
});

To request authentication data from the user, we need to call navigator.credentials.get and pass our resulting publicKeyCredentialRequestOptions object there. Next, this assertion will need to be sent to the backend; it will contain the PublicKeyCredential (see the format description above).

On the backend, we need to get our signature from PublicKeyCredential. The signature is essentially proof that the device owns the private key.

An example of key decryption might look like this:

const storedCredential = await getCredentialFromDatabase(
    userHandle, credentialId);

const signedData = (
    authenticatorDataBytes +
    hashedClientDataJSON);

const signatureIsValid = storedCredential.publicKey.verify(
    signature, signedData);

if (signatureIsValid) {
    return "Hooray! The user is authenticated! 🎉";
} else {
    return "Verification failed. 😭"
}

What's going on here: First, we get the user's credentialId from the backend, and then we create signedData. To create signedData, first, we must hash our clientDataJSON using the SHA-256 algorithm and add it to authData. Next, we must take the resulting authData, signature, and public key and verify the signature.

Below is an example of solving the same problem using crypto in nodeJS:

const crypto = require('crypto');

// We assume that signature, signedData, and publicKey have already been received
// signature must be in Buffer format or string
// publicKey must be in a format suitable for use with the crypto module, such as PEM

const verifySignature = (publicKey, signature, signedData) => {
    const verifier = crypto.createVerify('SHA256');
    verifier.update(signedData);
    verifier.end();

    return verifier.verify(publicKey, signature);
};

const signatureIsValid = verifySignature(publicKey, signature, signedData);

if (signatureIsValid) {
    console.log("Signature is valid. User is authenticated.");
} else {
    console.log("Signature is invalid. Verification failed.");
}


} else {
    return "Verification failed. 😭"
}

💡 Please note that before checking the signature on the backend, we first need to make sure that the challenge is valid, the number of uses of this authorization data has increased, and the origin is correct and matches the domain from which we expect authorization and registration.

Additional Format Options

Registration

I already described the public key configuration format above in basic terms. Now, let's look at additional fields and public key configuration options:

const publicKey = {
    challenge: new Uint8Array([117, 61, 252, 231, 191, 241, ...]),
    rp: { id: "acme.com", name: "ACME Corporation" },
    user: {
      id: new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26]),
      name: "jamiedoe",
      displayName: "Jamie Doe"
    },
    pubKeyCredParams: [ {type: "public-key", alg: -7} ],

    // additional fields
    timeout: 60000,
    excludeCredentials: [{
        id:  new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26, 88]),
        type: "public-key",
    }],
    authenticatorSelection: {
           authenticatorAttachment: "platform" | "cross-platform",
               residentKey: "required" | "preferred" | "discouraged",
         userVerification = "required" | "preferred" | "discouraged"
    },
    attestation:"none" | "indirect" | "direct" | "enterprise"
    attestationFormats: []
  }

Now let's examine what these additional properties are and what they are needed for:

timeout is the time the device will wait for the user to respond, in milliseconds. If the user does not confirm registration/authorization within this time, the authorization and registration process will end with an error. It is also worth noting that for each authorization/registration attempt, you must generate a new challenge.
- excludeCredentials is an array of credentialIds. Needed to prevent re-registration of the user if the authenticator already contains a credentialId from the credentialId list for this user.id.
- authenticatorSelection – authenticator device settings:
- authenticatorAttachment - an authenticator type selector where:
  - platform means that the device authenticator (faceId or touchID) will be used or
  - cross-platform means that both the platform authenticator and, for example, YubiKey can be used.
- residentKey – a parameter responsible for whether the private key should be stored on the device or not. It has three possible values:
  - required – means the key must be stored on the device,
  - preferred – means that priority is given to storing the key on the device, but if this is not supported by the device, then it is also possible for the key not to be stored on it, and
  - discouraged – storing the key on the device is not required if possible and preference is given to keys stored not on the device if the device supports it.

💡 Simply put, in one case the authenticator device knows and stores the credentialId and the public key, while in the other case, both are provided by the server, and the device attempts to find a connected authenticator for this credentialId.

userVerification – this parameter determines how involved the user should be in authorization:
- required – authentication must be done with user verification. This means that the authentication device must require additional action from the user, such as entering a PIN, using biometrics (e.g. a fingerprint or facial recognition), or another method that verifies that the user is the actual owner of the device.
- preferred – the authenticator should verify the user if possible. In this case, if the device supports user verification, it will be used. If the device does not support sufficient verification methods, authentication can be performed without this step.
- discouraged - user verification is not required. The system may allow authentication without explicitly confirming the user's identity. This can be used in situations where user convenience is a priority or where a simplified login procedure is required. > 💡User verification is not required means that the user, for example, simply inserted a key/signature token without any passwords or biometrics.
attestation is a kind of root certification authority for the authenticator or data by which you can determine on the server how much you can trust the authenticator. Supports the following values:
- none – attestation type none means that no attestation data is provided. In other words, we don't want to validate the authenticator.
- indirect – with indirect attestation, the authentication device can use intermediate certificates to create a chain of trust back to the root certificate. This is a kind of anonymous certificate. For example, we trust the authenticator’s certificate, but we do not know what kind of device was used as an authenticator. In the case of FaceID, we will not know that it is FaceID, but we can look at the certificate confirming the authenticity of the device.
- direct – attestation means that the authentication device directly provides attestation data, including a certificate signed by the device's root certificate or enterprise certificate. In the case of FaceID, we will receive both a certificate confirming the authenticity of the device and the type of authenticator device itself.
- enterprise attestation allows organizations to use their own attestation methods that can be integrated into the enterprise security infrastructure.
- attestationFormats - the preferred certificate format that can be requested from the client, e.g., “apple” (faceId, touchId). The list is here.

Now let's look at the authorization configuration format:

const publicKeyCredentialRequestOptions = {
    challenge: Uint8Array.from(
        randomStringFromServer, c => c.charCodeAt(0)),

    // additional fields
    timeout: 600000,
    rpId: 'example.com'
    allowCredentials: [{
         id:  new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26, 88]), // credenitalId
         type: "public-key",
         transports: [ 
         "usb",
           "nfc",
       "ble",
       "smart-card",
       "hybrid",
       "internal"
       ]
    }]

}

The structure of the authorization configuration is much simpler than that of registration. We are already familiar with timeout, so let's take a closer look at rpId and allowCredentials.

rpId is a domain, needed to indicate to the client which domain the authorization is being performed for. For example, if it turns out that the domain where authorization is performed does not match rpId, then authorization will end with an error. If this parameter is not specified during authorization, the domain from the browser context or the current webpage’s domain will be substituted instead.
allowCredentials – here it is worth considering contexts. If the key is stored on the authenticator device (see the residentKey property) then allowCredentials is optional. However, if the authenticator does not store the key and credentialId, then allowCredentials are mandatory – otherwise, the client won’t be able to find the required authentication data.

Attestation object

In the context of WebAuthn, an attestation object is structured data generated by an authenticator during user registration. This object contains the information necessary to confirm the authenticity and reliability of the authentication device from the server side. Here are the key components of a certification object:

The fmt byte group in the WebAuthn attestation object denotes the Attestation Statement Format. This string value defines how the data in the attestation statement is structured and should be interpreted. Here are some standard attestation formats that can be specified in the fmt field:

packed is one of the most common attestation formats that supports both self-attestation and certification authority (CA) attestation. An attestation statement in this format contains a signature generated by the authentication device, covering the authentication data and the client data.
fido-u2f - this format is used by devices compatible with the FIDO Alliance U2F (Universal 2nd Factor). The attestation statement in U2F format contains a signature generated using the device's private key and an authentication device certificate.
tpm (Trusted Platform) - a format used for authentication devices that support TPM. The attestation statement for a TPM contains the signature generated by the TPM device, as well as information about the public key and certificate generated by the TPM.
android-key is an Android-specific format used when credentials are created and managed by the Android Keystore. The attestation statement contains a signature and certificate confirming that the key was generated and stored in the secure Android Keystore environment.
android-safetynet - this format uses Google SafetyNet services to confirm that the device and operating system are in a safe state. An attestation statement in this format includes a JWT signed by Google.
apple is an attestation format used in Apple devices. This format is often associated with the concept of privacy, where attestation data minimizes the amount of user and device information transmitted.
none - used when no attestation data is provided. This format may be chosen for scenarios where device attestation is not required or when user privacy needs to be maximized. attStmt bytes consist of:
alg is the encryption algorithm used to create the cryptographic signature sig
sig is the authenticator certificate’s signature; it is used during registration to verify that the data was signed by this authenticator. To do this, you need to extract the public key of the authenticator – it’s located in the x5c field and must be the first certificate in this chain, – take sig and repeat the same signature verification procedure (see above) as during authentication, only use sig as as signature and use the first key from x5c as the public key
x5c is an X.509 certificate chain that is typically used to establish trust in the certificate's public key. May be missing, depending on the authenticator's certificate.

authData is the most important block of bytes. It contains the public key, various flags, and the authentication data identifier. Let's take a closer look at its structure:

rpIdHash – a domain hashed using the SHA-256 algorithm
flags are boolean values where each bit has a value of 0 or 1:
- UP (User Presence) – this flag indicates whether a physical user action was recorded during the authentication process, such as pressing a button on the authenticator. This serves as proof that the user is actually present during the authentication operation.
- UV (User Verified) – this flag indicates whether the user has been verified by the authenticator, e.g., through biometrics or a PIN. If the flag is set, this means that additional user authentication has been performed.
- BE (Backup Eligibility) – the flag shows whether it is allowed to create a backup copy of the key, which is relevant if the authorization data can be transferred to another device. However, as the authenticator’s certificate is received only during registration, there is no way to find out that the key is being used on another device within the WebAuthn standard.
- BS (Backup State) - the flag shows if the authorization data was copied, that is, if a backup copy was created. Note that you can rely on this flag only if the BE bit is set to 1! The fifth bit in the structure is reserved for the future
- AT (Attested Credential Data Included) – the flag indicates that attested credential data is included in authData. This means that the authentication data contains additional elements such as AAGUID (device identifier), credential ID, and public key.
- ED (Extension Data Included) – this flag indicates that extension data is present in authData. This means that specific extensions were used during the authentication process, and the corresponding data of these extensions is included in the authentication data. counter is a 32-bit number that stores the number of times the authenticator has used these credentials. With each authorization, this counter is increased by one. This number must be saved for each authorization and checked to ensure that the number of authorizations in this field is greater than the number stored in the database.

Attested credential data:

AAGUID (Authenticator Attestation GUID) is a unique identifier for the authenticator model that helps determine the type of authentication device.
Credential ID – a unique credential identifier created by the authenticator and used to identify the account to which it belongs.
Credential Public Key – the public credential key created by the authenticator. This key will be used to authenticate the user during login attempts.

Autocomplete

To improve the user experience during authorization, you can also use autocomplete. Input and textarea support username values for the autocomplete attribute, with the value webauthn. If the user interacts with the input / textarea with autocomplete=”username webauthn” then the browser will return the user’s username at the onChange event, for which we should get the credentialId and pass it to the allowCredentials array.

Iframe

The Webauthn standard partially supports work in iframes; to do this, you need to pass the value publickey-credentials-get to the allow attribute for authorization via the iframe. If the iframe is loaded from a top-level context other than the domain (the domain in the browser’s bar), two additional fields topOrigin and crossOrigin will be sent to clientDataJSON. topOrigin is the domain from the address bar, and crossOrigin is a boolean flag indicating whether the request was cross-domain.

Extensions

While reading the article, you probably noticed a field/byte array called extensions. You can say this is a list of additional authenticator settings, and the full list of extensions can be found here.

CBOR

CBOR (Concise Binary Object Representation) is a data representation format that is structurally similar to JSON, but optimized for a more compact binary representation.

Conclusion

In conclusion, WebAuthn is revolutionizing digital authentication by offering a secure, user-friendly solution that transcends the limitations of traditional passwords. Throughout this article, various explanation formats, such as diagrams and real-world examples, were used to clarify the sophisticated technology behind WebAuthn, making it accessible to a broader audience.

Looking forward, the evolution of WebAuthn will be influenced by emerging technologies and cybersecurity trends. Embracing these changes and employing innovative educational techniques will be crucial for fostering understanding and adoption. As WebAuthn continues to develop, it promises to enhance security and user experience, positioning itself as an essential component of future cybersecurity strategies.

Web Workers: Revolutionizing Web Performance and User Experience

Marsel Akhmetshin — Thu, 14 Mar 2024 08:31:10 +0000

What is a Web Worker?

A WebWorker is a JavaScript feature that allows scripts to run in the background, parallel to the main execution thread, without blocking it or affecting user interface performance. This allows complex computations or data processing to be performed without degrading the responsiveness of the web page.

Essentially, it is a JavaScript script that runs in a separate browser thread and executes code concurrently with the main thread. Web Workers also have their own context, which is separate from the window.
What is meant by "own context"? To simplify, within Web Workers, access to the window, document, or parent objects is unavailable, meaning we cannot manipulate the DOM. At least not directly, but nothing stops us from manipulating the DOM indirectly, for example, by sending commands to the window thread using postMessage.

How to create and run a Web Worker?

It's quite simple: you need to call the Worker constructor and pass a link to our JavaScript file with the code, and that's it:

// window context app.js
const worker = new Worker('worker.js');

Let's now figure out how to link the main browser thread with the Worker thread. They communicate with each other via messages:

// window context app.js
const worker = new Worker('worker.js');

worker.postMessage({ message: '415th, this is base, respond'});

Next, in the Web Worker, using the onmessage property located in the Worker's global context, or in other words, self, we assign our message handler from the higher context. Note that postMessage or self.postMessage can be called from anywhere within our Worker.

// worker context worker.js
onmessage = function (e) {
  if (e.message === "415th, this is base, respond") {
    postMessage("Base, this is 415th, do you copy?");
  }
};

Now, let's receive this message in our app.js: for this, we will also use onmessage, but this time on our Worker object.

// window context app.js
const worker = new Worker("worker.js");

worker.postMessage({ message: "415th, this is base, respond" });

worker.onmessage = function (e) {
  console.log(e); // Base, this is 415th, do you copy?
};

The attentive reader will notice that in the Worker, I sent an object with a message property, but the response from the Worker was a simple string. This is because we can pass any object or data type in postMessage.

Now, let's dive deeper into Web Workers.

Earlier, I mentioned that the window object is not available, but what exactly is available inside a Web Worker? In fact, there's a lot available, but I'll only list some of the Browser API functions we use most often — these include fetch, setInterval, setTimeout, requestAnimationFrame, queueMicrotask. A complete list of supported APIs can be found here.

Previously, we discussed the Dedicated Worker, which is a Worker that is only accessible in the script that created it. If a Worker has its state, that state is only accessible in the script that created the Worker. But what if we want our Worker instance to be accessible from different tabs of the application and from different places within the application? This capability is provided by Shared Workers.

What are Shared Workers?

In web development, Shared Workers are a type of Web Worker that allows creating a multi-threaded, parallel execution stream shared between multiple tabs, iframes, or windows within the same origin. This means that a Shared Worker can be used simultaneously by multiple parts of a web application to exchange data, synchronize states, or perform background tasks without the need to reload or duplicate in each tab or window. It's worth noting that the state of a Shared Worker remains alive as long as someone remembers it.
Let's now figure out how to create and launch a Shared Worker.
Overall, it's the same as with a Dedicated Worker, but with some exceptions. First, to create a SharedWorker instance, you need to use the SharedWorker object/class. Second, working with onmessage and postMessage happens through the port property:

// app1.js
const sharedWorker = new SharedWorker("worker.js");

sharedWorker.port.onmessage = (event) => {
  console.log("data from worker", event);
};

const sendDataToWorker = () => {
  sharedWorker.port.postMessage(1);
};

After that we are doing the same in the other script:

// app2.js
const sharedWorker = new SharedWorker("worker.js");

sharedWorker.port.onmessage = (event) => {
  console.log("data from worker", event);
};

const sendDataToWorker = () => {
  sharedWorker.port.postMessage(2);
};

Let’s now look at the structure of our SharedWorker:

// worker.js
let sum = 0;

onconnect = (connect) => {
    // there will always be one port in ports
  port = connect.ports[0];

  port.onmessage = (event) => {
    sum += event;
  };

  port.postMessage(sum);
};

Inside onconnect, we receive an event, which in our case we call connect, and from there we extract the port object. It's always the only one in this array, and it's not entirely clear why it was designed as an array, possibly as a provision for the future. Next, we take the port and subscribe to incoming messages on it. Sending messages follows the same algorithm and is carried out through the port object.
As you may have noticed, 'ports' is an array, but it always contains only one element, one port. Probably this is a provision for the future.

Nesting of Web Workers

Workers can be nested, and Workers can manage other Workers. The creation principle is identical to the standard method for creating a Worker.

Imports in Web Workers

Starting with browser versions released in June 2023, nearly all browsers support ES modules in the context of Workers, allowing you to use imports with the ‘import xxxxx from ‘lib’’ syntax. This information will be useful when configuring application builds.

Sending Data to a Web Worker

Sending data to and from a Web Worker is usually done through the messaging mechanism, using the postMessage() method. When you send data to a Web Worker (or back to the main thread from the Worker), the data is copied by default, which can lead to additional performance costs, especially when working with large volumes of data.

Sending Data Without Copying

To optimize performance and minimize the costs of copying data, you can use the technique of transferring data through Transferable objects. Transferable objects allow data to be exchanged between the main thread and a Web Worker (or between Web Workers) without copying, by transferring ownership of the data from one context to another. This means that the source loses access to the data after it's sent. Examples of transferable objects include ArrayBuffer and MessagePort.

Example of Using Transferable Objects

Sending data to a Web Worker:

// Creating ArrayBuffer
var buffer = new ArrayBuffer(1024); // 1024 bytes

// Sending ArrayBuffer в Worker
worker.postMessage(buffer, [buffer]);

Receiving data in a Web Worker:

onmessage = function(e) {
  // Receiving ArrayBuffer
  var buffer = e.data; 
  // Ready to work with the data
};

In this example, the ArrayBuffer is sent to the Web Worker using postMessage, and the ArrayBuffer itself is specified in the second argument of postMessage as a transferable object. This means that after the ArrayBuffer is sent from the main thread, it is no longer available in that thread, and ownership is transferred to the Web Worker.

Limitations

After transferring a transferable object, the source loses access to the object. This means that the object cannot be used in the source after it has been sent.
Not all objects can be transferred as ‘transferable’. The types of objects that can be transferred in this way are limited and include ArrayBuffer and MessagePort.

Advantages

Using transferable objects to transfer data between the main thread and Web Workers significantly improves performance when working with large volumes of data, as they avoid the costly process of copying data. This is especially important for applications requiring high performance, such as games, graphic editors, and applications for processing video and audio in real time.

Conclusion

Web Workers are a powerful tool for developing more responsive and efficient web applications. They allow offloading heavy computations and background tasks from the main thread, thereby providing a better user experience. However, it's necessary to consider their limitations and implementation specifics for effective use in your projects.

Building a video player with a streamlined and innovative approach

Marsel Akhmetshin — Wed, 24 Jan 2024 15:00:59 +0000

Let’s develop a video player.

The video player will be implemented with a non-standard approach where control of the video element is done through a controller class, and its state is derived from the state of the DOM element. Instead of duplicating the state of the video element in the state of the React component, we use the existing state of the video element, making the code more efficient, stable, and reducing the amount of code.

The approximate structure of the project that I will adhere to:

├── src
│   ├── components
│   │   ├── player
|   |   |   ├── Player.styles.ts
|   |   |   └── Player.tsx
|   |   ├── progress 
|   |   |   ├── Progress.styles.ts
|   |   |   └── Player.tsx
|   |   ├── timer
|   |   |   ├── Timer.styles.ts
|   |   |   ├── Times.tsx
|   |   |   └── utils.ts
|   |   ├── volume
|   |   |   ├── Volume.styles.ts
|   |   |   └── Volume.tsx
|   |   ├── controllers
|   |   |   ├── gesture-controller.ts
|   |   |   ├── rectanglre-controller.ts
|   |   |   └── video-controller.ts
|   |   ├── styles
|   |   |   └── common.styles.ts

TECHNOLOGIES

ReactJS - A library for web and native user interfaces.
TypeScript - A strictly typed programming language based on JavaScript.
Styled Components - A CSS-in-JS style library.
Screenfull - A wrapper for cross-browser use of the JavaScript Fullscreen API.
Create React App - A project template configured for ReactJS.
You can see an example of the video player here: https://bymarsel.github.io/videoplayer-example/

1. PLAY/PAUSE

Let's start implementing our player with play/pause. For this, we'll start writing our controller. We describe the contract: play, pause methods, and add an element property where we will store a reference to the video DOM element.

export class VideoController {
  private readonly element: HTMLVideoElement;

  constructor(el: HTMLVideoElement) {
    this.element = el;
  }

  play() {
  }

  pause() {
  }
}

Let's start describing the play method:

export class VideoController {
  private readonly element: HTMLVideoElement;
  //...
  play() {
    this.element.play();
  }
  //...
}

Seems simple enough? Actually, not quite. The play() method of the video element is asynchronous, which can lead to isome nteresting effects:

Firstly, video.play() inside an asynchronous function can lead to the loss of the "user gesture token," necessary for playing the video. Without this token, the browser will think that the JS code is trying to do something bad, like showing ads without the user's consent, and just block the video playback.
If you called play(), and then the user pressed pause, you will get a playback error in the browser console. Subsequent calls to play() will lead to a similar result. Why? Because play() is an asynchronous call, and the subsequent call to pause() interrupts the video loading, making subsequent playback impossible. The best way to prevent such a scenario is to block the pause call until the video starts playing. For example, you can wait until the play() call resolves.

Let's slightly change our play() and pause() methods:

export class VideoController {
  private readonly element: HTMLVideoElement;
  private isPausingBlocked: boolean;

  constructor(el: HTMLVideoElement) {
    this.element = el;
  }

  play() {
    this.isPausingBlocked = true;

    this.element
      .play()
      .then(() => {
        this.isPausingBlocked = false;
      })
      .catch((e) => {
        console.log(e);
      });
  }

  pause() {
    if (!this.isPausingBlocked) {
      this.element.pause();
    }
  }
}

Here’s what's happening here:

We set this.isPausingBlocked = true so that the pause call is ignored until the this.element.play() method finishes.

Now we have a basic controller, let's start writing our player. So far, without adding any styles, we will add them later:

import {
  FC,
  useState,
} from "react";

interface Props {
  src: string;
}

export const Player: FC<Props> = ({ src }) => {
  const [element, setElement] = useState<HTMLVideoElement | null>(null);

  return (
    <video src={src} ref={setElement} />
  )
}

It may seem strange or erroneous that we record a reference to the element in the React state. We use this approach so that we can subscribe to state changes. As soon as the reference to the DOM element is available, setElement will be called, which will lead to the component state update.

Now let's create our controller:

import {
  FC,
  useState,
    **useEffect**
} from "react";
**import { VideoController } from "../../controllers/video-controller";**

 // Player.tsx
export const Player: FC<Props> = ({ src }) => {
//...
const [controller, setController] = useState<VideoController | null>(null);
//...
useEffect(() => {
    if (element) {
      const newVideoController = new VideoController(element);
      setController(newVideoController);
    }
 }, [element, src]);
 //...
}

I think everything is clear here: as soon as the element appears in the state (see the code above), useEffect responds to it, and inside useEffect, we create a controller and also save it in the component state.

Okay, now let's give the user the ability to start and pause the video.

import {
  FC,
  useState,
    useEffect**,
    useCallback**
} from "react";

//...
export const Player: FC<Props> = ({ src }) => {
  // ...
  const [controller, setController] = useState<VideoController | null>(null);
  // ...
  const handlePlay = useCallback(() => {
    controller?.play();
  }, [controller]);

  const handlePause = useCallback(() => {
    controller?.pause();
  }, [controller]);

  return (
    <div>
      <video src={src} ref={setElement} />
      <button onClick={handlePlay}>play</button>
      <button onClick={handlePause}>pause</button>
    </div>
  )
}

Here we added pause and play buttons, which call the corresponding methods of the video controller.

💡 In our implementation, we use separate buttons for different playback states. You can use one button and different icons.

Now our player supports two actions: play and pause. But the interface does not react to this, except for playing the video. What if we want to change the play icon to pause on the play event, or some other visual action? The first thing that comes to mind is to add a new property, isPlaying , to the component state and change it on click in handlePlay and handlePause:

// do not copy, this is just an example
  const [isPlaying, setIsPlaying] = useState<boolean>(false);

  const handlePlay = useCallback(() => {
    controller?.play();
  }, [controller]);

  const handlePause = useCallback(() => {
    controller?.pause();
  }, [controller]);

This would work, if not for one thing: The video may be interrupted due to a connection break or slow internet because the video may play faster than it downloads, and our isPlaying won't know about it.

Let's solve this problem. Let's return to our controller and add the getPlayingState method, which will return the current playback state.

export class VideoController {
  // ...
  getPlayingState() {
    if (!this.element.paused) {
      return "playing";
    }

    return "paused";
  }
  // ...
}

With that sorted out, we need to somehow notify the React component that the playback state has changed. For this, we will make some changes to our VideoController:

export class VideoController {
  //...
  private playingStateListeners: (() => void)[] = [];
  private boundEmitPlayingStateChangeListener: () => void;

  //...
  constructor(el: HTMLVideoElement) {
      //...
      this.element = el;
      //...
      this.boundEmitPlayingStateChangeListener = this.emitPlayingStateChangeListeners.bind(this);

      el.addEventListener(
        "play",
        this.boundEmitPlayingStateChangeListener
      );
      el.addEventListener(
        "pause",
        this.boundEmitPlayingStateChangeListener
      );
  }

  private emitPlayingStateChangeListeners() {
    try {
      this.playingStateListeners.map((s) => s());
    } catch (e) {
      console.error(e);
    }
  }

  subscribe(
    event: "playingState",
    callb: () => void
  ) {
    if (event === "playingState") {
      this.playingStateListeners.push(callb);
    }
  }
  //...
}

What's happening here? In very simple terms, we have made a mechanism for subscribing to video element events. In more detail:

playingStateListeners - an array of callbacks where we will store all subscribers to the playback state change.
boundEmitPlayingStateChangeListener - a link to the event listener, bound to the context of the VideoController instance through bind(). We store a separate link so that we can unsubscribe this listener from the event.
emitPlayingStateChangeListeners - a method that notifies subscriber components about the playback state change.
subscribe - a method for subscribing to events, in this case, to playingState.

With that sorted out, let's teach our React component to react to these events.

export const Player: FC<Props> = ({ src }) => {
  //...
  const [playingState, setPlayingState] = useState<
    "playing" | "paused"
  >("paused");

  useEffect(() => {
    if (controller) {
      controller.subscribe("playingState", () => {
        setPlayingState(controller.getPlayingState());
      });
    }
  }, [controller]);
  // ...

  return (
    <div>
      <video src={src} ref={setElement} />
      {playingState === "paused" && <button onClick={handlePlay}>play</button>}
      {playingState === "play" && <button onClick={handlePause}>pause</button>}
    </div>
  )

In useEffect, we subscribed to changes in playingState. For every change in playingState, we will update the component's state. We also made a small change: now, when a video is playing, a button with the text "pause" will be displayed, and conversely, when on "pause", a button with the text "play" will be displayed.

Wait, why go through such complexities when we could have simply implemented it as in the "isPlaying" example? To answer this question, let's return to our controller and add a couple more subscriptions:

constructor(el: HTMLVideoElement) {
    //...
    el.addEventListener(
      "playing",
      this.boundEmitPlayingStateChangeListener
    );
    el.addEventListener(
      "waiting",
      this.boundEmitPlayingStateChangeListener
    );
    //...
  }

We subscribed to two events:

The playing event will be thrown after video playback resumes, after being paused due to slow internet. The video is playing faster than it's loading.
The waiting event will be thrown after video playback is paused due to insufficient data for video playback because the video has not yet finished loading.

Unlike the play and pause events, the playing and waiting events will not be directly triggered by user actions.

Let's summarise these subscriptions: now, when the waiting event occurs, our player will switch to the pause state, and with playing, it will switch to the play state.

We could stop here and say that we've figured out play/pause, but let's do something else, namely, subscribe to the "ended" event.

Why do we need it? To understand that the video has been fully played and to inform the user about it, or, for example, to offer the next video for viewing, as YouTube does.

Let's make some changes to the controller:

export class VideoController {
  //...
  constructor(el: HTMLVideoElement) {
      //...
      el.addEventListener(
        "ended",
        this.boundEmitPlayingStateChangeListener
      );
      //...
  }

  getPlayingState() {
    // ...
    if (this.element.ended) {
      return "ended";
    }
    // ...
  }
}

Here we’ve done the following:

Subscribed to the "ended" event;
Added a new playingState with the simple name ended.

But that's not all, let's teach our component to react to this event:

export const Player: FC<Props> = ({ src }) => {
   const [playingState, setPlayingState] = useState<
     "playing" | "paused" | "ended"
   >("paused");

  //...
  const handlePlayAgain = useCallback(() => {
    controller?.replay();
  }, [controller]);

  return (
    <div>
       //...
      {playingState === "ended" && <button onClick={handlePlayAgain}>replay</button>}
    </div>
  )
}

Here we expanded the type of states in playingState, adding "ended", added a button with the text "ended" and added a click handler handlePlayAgain.

A careful reader will notice that in handlePlayAgain we call the method controller.replay(), which we did not describe earlier, and this is indeed the case.

In fact, to restart the video, assuming that videoElement.ended === true (the video has played to the end), it's enough to call the play() method on the video element, or in our case, controller.play(), and the video will start again.

But what if we wanted to interrupt the video and start it over again, for example, we need a "stop" button, then how to do it? Easy! Let's implement the replay() method in our VideoController:

export class VideoController {
  //...
  private reset() {
    this.element.currentTime = 0;
  }

  replay() {
    if (this.getPlayingState() !== "ended") {
       this.reset();
    }

    this.play();
    }
  //...
}

Here we added the reset and replay methods:

To reset the video playback progress, you need to set the currentTime property to 0, then it will be played from the beginning. Which is what happens in the reset() method.
The replay method calls reset if the video has not ended, and calls the play method.

We wrote a basic version of the player that can play and pause videos. Let’s keep moving.

2. Timer

We've sorted out play/pause; now let's learn how to display the video playback progress time - a timer.

There are two ways to find out the current playback time of a video:

Subscribe to the timeupdate event and, when it's thrown, retrieve the current second of playback from the currentTime property of the video.
Retrieve the current second of playback from the currentTime property while the video is not paused.

We will use the second approach because the first one generates a timeupdate event every 250ms, but this can vary depending on the system. First, it loads our event loop with events, and secondly, our timer might "flip" oddly - sometimes faster by 250ms, sometimes slower, which will not look very good.

Let's describe our component:

import { FC, useRef } from "react";
import { VideoController } from "../../controllers/video-controller";

interface Props {
  controller: VideoController | null;
}

export const Timer: FC<Props> = ({ controller }) => {
    const timerRef = useRef<HTMLSpanElement>(null);

    return <span ref={timerRef}>0:00</span>
}

Right now, the controller does not return the current playback time to us; let's add a getter getPlayingState.

export class VideoController {
  //...
  getPlayingProgress() {
    return this.element.currentTime;
  }
  //...
}

Yes, it's a simple getter that returns currentTime.

The basic structure is ready; let's get it to work. The first thing we'll do is add a function to our component that will update the current playback time.

import { FC, useRef, **useCallback** } from "react";
import { formatCurrentVideoTime } from "./utils";
//...
export const Timer: FC<Props> = ({ controller }) => {
    //...
    const updateCurrentVideoTime = useCallback(() => {
      const timeEl = timerRef.current;

      if (timeEl?.textContent) {
        timeEl.textContent = formatCurrentVideoTime(
          controller?.getPlayingProgress() || 0
        );
      }
    }, [controller]);
    //...
}

Here we get a reference to the DOM element and set its current playback time, previously converting seconds to minutes using the formatCurrentVideoTime function. We need this function to convert video.currentTime from just seconds into human-readable minutes, hours, etc.

💡 The code for the formatCurrentVideoTime function can be found here
.

Let's describe a task that will set a task for updating the time:

//...
import { formatCurrentVideoTime } from "./utils";

export const Timer: FC = ({ controller }) =&gt; {
    //...
    const runTask = useCallback(async () =&gt; {
       const task = () =&gt; {
         if (controller?.getPlayingState() === "playing") {
           updateCurrentVideoTime();
           window.requestAnimationFrame(task);
          }
      };

      window.requestAnimationFrame(task);
    }, [controller, updateCurrentVideoTime]);
    //...
}

Let's figure it out. Here we start the task through requestAnimationFrame, in which we call the updateCurrentVideoTime function, which updates the time and again calls requestAnimationFrame. Before this, we check that the video is still playing by requesting the current playback status through controller?.getPlayingState() === "playing".

But that's not all. RunTask should be somehow called; let's add this functionality:

import { FC, useRef, useCallback, **useEffect** } from "react";

export const Timer: FC = ({ controller }) =&gt; {
  //...
  useEffect(() =&gt; {
    if (controller) {
      controller.subscribe("playingState", runTask);
    }
  }, [controller, runTask]);
  //...
}

Here we subscribed to changes in playingState (play/pause/ended). For every change in playingState, we will call runTask, which will call the task to update the video timer.

Now let's add styles to our timer:

//...
import { Time } from "./Timer.styles";

export const Timer: FC = ({ controller }) =&gt; {
        //... 
   return <time ref="{timerRef}">0:00</time>;
}

Copy the Timer styles from here, and our Timer component is ready.

💡 All component styles are described in the CSS-in-JS approach. The library used was styled-components. If you're not familiar with this approach, no worries, you only need to copy the style file and place it in the appropriate folder according to the structure described at the beginning of the article.

💡 Some styles, such as those for the sound control component, inherit common styles. Therefore, copy them from here into the project before continuing.

With the styles sorted out, let's slightly modify our Player component:

//...
import { Timer } from "../timer/Timer";
//...

export const Player: FC<Props> = ({ src }) => {
  //...
  return (
    <StyledContainer ref={containerRef}>
      <StyledPlayer ref={setElement} src={src} />
      <StyledControls>
        <div>
          {playingState === "paused" && (
            <PlayPauseButton onClick={handlePlay}>play</PlayPauseButton>
          )}
          {playingState === "playing" && (
            <PlayPauseButton onClick={handlePause}>pause</PlayPauseButton>
          )}
          {playingState === "ended" && (
            <PlayPauseButton onClick={handlePlayAgain}>replay</PlayPauseButton>
          )}
        </div>
        <ProgressAndTimerContainer>
          **<Timer controller={controller} />**
        </ProgressAndTimerContainer>
      </StyledControls>
    </StyledContainer>
  );
};

Here we added styles to our player, and also, pay attention, we added the Timer component to our Player. In the block, all player control components will be located in the StyledControlls block.

3. Playback status

As mentioned above, you can find out the current progress of video playback in seconds through the video.currentTimeproperty. Next, we will work with this property of the video.

💡 Take the styles for our progress from here and here, just copy them into your project.

Let's describe our Progress component:

import { useRef } from 'react';
import { VideoController } from "../../controllers/video-controller";
import {
  StripValue,
  StripValuePlaceholder,
  StripValueWrapper,
} from "../../styles/common.styles";

interface Props {
    controller: VideoController | null;
}

export const Progress: FC<Props> = ({ controller }) => {
    const progressRef = useRef<HTMLDivElement>(null);
  const placeholderRef = useRef<HTMLDivElement>(null);

  return ( 
        <StripValueWrapper>
      <StripValue ref={progressRef} />
      <StripValuePlaceholder ref={placeholderRef} />
    </StripValueWrapper>
    )
}

The basic implementation of the component will be as follows: The component will consist of a progress bar (a wide strip) and a progress placeholder (a strip across the entire width of the player, showing 100%). This is the strip that will represent the entire progress of the video. It sounds complicated, but it's not in practice.

To calculate the percentage of the video played, let's teach our VideoController to return the duration of the video:

export class VideoController {
    //...
  getDuration() {
    return this.element.duration;
  }
    //...
}

Here it's simple, we refer to the video element.duration property and get the duration of the video in seconds.

Let's add a method to our component that will change the width of the progress bar depending on video.currentTime:

export const Progress: FC<Props> = ({ controller }) => {
  //...
  const updateProgressBar = useCallback(() => {
    const progressEl = progressRef.current;

    if (progressEl) {
      const videoProgress = controller?.getPlayingProgress() || 0;
      const duration = controller?.getDuration();

      if (duration) {
        progressEl.style.width = `${(100 / duration) * videoProgress}%`;
      }
    }
  }, [controller]);
  //...
};

We take the current played second through getPlayingProgress(), then get the duration of the video through getDuration() and calculate the percentage of the video progress by the formula 100 / duration * videoProgress, after that, we write this value in percentages in the CSS property width of the element.

Now, like the timer, let's write code that will launch the task to update the progress bar in requestAnimationFrame:

export const Progress: FC<Props> = ({ controller }) => {
        //...
        const runTask = useCallback(async () => {
    const task = () => {
      if (controller?.getPlayingState() === "playing") {
                updateProgressBar();
        window.requestAnimationFrame(task);
      }
    };

    window.requestAnimationFrame(task);
  }, [controller, updateProgressBar]);

  useEffect(() => {
    if (controller) {
      controller.subscribe("playingState", runTask);
    }
  }, [controller, runTask]);
    //...
}

Here we did the same as in Timer: described a task that will be called in requestAnimationFrame, and subscribed to the playingState event, the handler of which will call runTask, which will cause our progress bar to be updated.

Let's display our Progress component in Player:

//...
import { Progress } from "../progress/Progress";

export const Player: FC<Props> = ({ src }) => {
  //...
  return (
    <StyledContainer ref={containerRef}>
      //...
      <StyledControls>
        //...
        <ProgressAndTimerContainer>
          **<Progress controller={controller} />**
          <Timer controller={controller} />
        </ProgressAndTimerContainer>
      </StyledControls>
    </StyledContainer>
  );
};

4. Rewinding

In this chapter, we will implement video rewinding. As I mentioned earlier, video rewinding is achieved through the video's currentTime property. To rewind a video, you simply need to set the required second of the video in this property.

Let's implement this. To calculate the second to which we need to rewind the video, we will need to determine the cursor's position relative to the beginning of the progress block. To understand where our progress block is located, we will have to use getBoundingClientRect.

💡 Be careful. When calling getBoundingClientRect, the browser recalculates the layout and returns the current values of the element's size and position. This can be a costly operation, so it is recommended to use this method cautiously and not to abuse its call within loops or frequently recurring events.

Considering the above, let's implement a controller that will call getBoundingClientRect once and request it again on the resize:

export class RectangleController {
    private readonly element: HTMLElement;
  private width: number = 0;
  private left: number = 0;
  private leftPadding: number = 0;

    getWidth() {
    return this.width;
  }

    getLeftOffset() {
    return this.left;
  }

    getLeftPadding() {
    return this.leftPadding;
  }

    private update() {
  }
}

Let's understand the structure of our controller. We will store three main variables in the controller: width, left, leftPadding, which will be accessible outside the controller. We will also store a reference to the DOM element, but the element will not be accessible externally.

Now let's describe the update() method:

export class RectangleController {

    //...
    private update() {
    const domRect = this.element.getBoundingClientRect();

    this.leftPadding = this.element.offsetLeft;
    this.width = domRect.width;
    this.left = domRect.left;
    }
    //...

}

In this method, we will call getBoundingClientRect on our DOM element and fill width, left, leftPadding. leftPadding will be filled from this.element.offsetLeft, because getBoundingClientRect does not have this data. It's all straightforward at this point.

Now let's teach the controller to update the necessary values on resize.

export class RectangleController {
    //...
    private boundUpdate: () => void;

    constructor(element: HTMLElement) {
    this.element = element;
    this.boundUpdate = this.update.bind(this);

    window.addEventListener("resize", this.boundUpdate);

        this.boundUpdate();
    }
    //...
}

Here too, everything is quite simple. We subscribe to the resize event and pass the update method as a handler, bound to the context of our controller class using .bind(). At the end, we call update, or rather its bound version.

We've figured out RectangleController, let’s keep moving.
To make it easier, let's implement helpers that will calculate the cursor position by the x-coordinate, taking into account the position of the block on the page:

import { RectangleController } from "../../controllers/rectangle-controller";

export const calculateCursorPosition = (
  rectangleController: RectangleController,
  x: number
) => {
  const offsetLeft = rectangleController.getLeftOffset();
  return x - offsetLeft;
};

I think everything is clear here. We take the x-coordinate (or offset) of the element from the left edge and the x-coordinate of the mouse cursor and subtract one from the other x - offsetLeft, so we get the mouse cursor position relative to the element from 0px to the maximum width of the block.

Let's add another helper. It will immediately return the mouse cursor position in percentages relative to the element.

export const calculateCursorPositionInPercents = (
  rectangleController: RectangleController,
  x: number
) => {
  const widthInPercents = 100 / rectangleController.getWidth();

  return (
    widthInPercents * calculateCursorPosition(rectangleController, x)
  );
};

Here we get the number of percent per 1px width of the element and multiply it by the value obtained for the position of the cursor relative to the element. It sounds complicated, but let's try it this way:

Suppose the width of the element is 200px, so when dividing 100% by 200px, we get a value of 0.5, meaning for each 1px there is 0.5% of the element's fill.

Now let's implement a helper that will calculate for us the second where the mouse cursor is located:

export const calculateCurrentTimeByCursorPosition = (
  rectangleController: RectangleController,
  x: number,
  duration: number
) => {
  const normalizedPercent =
    calculateCursorPositionInPercents(rectangleController, x) / 100;

  return Math.min(duration * normalizedPercent, duration);
};

Here we convert our calculated percentage of the mouse cursor's position to a decimal number normalizedPercent. That is, 38% is converted to 0.38, etc. Then we take the duration of the video and multiply it by normalizedPercent, ultimately getting the number of seconds of video duration relative to the position of the mouse cursor on the element.

It seems we are done with the calculations for now, let's implement the video rewinding. The first thing we need to do is initialise our RectangleController:

//...
import { RectangleController } from "../../controllers/rectangle-controller";
//...

export const Progress: FC<Props> = ({ controller }) => {

    //...
    const [rectangleController, setRectangleController] = useState<RectangleController | null>(null);

          useEffect(() => {
            if (placeholderRef.current) {
              setRectangleController(new RectangleController(placeholderRef.current));
            }
          }, []);
    //...

}

ts
Here everything is simple: we take placeholderRef.current and create a RectangleController with it.

But our videoController knows nothing about video rewinding, let's expand its capabilities:

export class VideoController {
    //...
    seek(seconds: number) {
      this.element.currentTime = seconds;
  }
    //...
}

As mentioned above, to rewind a video, you just need to specify the necessary time in seconds. For this, we implemented the seek method, which takes time in seconds and sets it in this.element.currentTime.

Now let's implement video rewinding in the component:

import {
  calculateCurrentTimeByCursorPosition
} from "./utils";

export const Progress: FC<Props> = ({ controller }) => {
        //...
        const seek = useCallback((x: number) => {
        if (rectangleController && controller) {
          const seekingValue = calculateCurrentTimeByCursorPosition(
            rectangleController,
            x,
            controller.getDuration()
          );

          controller.seek(seekingValue);

         if (controller.getPlayingState() !== "playing") {
            window.requestAnimationFrame(updateProgressBar);
         }
        }
      }, [controller, rectangleController, updateProgressBar])
        //...
}

Here we described the seek method in the component. Let's figure out what's happening here.

We get the second to which we want to rewind, calculated by the position of the mouse cursor (by the x-coordinate) - the calculateCurrentTimeByCursorPosition method helps us with this - and we pass this value to the seek method. After calling seek, we update our playing progress bar by calling window.requestAnimationFrame(updateProgressBar), provided the video is not playing.

Now, all we have left to do is to add a click handler, thanks to which the user will be able to rewind the video in our player by clicking on the progress bar:

export const Progress: FC<Props> = ({ controller }) => {
    //...
    const handleClick: React.MouseEventHandler<HTMLDivElement> = useCallback(
    (event) => {
        seek(event.clientX)
    },
    [seek]
  );

  return ( 
        <StripValueWrapper onClick={handleClick}>
      <StripValue ref={progressRef} />
      <StripValuePlaceholder ref={placeholderRef} />
    </StripValueWrapper>
    )
}

handleClick calls the seek method of the component we implemented above and passes the X-axis cursor coordinate taken from our click event.

💡 An attentive reader would have noticed that we attach the clickHandler to the progress wrapper, not to the progress itself or the placeholder. We did this because the wrapper is wider, and clicking outside the bounds of the placeholder would result in a negative value, which would be interpreted as rewinding to 0 seconds or to the duration seconds if the click occurred beyond the progress. This is necessary because the user cannot and will not be precisely clicking to the pixel when rewinding the video to the beginning or end.

After we supported the seeking event, it's time to make some adjustments to our Timer and Player.

Now, when the video is playing, our timer will update. But what happens if the user pauses the video and rewinds it? Currently, our timer does not react to rewinding, so let's fix that.

The first thing we will do is teach our controller to work with the seeking event.

This is an event that is triggered when the video's currentTime property changes.

export class VideoController {
    //...
    private seekingListeners: (() => Promise<void>)[] = [];
    //...
    private boundEmitSeekingListeners: () => void;

    constructor(el: HTMLVideoElement) {
        //...
        this.boundEmitSeekingListeners = this.emitSeekingListeners.bind(this);
        el.addEventListener("seeking", this.boundEmitSeekingListeners);
    }

    //...
    subscribe(
    event: "playingState" | **"seeking"**,
    callb: () => Promise<void>
  ) {
        //...
        if (event === "seeking") {
      this.seekingListeners.push(callb);
    }
    }
}

At this point, everything is fairly simple - in the constructor, we subscribed to the seeking event and added the ability to subscribe to this event for our components in the subscribe method.

Now let's return to our Timer component and add support for this event:

export const Timer: FC<Props> = ({ controller }) => {
    //...
  useEffect(() => {
    if (controller) {
      controller.subscribe("seeking", async () => {
        window.requestAnimationFrame(updateCurrentVideoTime);
      });
    }
  }, [controller, updateCurrentVideoTime]);
    //...
};

Here, it's just as simple: we subscribed to the seeking event. As soon as this event is thrown, requestAnimationFrame will be called with a function that updates our timer. That is, even if the video is on pause, and the user rewinds the video from 21 seconds to 1:30, the timer will update because the seeking event is called, and our handler will trigger the timer update.

Now let's make changes to our Player:

export const Player: FC<Props> = ({ src }) => {
    //...
  useEffect(() => {
    if (controller) {
      //...
      controller.subscribe("seeking", async () =>
        setPlayingState(controller.getPlayingState())
      );
      //...
    }
  }, [controller]);
    //...
};

Here we subscribed to the seeking event. When processing this event, we record the current playback state of the video.

Why was this done? For the sole case when the video has reached the end, and the user rewinds it, for example, to the middle. If we do not update the status, then the playback button will be for the action "start over" instead of the desired "play."

5. Volume control

//...
import { Volume } from "../volume/Volume";
**import { isIOS } from 'mobile-device-detect'**
//...

export const Player: FC<Props> = ({ src }) => {
  return (
    <StyledContainer ref={containerRef}>
      <StyledPlayer ref={setElement} src={src} />
      <StyledControls **isIOS={isIOS}**>
              //...
        <ProgressAndTimerContainer>
             //...
        </ProgressAndTimerContainer>
                **{!isIOS &&** <Volume controller={controller} />**}**
      </StyledControls>
    </StyledContainer>
  );
};

Now Volume will be hidden on an iOS device.

6. Fullscreen mode

It's time to talk about fullscreen mode. The first thing we will do is install the screenfull library. It is convenient for working with the Fullscreen API, and it is cross-browser compatible, well, almost.

💡 The Fullscreen API is not supported on the iPhone, I will show you later how to work around this.

So, let's get started. First, let's add a click handler that will request the browser to enter fullscreen mode:


export const Player: FC<Props> = ({ src }) => {
//...
const handleToggleFullscreen: MouseEventHandler<HTMLButtonElement> =
    useCallback(() => {
      if (screenfull.isEnabled) {
        if (containerRef.current) {
          screenfull.toggle(containerRef.current);
        }
      } else {
       //...
      }
    }, [element]);
//...
}

Here everything is simple: first, we check if the Fullscreen API is available on the device through screenfull.isEnabled. If yes, then we try to request fullscreen mode if we are not in it, or exit from fullscreen mode if we are in it, using the toggle method of the screenfull library.

💡 The attentive reader noticed that we request fullscreen mode for the container or wrapper of the player, not the video element itself. This is because if we request fullscreen mode for the video element, we will get the native video player in fullscreen mode without our styles and player buttons. For this reason, we request fullscreen mode for a div element, which simply shows us the element in full screen, as well as our custom video player in it.

But simply calling fullscreen mode is not enough, we need to somehow react to it, for example, we want to change the icon on the button that opens/closes fullscreen mode. First, let's add the flag isFullscreen to the state:

export const Player: FC<Props> = ({ src }) => {
    //...
    const [isFullscreen, setIsFullscreen] = useState<boolean>(false);
    //...
}

At this point, everything is fairly straightforward: we simply added the state of the isFullscreen flag, which we will change depending on whether we are in fullscreen mode or not.

Now let's subscribe to the transition/exit from fullscreen mode:

export const Player: FC<Props> = ({ src }) => {
        //...
        useEffect(() => {
            if (screenfull.isEnabled) {
                  screenfull.on("change", () => {
                    setIsFullscreen(screenfull.isFullscreen);
                  });
                }
      }, []);
        //...
}

Here we check that Fullscreen API is supported by the browser, and subscribe to the transition/exit from fullscreen mode and in the listener of this event, we record the value from screenfull.isFullscreen into the state.

Let's add a button that will call and close fullscreen:

export const Player: FC<Props> = ({ src }) => {
    //...
    return (
        <StyledContainer>
        //...
        </StyledControls>
                //...
        **<FullscreenButton onClick={handleToggleFullscreen}>**
          **{isFullscreen ? "]  [" : "[  ]"}**
        **</FullscreenButton>**
        </StyledControls>
        //...
    )
}

Here everything is simple: on click on the button, the handler we described above is called, and on the change of the isFullscreen variable, we change our “icon” of the button.

What about the iPhone? We have two ways:

try to display the player in full width and height, darkening everything around;
request fullscreen mode of the native iPhone player.

The second option seems to me more reasonable and functional. Let's implement it:

export const Player: FC<Props> = ({ src }) => {
  //...
  return (
    //...
    <StyledPlayer src={src} preload="metadata" ref={setElement} **playsInline** />
    //...
  );
};

At this point, once again, everything is simple: we set the playsInline attribute for the video element. playsInline is an attribute of the <video> element, which tells the browser to play the video inside the <video> element on the page, rather than in fullscreen mode. This is useful for mobile devices, especially on iOS devices, where video can automatically switch to fullscreen mode during playback.

Setting the playsInline attribute to true ensures that the video will play inside the <video> element, rather than switching to fullscreen mode when play is pressed on iOS devices.

Next, let's improve our method:

export const Player: FC<Props> = ({ src }) => {
//...
const handleToggleFullscreen: MouseEventHandler<HTMLButtonElement> =
    useCallback(() => {
      if (screenfull.isEnabled) {
        if (containerRef.current) {
          screenfull.toggle(containerRef.current);
        }
      } else {
       if (
          element &&
          (element as any)?.webkitSupportsPresentationMode("fullscreen")
        ) {
          (element as any)?.webkitSetPresentationMode("fullscreen");
        }
      }
    }, [element]);
//...
}

The webkitSetPresentationMode method is used to set the display mode of an element to fullscreen mode on devices supporting WebKit. In this case, we use it to request fullscreen mode for the video element on iPhone devices.

We check for the support of the webkitSetPresentationMode method with the fullscreen type for the video element. If the device supports this method, we call it with the fullscreen parameter to request the display of the video in fullscreen mode. This allows the video to open in fullscreen mode, but in the native interface of the device.

This way, using the webkitSetPresentationMode method, we can request fullscreen mode for video on iPhone devices where fullscreen mode using the Fullscreen API is not supported. On some iOS devices, this works reliably only after the user has pressed play and the video has started playing. It would help us if we set the preload attribute of the video element to auto, then the browser would always load the video, even if the user does not plan to watch it. In our case, we have set the value to metadata.

💡 When the preload attribute with the value metadata is set on a video element in HTML, the browser only loads the video's metadata. This includes information such as the video's duration, dimensions (width and height), and possibly the first frame for display as a thumbnail. However, the video itself (i.e., its content) will not be loaded until the user starts playback. This allows the page to load faster, as it avoids loading large amounts of video data if the user is not planning to watch it.

But there is another way to solve this problem - ask the user to click on the player to start playback. This way, we hit two birds with one stone: achieve stable operation on iOS and optimise video loading.

Let's improve our Player component:

export const Player: FC<Props> = ({ src }) => {
    //...
    const [wasFirstPlayed, setWasFirstPlayed] = useState<boolean>(false);
    //...
}

Here we added a flag wasFirstPlayed to our player's state, which will indicate that the user clicked for the first time on the player to start the video and hide our improvised poster.

Let's add a handler that will change this flag:

export const Player: FC<Props> = ({ src }) => {
    //...
  const handleContainerClick = useCallback(() => {
    setWasFirstPlayed(true);
    controller?.play();
  }, [controller]);

    //...
  return (
    <StyledContainer **onClick={handleContainerClick}** ref={containerRef}>
            {!wasFirstPlayed && (
        <FirstPlayOverlay>
          <FirstPlayButton>Click to Play</FirstPlayButton>
        </FirstPlayOverlay>
      )}
      //...
    </StyledContainer>
  );
};

Now, on the first click on our entire player, the wasFirstPlayed flag will be set to true, the video will start playing, and our improvised poster will be hidden:

<FirstPlayOverlay>
    <FirstPlayButton>Click to Play</FirstPlayButton>
 </FirstPlayOverlay>

Since we've touched on the topic of playing the video by clicking on the entire player, and not just on the play/pause/replay buttons, let's improve our handleContainerClick so that it not only plays the video but also pauses it.

export const Player: FC<Props> = ({ src }) => {
    //...
  const handleContainerClick = useCallback(() => {
    if (controller?.getPlayingState() === "paused") {
      setWasFirstPlayed(true);
      controller?.play();
    }

    if (controller?.getPlayingState() === "playing") {
      controller?.pause();
    }
  }, [controller]);
};

Now our click event handler will play or pause the video depending on the current playback state.

But now we've created a bug. During rewinding and changing the volume, in general, with any click inside the player, the player will play/pause our video. Let's fix this:

export const Player: FC<Props> = ({ src }) => {

const handleControllsClick: MouseEventHandler<HTMLDivElement> = useCallback(
    (event) => {
      event.stopPropagation();
    },
    []
  );

return (
    <StyledContainer **onClick={handleContainerClick}** ref={containerRef}>
            {!wasFirstPlayed && (
        <FirstPlayOverlay>
          <FirstPlayButton>Click to Play</FirstPlayButton>
        </FirstPlayOverlay>
      )}
            //...
            <StyledControls isIOS={isIOS} **onClick={handleControllsClick}**>
        //... 
      </StyledControls>
    </StyledContainer>
  );)

}

The solution is very simple: catch the click event on bubbling and cancel its further propagation using the stopPropagation method of the event.

7. Frame preview

In this chapter, we will implement a video frame preview feature. When the mouse cursor hovers over any point on the progress bar, we will display the frame corresponding to that position. However, this is just a demonstration version.

The first thing we will do is add our FramePreview component to the Progress component:

//...
import { FramePreview } from "./Progress.styles";

export const Progress: FC<Props> = ({ controller }) => {
    //...
    const framePreviewRef = useRef<HTMLVideoElement>(null);

    return ( 
        <StripValueWrapper onClick={handleClick}>
      <StripValue ref={progressRef} />
      <StripValuePlaceholder ref={placeholderRef} />
            **<FramePreview
            muted
            preload="metadata"
            src={controller?.getVideoSrc()}
            ref={framePreviewRef}
      />**
    </StripValueWrapper>
    )
}

Here we add the FramePreview component, which is a child component of the Progress component. It represents a <video> element, which will be used to display the video frame preview.

In the Progress component, a reference framePreviewRef is created using useRef, which will be used to access the <video> element of the FramePreview component.

Inside the Progress component, the FramePreview component is utilised. It takes the following attributes: muted indicates that the sound should be turned off, preload="metadata" specifies that only video metadata should be loaded, and src={controller?.getVideoSrc()} sets the video source, which is obtained from the controllerobject.

Effectively, we will be showing a player within a player (like exzibit) and rewinding it to the second where the cursor is positioned in the main player.

💡 It's best to implement video previews using a pre-prepared sprite (an image with video frame cutouts) on the server: this solution is more optimal as the sprite loads much faster than the video. To show the desired frame in our preview, in this case, the browser needs to load the video up to that second.

First, let's implement a method that will draw the video frame:

export const Progress: FC<Props> = ({ controller }) => {
 //...
    const renderFramePreview = useCallback(
    (x: number) => {
      const framePreviewElement = framePreviewRef.current;

      const updatePosition = () => {
        if (rectangleController && framePreviewElement) {
          const cursorPosition = calculateCursorPosition(rectangleController, x);

          const currentTime = calculateCurrentTimeByCursorPosition(
            rectangleController,
            x,
            framePreviewElement.duration
          );

          const leftPadding = rectangleController.getLeftPadding();

          framePreviewElement.currentTime = currentTime;
          framePreviewElement.style.left = `${cursorPosition - 50 + leftPadding
            }px`;
        }
      }

      window.requestAnimationFrame(updatePosition)
    },
    [rectangleController]
  );
    //...
}

Let's understand what's happening here. First, we get cursorPosition (the position of the cursor) relative to the width of the progress block by the x-coordinate. Next, by the x-coordinate, we try to get currentTime (frame time) where our cursor is positioned.

Then we rewind the video in FramePreview to the obtained time and move our preview image to the cursor position on the mouse.

💡 The position of FramePreview is calculated according to the formula: cursorPosition - 50 + leftPadding, where cursorPosition is the position of the mouse cursor on the progress block, 50 is half the width of FramePreview, and leftPadding is the padding inside the progress block.

As expected, the task of changing the element's styles is placed in requestAnimationFrame.

We don't always need to show the frame preview, only when the mouse enters the progress block.

export const Progress: FC<Props> = ({ controller }) => {
  //...
  const setFramePreviewVisible = useCallback(() => {
    const framePreviewElement = framePreviewRef.current;

    if (framePreviewElement) {
      framePreviewRef.current.style.visibility = "initial";
    }
  }, []);

  const hideFramePreview = useCallback(() => {
    const framePreviewElement = framePreviewRef.current;

    if (framePreviewElement) {
      framePreviewRef.current.style.visibility = "hidden";
    }
  }, []);
  //...

  return (
    <StripValueWrapper
      onClick={handleClick}
      onMouseEnter={setFramePreviewVisible}
      onMouseLeave={hideFramePreview}
    >
      <StripValue ref={progressRef} />
      <StripValuePlaceholder ref={placeholderRef} />
      <FramePreview
        muted
        preload="metadata"
        src={controller?.getVideoSrc()}
        ref={framePreviewRef}
      />
    </StripValueWrapper>
  );
};

Here everything is simple: on mouseEnter we change visibility to initial, and on mouseLeave we change it to hidden. And then we attach these event handlers to StripValueWrapper.

Now that the frame preview can appear and disappear, let's make it so that the frame preview moves with the mouse.

export const Progress: FC<Props> = ({ controller }) => {
  //...
  const handleMouseMove: React.MouseEventHandler<HTMLDivElement> = useCallback(
    (event) => {
        renderFramePreview(event.clientX);
    },
    [renderFramePreview]
  );
  //...

  return (
    <StripValueWrapper
      onClick={handleClick}
      onMouseEnter={setFramePreviewVisible}
      onMouseLeave={hideFramePreview}
            **onMouseMove={handleMouseMove}**
    >
      <StripValue ref={progressRef} />
      <StripValuePlaceholder ref={placeholderRef} />
      <FramePreview
        muted
        preload="metadata"
        src={controller?.getVideoSrc()}
        ref={framePreviewRef}
      />
    </StripValueWrapper>
  );
};

At this point, everything is pretty simple: we added the handleMouseMove event handler and attached it to the mousemove event of the StripValueWrapper component.

Now, when hovering the mouse, we will see the video frame preview at the second where the cursor is pointed.

8. Touch device support

If the click event still works and features can be used, then when it comes to mousemove, it almost doesn't work as it should on touch devices.

On touch devices, such as smartphones and tablets, the mousemove event does not function the same way as it does on a computer with a mouse. Instead, events like touchstart, touchmove, and touchend are used to track finger movements on the screen.

To support video rewinding on touch devices, you will need a touchmove event handler that will track the finger's coordinates on the screen and correspondingly change the position of the progress bar and the video time.

The first thing we do is implement a kind of GesturesController:

export class GesturesController {
    private touchStarted = false;
    private lastFingerPositionX = 0;
    private timeoutId = 0; 

    touch() {
        window.clearTimeout(this.timeoutId)
        this.touchStarted = true;
    }

    touchEnd() {
        this.timeoutId = window.setTimeout(() => {
            this.touchStarted = false;
        }, 300)
    }

    getTouchStarted() {
        return this.touchStarted;
    }

    setLastFingerPosition(x: number) {
        this.lastFingerPositionX = x;
    }

    getLastFingerPosition() {
        return this.lastFingerPositionX;
    }
}

GesturesController is a class used for managing gestures on touch devices. It has the following functionalities:

touch() - a method called when the screen is touched, sets the touchStarted flag to true.
touchEnd() - a method called when the finger is lifted off the screen, sets the touchStarted flag to false after 300 milliseconds using setTimeout.
getTouchStarted() - a method that returns the current value of the touchStarted flag.
setLastFingerPosition(x: number) - a method that sets the last finger position on the X-axis.
getLastFingerPosition() - a method that returns the last finger position on the X-axis.

This class allows tracking the start and end of a touch on the screen, as well as the last finger position. This is useful for implementing gestures and managing video rewinding on touch devices.

💡 Pay attention to the touchEnd method. In it, we set the touchStarted flag with a delay of 300ms. This is done to ignore mouseclick events on touch devices. It's a small hack for the stability of our code.

Let's support touch actions in our Progress component:

//...
const gesturesController = new GesturesController();

interface Props {
  controller: VideoController | null;
}

export const Progress: FC<Props> = ({ controller }) => {
//...

Here we did something a bit unusual. gesturesController was created at the level of the JS module. Why? Because we don't need to store it in the state of our player, and one instance is enough for the entire life cycle of the module.

Now let's write a touchstart event handler:

export const Progress: FC<Props> = ({ controller }) => {
  //...
  const handleTouchStart: React.TouchEventHandler<HTMLDivElement> = useCallback(
    (event) => {
      gesturesController.touch();

      if (event.touches.length === 1) {
        const touch = event.touches[0];

        const x = touch.clientX;
        gesturesController.setLastFingerPosition(x);
      }

      setFramePreviewVisible();
    },
    [setFramePreviewVisible]
  );
  //...
};

Let's understand what's happening here. First, we will notify our gesturesController that a touch event has started. Then we check that the number of touches is one event.touches.length === 1, extract our touch and get its position on the x-axis. Next, we call setFramePreviewVisible() to make our video preview visible.

Now let's implement a touchmove event handler:

export const Progress: FC<Props> = ({ controller }) => {
    //...
    const handleTouchMove: React.TouchEventHandler<HTMLDivElement> = useCallback((event) => {
    if (event.touches.length === 1) {
      const touch = event.touches[0];

      const x = touch.clientX;
      gesturesController.setLastFingerPosition(x);
      renderFramePreview(x)
    }
  }, [renderFramePreview])
    //...
}

Here we also get the x-coordinate of the user's touch and record it in gesturesController, and also pass this coordinate to the renderFramePreview method to render the video frame preview.

Now let's implement a touchend event handler:

export const Progress: FC<Props> = ({ controller }) => {
    //...
    const handleTouchMove: React.TouchEventHandler<HTMLDivElement> = useCallback(() => {
        gesturesController.touchEnd();

    seek(gesturesController.getLastFingerPosition())
    hideFramePreview()
  }, [renderFramePreview])
    //...
}

The simplest handler of all. Here we notify our gesturesController that the touch has ended. Then we call the seek method with the last touch coordinate for video rewinding and then hide our video frame preview.

This is not the only component that should support touch devices. Let's support touch devices in the Volume component.

//...
const gesturesController = new GesturesController();

interface Props {
  controller: VideoController | null;
}

export const Volume: FC<Props> = ({ controller }) => {
//...

As in the Progress component, we initialise our gesturesController.

Let's make changes to our click handler:

const handleClick: React.MouseEventHandler<HTMLDivElement> = useCallback(
    (event) => {
      if (!gesturesController.getTouchStarted()) {
        updateVolume(event.clientX);
      }
    },
    [updateVolume]
  );

Here it's the same as in Progress, we don't process the click if a "touch" action is already in progress.

Let's implement touch device handlers:

export const Volume: FC<Props> = ({ controller }) => {
  //...
  const handleTouchMove = useCallback(
    (event: React.TouchEvent) => {
      if (event.touches.length === 1) {
        const touch = event.touches[0];

        const x = touch.clientX;
        updateVolume(x);
      }
    },
    [updateVolume]
  );

  const handleTouchStart = useCallback(
    (event: React.TouchEvent) => {
      if (event.touches.length === 1) {
        const touch = event.touches[0];

        const x = touch.clientX;
        updateVolume(x);
      }

      gesturesController.touch();
    },
    [updateVolume]
  );

  const handleTouchEnd = useCallback(() => {
    gesturesController.touchEnd();
  }, []);

  return (
    <StyledStripValueWrapper
      onClick={handleClick}
      **onTouchMove={handleTouchMove}
      onTouchStart={handleTouchStart}
      onTouchEnd={handleTouchEnd}
      onTouchCancel={handleTouchEnd}**
    >
      <StyledStripeValue ref={volumeRef} />
      <StripValuePlaceholder ref={placeHolderRef} />
    </StyledStripValueWrapper>
  );
};

Here everything is analogous to what we did in the Progress component part.

Final touches

The full implementation and all the code can be viewed here: https://github.com/ByMarsel/videoplayer-example.

Streaming Video: If you want features like switching video tracks with different qualities (480p, 720p), streaming video (downloading video in chunks) using HLS, subtitle support, and more, consider using the hls.js library.

💡 HLS (HTTP Live Streaming) is a video format developed by Apple that allows streaming video via HTTP protocol. It is used for delivering video to various devices and platforms, including web pages, mobile apps, and smart TVs.

HLS divides video into small fragments, which are progressively downloaded and played by the client application. This allows delivering video of varying quality depending on the device and network bandwidth availability. For instance, if a device has a slow internet connection, HLS will automatically switch to lower quality video to ensure smooth playback without buffering.

HLS also supports the addition of subtitles, multi-channel audio, and other additional features. It has become a popular format for streaming services such as YouTube, Netflix, and Twitch.

*Video Speed *

If you want to change the video speed, this can be done through the video property playbackRate, with the maximum supported value being 4x.

*Autoplay *

Autoplay will only work if the video is muted, meaning the muted attribute of the video element is set to true. Otherwise, playback of such a video by the browser will be blocked.

Forem: Marsel Akhmetshin

Storybook: Stories for Smart Components

Motivation

Decorators and Addons Mechanism

Integration of a Story with the Application Store: An Example with Redux

Integration of a Story with React Router

Request Mocking

Switching Story Languages from the Storybook Interface

Bonus: Module Federation Support in Storybook

Conclusion

🧠 Unraveling Macrotasks and Microtasks in JavaScript: What Every Web Developer Should Know 💯

Event Loop

Microtasks and Macrotasks

Asynchronicity in the Web Browser

Web Workers: Revolutionizing Web Performance and User Experience

An Example with Macrotasks

An Example with Microtasks

Combined Example: Microtask + Macrotask

An Example with Page Rendering

Example with a Macrotask Calling a Microtask

Event Loop Contexts

The Philosophy of Microtasks and Macrotasks

requestAnimationFrame

Microtasks

Conclusion

🔓 Webauth Unlocked: An In-Depth Exploration of Advanced Authentication Solutions

Introduction

What is WebAuthn?

How does it work?

Registration

Authentication

Formats Description

Registration

Authorization (authentication)

General Implementation

Registration

Authorization

Additional Format Options

Registration

Attestation object

Autocomplete

Iframe

Extensions

CBOR

Conclusion

Web Workers: Revolutionizing Web Performance and User Experience

What is a Web Worker?

How to create and run a Web Worker?

Now, let's dive deeper into Web Workers.

What are Shared Workers?

Nesting of Web Workers

Imports in Web Workers

Sending Data to a Web Worker

Sending Data Without Copying

Example of Using Transferable Objects

Limitations

Advantages

Conclusion

Building a video player with a streamlined and innovative approach

TECHNOLOGIES

1. PLAY/PAUSE

2. Timer

3. Playback status

4. Rewinding

5. Volume control

6. Fullscreen mode

7. Frame preview

8. Touch device support

Final touches