I noticed that none of the x in navigator statements are guarded, so they will all break when rendering server-side. I propose adding typeof navigator !== 'undefined' in front of all those.

Furthermore, with the exception of the networking, the hooks return static data and even use useState to store the static data, causing extra work and memory use for something that's basically a single static value that can be determined at module load time. This confuses me, I created #1 to explain what I mean.

Curious to know if there's an Angular equivalent (or if that's already part of Angular).

Cool project, and thanks!

OK, just hear me out on this...

Let's say you have a cosy evening at home, your SO is sitting next to you on the couch watching The Crown on Netflix and the lights are turned off for extra dramatic effects.

However, suddenly you want to check something on your device for whatever reason. Maybe you're frustrated they switched actors in season 3 of The Crown or you want to check something you spent the entire day thinking of.

You turn your device on which is in dark mode to save your eyes (and arguments with you SO) and if you're lucky the site you're visiting automatically picks up the prefers-color-scheme: dark media query and sets the background to a nice and gentle dark tone for smoother reading in dark environments.

And then, you want to play a video and what happens...

But, what if the web app is intelligent enough to pick up light intensity and stream a more suited video source for dark environment. In comes the useAmbientLightEvents() hook allowing developers to adapt the media assets and others based on surrounding light intensity. You don't want to use dark mode for this because then you'd get the "dark" streams on broad daylight...

Let's just say, Ambient Light Events could offer users better experiences than dark mode depending on the use case. Even though support is somewhat limited, only Edge supports it 🙄, I think we could let the big browsers know we might be interested in seeing this in future versions of their browsers. Unless there's a good reason they're not supporting it.

Well at the very least, thanks for hearing me out 😀

disclaimer: this ticket will self-close if it's not gaining traction in 1 week

i am trying to implement the react adaptive hooks on my project but i get the following error.

i am using Next.js
my test page code is as follows

import React from 'react';
import Layout from '../components/template/Layout';
import { useNetworkStatus } from 'react-adaptive-hooks/network';

function Test() {
  const { effectiveConnectionType } = useNetworkStatus();
  return (
    <Layout>
      <p>test</p>
    </Layout>
  );
}

export default Test;

This library is expected to be consumed as is, however, without implicit include for babel-loader it will emit the original ES6 code to the final bundle, breaking old browsers.

Proposal:

• use ES5 inside, so it would be safe to use it
• or ship as a multi-bundle (see https://github.com/theKashey/multiple-entry-points-example)

PS: And is there any reason so spread result like return { ...memoryStatus };

From the title and description I understood that this library should be a React hooks collection. However, when reviewing the source code I found only the Network hook to internally use React hooks APIs, the other three hooks seem to be plain JS functions that memoize the data in module scope at boot time, hence they are not really React hooks.

My understanding of a React hook is something that internally itself uses some other React hook, which means React will schedule calls to those hooks on its hook-stack. If a JS function internally does not use any of React hooks, it is not really a hook, it can be called anywhere-anytime, and hook "rules" don't apply to it. For example, in react-use we have a rule about this in CONTRIBUTING.md.

React hooks are useful for two things: (1) store state at a specific node in React's rendering tree; (2) force a React component to re-render. For example, if you take useHardwareConcurrency hook, it reports number of CPUs on user's device. But that is not state, as number of CPUs is constant and you will never need to re-render a React component because of that data as it will never change.

I hope I'm missing something, would be happy to learn that.

Vue 3 will have an equivalent to react hooks called Composition API.

Given the fact that there are already some hooks that can be used in Vue 3 like the save data hook and memory hook. This project could facilitate both libraries, centralizing the communication with the native browser api as much as possible and providing an lightweight implementation api for both react and vue.

Moved from GoogleChromeLabs/adaptive-loading#60 and GoogleChromeLabs/adaptive-loading#59

The Media Capabilities API allows websites to get more information about the decoding abilities of the device/system/browser. This enables web developers to make optimal decisions when selecting media streams for the user.

After the build scripts update, it is breaking CRA apps.

Failed to compile.

./node_modules/react-adaptive-hooks/dist/index.mjs
Can't import the named export 'useEffect' from non EcmaScript module (only default export is available)

CRA doesn't support .mjs files and requires a good amount of effort just to use that. From my understanding there is no reason that .mjs extension is needed to indicate a ESM file.

Related issues:

• facebook/create-react-app#4317

@midudev and @addyosmani

Currently, useMediaCapabilitiesDecodingInfo will check if the current device can play a certain media file.

Would be nice if we could add support for encoding information, this will allow developers to check if the device can record to a specific media type.

If feasible, we could either...

• add another hook within the media-capabilities folder called useMediaCapabilitiesEncodingInfo
• refactor the current hook to support both API.

For now, the browser api is still in development and not available in chrome but we can already think about the use cases and wether or not we want to implement this.

Specs: https://w3c.github.io/media-capabilities/#dom-mediacapabilities-encodinginfo

Consider this scenario:

My phone is connected to WiFi(4g), the power goes off, and my mobile data(2g) kicks into action. If there were multiple assets fetched for 4g, all their low quality equivalents will now be fetched.
This will also happen when I am travelling between places as my data speed keeps fluctuating.

I am not sure what the solution to this problem is but I believe we shouldn't be replacing assets that are already fully loaded.

memory info totalJSHeapSize and usedJSHeapSize change over time, whereas useMemoryStatus hook return value which was captured during the module load time.
useInitialMemoryStatus would have been a better name since this hook returns initial memory status.

Hi guys, first of all your lib is awesome. And what if it had a interface that automatically inject the right resource? Like in android, you have different paths for different assets,

@wingleung cc @addyosmani

const useMediaCapabilities = (mediaConfig, initialMediaCapabilities = {}) => {
  let mediaCapabilities = {
    supported,
    hasMediaConfig: !!mediaConfig
  };

  mediaCapabilities = (mediaCapabilities.supported && mediaCapabilities.hasMediaConfig)
    ? navigator.mediaCapabilities.decodingInfo(mediaConfig)
    : {
      ...mediaCapabilities,
      ...initialMediaCapabilities
    };

  return {mediaCapabilities};
};

I think navigator.mediaCapabilities.decodingInfo(mediaConfig) was considered synchronous method in above implementation but according to MediaCapabilities.decodingInfo() MDN doc, it's asynchronous method that returns a promise.

So I wonder if this hook returns false for supported property all the time.
And this highlights an issue with the tests which should be catching such problems.

@wingleung Would you mind addressing this issue? Thank you.

Hi. I saw a recent issue #2 regarding server side rendering. However, this behaviour simply hides the attribute mismatch that can happen due to the SSR phase and the client phase rendering differently.

I have built an example repo that showcases this mismatch. https://github.com/gja/react-adaptive-hooks-ssr

Apologies for just copying the relevant file (react-adaptive-hooks/network), but I didn't have time to configure babel and whatnot for server side rendering.

Usage to start repo:

npm install
# npx webpack (if you want to recompile main.js, though it's checked in)
node .

As you can see from https://github.com/gja/react-adaptive-hooks-ssr/blob/master/src/ReactAdaptiveHooksExample.js, it should render a paragraph whose text and class are matching (ie: <p class="4g">Your Network Status Is 4g</p>). However, the ssr hydration will not resolve the classname (ie: <p class="unsupported">Your Network Status Is 4g</p>).

However, react hydrate does not go through element attributes to look for mismatches, hence these attributes will never be caught. (worse, react believes that the classname is set to 4g, while the dom has a different value, so this will not be rectified in future renders as well).

I'm not sure what the supported model is here. In the old class world, i'd have only called out to the new functions during componentDidMount, and change the behaviour that way. I'm not sure what the equivalent is in the react hooks world.

Maybe return undefined when loading, then useEffect to set loading to false, and return the correct value on the next render.

For jsHeapSizeLimit, totalJSHeapSize, usedJSHeapSize it could be nice to have a human readable property like deviceMemory is somewhat of a human readable property (in gigabytes). We could add a human readable property alongside machine value.

{
	supported: true,
	deviceMemory: 8,
	jsHeapSizeLimit: 4345298944
	jsHeapSizeLimit-human: "4.05 G",
	totalJSHeapSize: 47665242, 
	totalJSHeapSize-human:"45.46 MB",
	usedJSHeapSize: 38501994, 
	usedJSHeapSize-human: "36.72 MB",
}

@addyosmani I have spotted your Travis configuration is using Yarn, and there's no yarn.lock in the repo (there's package-lock.json file instead). I don't know whether it's done intentionally or it's just a simple mistake :) In order to get consistent installs across machines, it would be good to pick one of them.

WDYT?

The basic idea behind the useHardwareConcurrency hook is great, but I fear that it is not sufficient to identify slow devices.
Even the moto G of the first generation (with a Snapdragon 400 CPU) has 4 cores. On the other hand, older iPhones only have 2 cores while the single cores are much faster and are able to run expensive animations more easily compared to low end android devices with more cores.

Could we maybe implement a "mini benchmark" to identify the JS execution speed of the device?
Maybe something along the lines of this:

function measure() {
  let start = Date.now();
  let index = 0;
  while (start + 8 >= Date.now()) index++;
  return index;
}

This would however block the mainthread for 8ms (duration could be changed obviously).

Get your score here: https://ogb5i.csb.app/

My Laptop (i7 8565U) manages something around 30.000 while my s10 (Exynos variant) only gets 3.000 - 10.000, the s7 of a friend manages ~1000 and the iPhone 6s of a friend gets 8.000

One would need to source the scores for different devices and implement categories.

Another added benefit would be, that the JS execution speed of the browser is factored in. That would mean, that IE gets fewer heavy animations because it is slower.

I Implemented effectiveConnectionType to detect the network signal strength. When I call the function may be its going in infinite loop and returning following error in console:

Its going multiple times in switch cases. This is my function:

 const MeasureConnectionSpeed = () => {
     const { effectiveConnectionType } = useNetworkStatus();
      switch(effectiveConnectionType) {
        case 'slow-2g':
              setNetworkStrength("WEAK");
          break;
        case '2g':
              setNetworkStrength("OKAY");
          break;
        case '3g':
              setNetworkStrength("GREAT");
          break;
        case '4g':
              setNetworkStrength("EXCELLENT");
          break;
        default:
          break;
      }
  }
  MeasureConnectionSpeed();

Using both lock files inside a repo may cause future problems as far as I know.
Syncing both lock file is extra working unless we do it on precommit I guess.
further info:
https://stackoverflow.com/questions/44552348/should-i-commit-yarn-lock-and-package-lock-json-files
https://yarnpkg.com/blog/2018/06/04/yarn-import-package-lock/

As of now, the code is very verbose and easy to read but I'm wondering if we can optimize readability by tweaking some code styles and namings to prevent double negatives.

For example, the following code...

let unsupported;

const useSaveData = (initialSaveDataStatus = null) => {
  if ('connection' in navigator && 'saveData' in navigator.connection) {
    unsupported = false;
  } else {
    unsupported = true;
  }

  return {
    unsupported,
    saveData: unsupported
      ? initialSaveDataStatus
      : navigator.connection.saveData === true
  };
};

export { useSaveData };

could become...

const useSaveData = (initialSaveDataStatus = null) => {
  const supported = ('connection' in navigator && 'saveData' in navigator.connection)

  return {
    unsupported: !supported,
    saveData: supported
		? navigator.connection.saveData === true
		: initialSaveDataStatus
  };
};

export { useSaveData };

maybe even use a supported property in the return value, I'm not sure if it's deliberate that we use negative naming for this.

is there a way to detect offline state in the network, so we can serve different content, using the hooks?

Are there plans to add typescript support?

useRef is much more suitable than useState when you just want some value to persist across renders. I can make a PR for that change.