DEV Community: Nika Dev

React Hook for the Battery Status API

Nika Dev — Fri, 10 Oct 2025 18:10:04 +0000

Building a React Hook for the Battery Status API

Hello and welcome to my first React post!

Because I love the Web and I’m also a huge fan of the React framework, I’m very happy to share this article with you.

But enough of the intro — let’s get into the topic!

I’m writing this post because I created a custom hook called useBatteryStatus.

I’ll explain how to build the hook from scratch and later show you how to install and use it yourself.

Let’s start from the beginning.

What is the Battery Status API?

If you’re not familiar with what the API does or what can be achieved with the Battery Status API, I already have a dedicated post about it:

👉 Hands-on Battery Status API.

You can read that first and then continue here.

The Hook

When working with React, I love to keep things small and easy to reuse later on.

That’s also the reason why I love hooks — and why they became so popular.

So I decided to implement this Web API as a React hook, and I named it useBatteryStatus.

Get the BatteryManager

As we learned from the other post, there’s a BatteryManager object that’s returned by the Promise request for the API.

This object is created once per browser window.

In React, each hook instance is isolated, which is a bit tricky in this case.

If we call the Promise inside every hook instance, only the first hook would work — all other instances would lose their event listeners and stop updating.

Let’s take a look at the code:

let batteryManager: BatteryManager | null = null;

async function getBatteryManager() {
  if (!navigator.getBattery) {
    console.warn("Battery Status API is not supported on this browser.");
    return null;
  }

  if (!batteryManager) {
    batteryManager = await navigator.getBattery();
  }

  return batteryManager;
}

We call this function instead of always calling navigator.getBattery().

Here’s what happens:

We check whether the browser supports the API. If not, we log a warning and return null.
If no batteryManager has been created yet (first hook instance), we request it and wait for the Promise to resolve.
If there’s already a batteryManager (when multiple hooks are used on your page), we simply return the existing instance.

That ensures there’s only one call to getBattery() in total.

Initialize Hook Data

First, let’s define the data structure we want to return.
Here’s the interface:

interface BatteryStatus {
  charging: boolean;
  level: number;
  chargingTime: number;
  dischargingTime: number;
}

Nothing surprising here — these properties all exist on the BatteryManager object as well.
Here’s how we initialize the state:

const [batteryStatus, setBatteryStatus] = useState<BatteryStatus>({
    charging: false,
    level: 0,
    chargingTime: Infinity,
    dischargingTime: Infinity
});

battery = await getBatteryManager();
if (!battery) return;

setBatteryStatus({
   charging: battery.charging,
   level: battery.level,
   chargingTime: battery.chargingTime,
   dischargingTime: battery.dischargingTime
});

As you can see, we’re using the helper function from before to get the BatteryManager object.
If the browser supports the Battery Status API, we update the state with the current battery data.

Add event listeners

const handleChange = () => {
   setBatteryStatus({
      charging: battery!.charging,
      level: battery!.level,
      chargingTime: battery!.chargingTime,
      dischargingTime: battery!.dischargingTime
   });
}

battery.addEventListener("chargingchange", handleChange);
battery.addEventListener("levelchange", handleChange);
battery.addEventListener("chargingtimechange", handleChange);
battery.addEventListener("dischargingtimechange", handleChange);

In this case, we’re simply listening for all supported Battery Status events.
Whenever something changes, we update our React state accordingly.

Of course, we should also remove the event listeners when the hook’s useEffect cleanup runs.
You can find the full code at the end of this post.

That’s really all the magic we need — pretty simple, right?
But it makes working with the Battery Status API in React much more convenient.

Use the Hook

Now that we’ve built the hook, let’s see how to install and use it:

npm install @nikadev/use-battery-status --save
# or
yarn add @nikadev/use-battery-status

Then inside your app or component:

import { useBatteryStatus } from "@nikadev/use-battery-status";

export function Component() {
   const { level, charging, chargingTime, dischargingTime, isSupported } = useBatteryStatus();

   if(!isSupported) {
      return (
         <p>Battery Status API is not supported in this browser.</p>
      )
   }

   return (
      <>
         <h1>Battery Status API</h1>
         <section>
            <p>
               <span>charging:</span>
               <span>{charging ? 'Yes' : 'No'}</span>
            </p>

            <p>
               <span>chargingTime:</span>
               <span>{chargingTime}{chargingTime !== Infinity ? 's' : null}</span>
            </p>

            <p>
                <span>dischargingTime:</span>
                <span>{dischargingTime}{dischargingTime !== Infinity ? 's' : null}</span>
              </p>

            <p>
               <span>level:</span>
               <span>{level * 100}%</span>
            </p>
        </section>
    </>
  )
}

Example

You can explore an example in the repository itself:
👉 useBatteryStatus GitHub
Or check out the live demo:
👉 Vercel Example Page.

Conclusion

We’ve seen how the useBatteryStatus hook encapsulates the logic and data of the Battery Status API, making it easy to use in React.
If you’d like to work with the Battery Status API in your own React project, give my hook a try:
👉 useBatteryStatus.

I’d love to hear your thoughts or see what you build with it — let me know in the comments below!

Useful links

Hands on Battery Status API

Nika Dev — Fri, 10 Oct 2025 18:09:35 +0000

Hi everyone, it‘s me again.

So, let‘s move on with what we’ve done before. Today, I want to write about a cool and small API — the Battery Status API.

What is the Battery Status API?

The API gives you the ability to get the battery level of your device. Besides this, you can also get information about the charging status and more detailed information about the charging and discharging time. It’s just as simple as that.

Why should I use the Battery Status API

To be honest, it’s not something that will be used by every web application. But you can use it for energy-efficient features (like reducing animations or pausing background sync) depending on the battery status.
There’s also a use case where you might want to recommend something to the user when their battery is low, such as enabling dark mode or disabling live updates.
It could also be useful if you want to use it for device diagnostics.

How can I use the Battery Status API

As with most new Web APIs, the Battery Status API can be used through an asynchronous method that returns a Promise.

const battery = await navigator.getBattery();

This API call returns a BatteryManager object with the following properties:

charging (boolean)
chargingTime (number)
dischargingTime (number)
level (number)

Let's go quickly through the properties.

charging

This is just a boolean that indicates if the device is connected to a power source. On desktops with no battery, browsers should always return true, but in some cases, they might also return false. For typical mobile devices (laptops or smartphones), it should work as expected.

chargingTime

This is a number in seconds that tells you the estimated time your device needs to fully charge. It may take some time for your device to estimate this value. If the time isn’t yet calculated, it could return Infinity for mobile devices and may change later on. For desktop devices, it will always return Infinity.

dischargingTime

Similar to the previous one, but it tells you the estimated time until your device reaches an empty battery state.

level

This is a number that shows you the current battery level. The number is between 0 and 1 — for example, 0.5 represents 50%.

events

There are also multiple events that you can listen to:

chargingchange
levelchange
chargingtimechange
dischargingtimechange

These events will be triggered whenever one of those values changes. So nothing really special — let’s see it in action.

Everything in action

Okay, sounds easy so far. And yes, the code looks quite simple too:

async function initialize() {
   if(!navigator.getBattery) {
      console.warn("The Battery Status API is not supported in your browser.");
      return;
   }
   const battery = await navigator.getBattery();

   // event listeners
   battery.addEventListener("chargingchange", () => {
      console.log(`Battery charging? ${battery.charging ? "Yes" : "No"}`);
   });

   battery.addEventListener("levelchange", () => {
      console.log(`Battery level: ${battery.level * 100}%`);
   });

   battery.addEventListener("chargingtimechange", () => {
      console.log(`Battery charging time: ${battery.chargingTime} seconds`);
   });

   battery.addEventListener("dischargingtimechange", () => {
      console.log(`Battery discharging time: ${battery.dischargingTime} seconds`);
   });
}

// call the async function for initialization
initialize();

For testing purposes, you can just copy this code into your browser. If you then plug in or unplug your power supply and your browser supports the API, you’ll see console updates in the DevTools.

Which Browsers support the Web Battery Status API?

I don't want to talk about it in detail, because it could be outdated. So here is the link to Web Battery Status API support.

Conclusion

As I said before, the feature is small and easy to use. So there’s no excuse not to use it when it’s useful for your application.
Unfortunately, the feature is currently (as I write this post) not supported by all major browsers, but like most new Web APIs, you can add progressive support for it.

Have you already used it in your project? Let me know in the comments if you have — or give it a try in your next one!

React usage

Reading this and want to use it inside your React application? I already created a small hook where you can use this API in the most “React-like” way possible.
Check out my post about React Hook for the Battery Status API

My sources:

Hands on Web Share API

Nika Dev — Thu, 19 Aug 2021 13:26:48 +0000

Hello world, welcome to my first post!
In this one, I will explain what the Web Share API is and what you can do with it. If you didn't work it yet, maybe you give it a try in your current or next project.

What is the Web Share API?

Let's say, you want to share some page specific data from your website to some social media platforms and maybe messengers.
The Web Share API give web developers the power to use the native share mechanisms, that we all know from native applications (e.g. if you click the share button in Safari on the bottom center). It's one of these cool new APIs, that give the web more capability and push the keyword "Progressive Web App" a little more. If you haven't got any idea what the hell I'm talking about, here is a picture for you:

Web Share API - native dialog on iOS after clicking the button

Why should I use the Web Share API?

You may ask yourself why you should use this API, because you already have enough share possibilities like WhatsApp, Facebook, Twitter, LinkedIn etc. within your application. That's fine, but think about the Web Share API as the cool new kid on the block, which also makes it much easier for you to implement these share possibilities.

Without the Web Share API

In this case, we should have to provide a link/button for every social media/messenger platform. That means, we have to take care of each link separately. That also implies to maintain these links, because they could change in the future.

With the Web Share API

In this case, we will just have one button to click on. After clicking this button, the native dialog will be shown. One advantage of this native feature is, that it is known by the users. Another advantage (I think a bigger one) is, that if there is a new social media platform or native share feature (in the OS) it's directly implemented! All done by the native mechanism! Yeah! 🎉

How can I use the Web Share API?

Like any other new cool Browser API out there, it's asynchronous. That means we have to work with Promises (if you are not familiar with Promises, I'm sure you will find a good article out there). In this case, we will call our navigator.share() function, which will return a promise:

const sharePromise = navigator.share(shareData);

Okay, maybe we need some more context to have a good example.

Let's start with the share() function, that will take the data object (shareData) as a parameter. The result of this call, will be the native share dialog with some share targets, depending on the data that was thrown in. A share target is a possible option, that is displayed to the user in the dialog. This could be a contact (via WhatsApp, Telegram etc.), native applications or built-in service (e.g. "Copy to clipboard"). To make it clear here, you can't decide which share targets should be shown to the user, they were provided by the user agent.

So let's start with the most secret part ... the shareData. Honestly, it's just an object that can contain the following members:

title
text
url
files

In the future there could be some more members, but this is the current state. It's important that not all data members have to be provided, but at least one member should be inside.

The user agent will take care of the shareData and converts these in a suitable format for the different targets. This could include merging or discarding some members. But this magic is done behind the scene, we can just take a drink and enjoy the beautiful interface. 🍹
The share targets that you will see on the native dialog depends on the shareData payload. Anyway, let's dive into the different members of the shareData object.

Title member

This member is a string and contains the title of the document that is shared. In my tests, I couldn't find it anyway. So in most cases, this member is not being displayed or used on most targets.

Url member

The url member is just a simple pure string URL that refers to a resource that should be shared. This could be an absolute or relative URL. If you provide a relative URL it will automatically update the url like a href attribute.

Pro Tip: If you just provide an empty string as url, then it will automatically reffers to the current page.

Text member

The text member is also a string option, that allows you to provide a body of the message for the shared data. This member is often use by the share targets (e.g. email body text).

Everything in action

You might think, why didn't we cover the files member. Please keep cool and take a breath, we will cover it in a couple of minutes. But I think now it's time for some code. Finally 🎉

Let's say we have a fancy button on our page, where we just want to share some data related to the current page. The JS code would look something like this:

// our share button in the markup
const shareButton = document.getElementById('share');

// create share data object
const shareData = {
  title: 'Web Share API',
  text: 'The best way to share your data.',
  url: '' // reffers to the current page
};

// click event handler is necessary to call navigator.share()
shareButton.addEventListener('click', async () => {
  // does the browser supports the feature?
  if(navigator.share) {
    try {
      await navigator.share(shareData);
      console.log('🥳 Shared via API.');
    } catch(error) {
      console.log(`😢 ${error}`);
    }
  } else {
    // you could do a fallback solution here ... 
    console.log('😢 Your browser does not support the web share api.')
  }
})

Now let's go through the code step by step. At first, we create an object and add some members to it, in this case title, text and url. Then we add an event listener to our shareButton. In the event handler, we check for navigator.share, because we want to check if the browser supports the Web Share API. If not, it will return undefined and the else branch will be executed. There could be a fallback solution for all browsers that are not supporting this functionality. At least this would be the best, if we think about progressive enhancement. But in this post we want to concentrate on the if branch.

First, we will open the try block and call the navigator.share(shareData) inside. Now the native dialog will open up with all possible share targets. With await we will wait until the promise is fulfilled. That means, until the user cancel the sharing or chose a share target. On cancel, the code above will run the catch block. If the user finally shares the data via a share target, then the promise will be resolved. Then we successfully shared some data with the Web Share API 🎉

ℹ️ Important note: Even if the sharing was successful, we didn't get any detailed information. The promise itself will just return undefined. There is no way to get the chosen share target of the user. I know that's a bit disappointing, but there is a good reason.

There is a requirement to not allow the website to learn which apps are installed, or which app was chosen from share(), because this information could be used for fingerprinting, as well as leaking details about the user's device. https://www.w3.org/TR/web-share/

Files member

Now it's time to talk about the files member. This one contains all shared files as an array. By adding this member to you shareData, we have to handle binary data and the code gets a little more complex. But don't be afraid, we will go through it together.

So time for some imagination 💭 again...
Imagine you want to share a super cool looking image, if the user clicks on our share button. We need to load the file like this:

const image = await fetch('./super-cool-looking.jpeg');
const blob = await image.blob();
const file = new File([blob], 'image.jpg', { type: 'image/jpeg' });
const filesArray = [file];

// add it to the shareData
shareData.files = filesArray;

In these lines of code we fetch the image, convert the raw data to BLOB (binary large object) and create a new File with the File interface. Then we just put it into an array. Of course, it's possible for you to add their more than one file.
In the end, we just add the files property to the shareData object and initialize it with the filesArray.

Now you can share images via the Web Share API, but be aware that this feature is not supported in all browsers. There is also an opportunity to check, if file sharing is possible in the browser. You can use the navigator.canShare() function for this. It could look like this for our example:

if(navigator.canShare && navigator.canShare({files: filesArray})) {
  await navigator.share(shareData);
} else {
  console.log('File sharing is not supported.');
}

The function has one parameter like the share() function and will return true or false, if the browser can share the object (shareData) you put in.
But there is a big disadvantage for this approach, because this functionality is experimental and is not supported everywhere. Sadly, file sharing isn't that easy to handle on every device and browser. But as always, do it progressive (like above) and support modern browsers.

When to use?

One important note, the navigator.share() function will just work on a user interaction (e.g. click event handler). That means, you can not run the code on page load. Which is good, because otherwise we would have the next stupid thing like cookie banners or push notification permission request.

Which Browsers support the Web Share API?

I don't want to talk about it in detail, because it could be outdated. So here is the link to Web Share API support.

Conclusion

As shown above, the modern way of sharing data in JS makes the code quiet easy and understandable. Also it's easy to maintain the code and we get the native share mechanism, which will also support future social platforms automatically. I'm a real fan of this approach and would recommend to give it a try in your next project. If you already made some experiences with this API, please share your thoughts in the comment section below. 👇

My sources