faceless-ui / window-info

A React library for subscribing to window events

Faceless UI

To regenerate search indices, run yarn build:cache.

window-info's Issues

Write useWindowInfo hook

`breakpoints` should default to an empty object

This is to avoid needing to add an empty object fallback when using breakpoints with the useWindowInfo hook.

For example:

const {
  breakpoints: {
    m: midBreak
  } = {} // AVOIDS THIS
} = useWindowInfo();

Add CSS variables for scrollbar information

Should include:

• state
• width

Browser disconnect when calculating media-queries

The Browser Issue

Example breakpoint: @media (max-width: 850px) { }

Chrome calculates media-query breakpoints based on the window width.

• If the browser is 850px wide (from edge to edge) the breakpoint will trigger

Safari calculates media-query breakpoints based on the documents body (not including the scrollbar)

• If the browser is 865px wide (from edge to edge) the breakpoint would hit, because it is calculating document body width and not including the scrollbar.

The window-info Issue

This package follows the chrome approach to calculate when breakpoints have hit, by using the entire window as the measurement. In safari, the disconnect occurs when you are using this package to break at 850px, the JS breakpoint approach will hit after the browser media-query does, because at 865px in Safari, the 850px media-query styles will apply and the JS ones will not unless the browser shrinks down to 850px.

Possible Solution

Instead of using the window width to determine if a breakpoint has hit, I think window.matchMedia could replace that, so on resize, these functions would run and then they would align with the browsers' stylesheet media-query approach.

Thoughts?

Instantiate breakpoints as `undefined` on first render

Provided state values should initialize as undefined until the window is available, as opposed to false, 0, etc.

This will give developers more freedom in their conditional rendering.

RFC - Fully custom breakpoints object

With the current setup, we are only exposing/allowing certain breakpoints to hit and report back to the user and they are all max-width based breakpoints that range from xs/s/m/l/xl

I think a better approach would to allow the user to supply (almost) the entire object and that would have the potential to look exactly how the user wants it to. Take the following as an example, the user could use their own descriptive keys that fit their use case (only using these to show the customization potential):

{
   iphoneXS: '(max-width: 300px)',
   iphoneX: '(max-width: 400px)',
   ipad: '(max-width: 1000px)',
   iphoneXMaxHeight: '(max-height: 800px)',
}

With this approach, breakpoints would be 100% customizable, which would be ideal in many cases.

Then we would create the necessary window.matchMedia queries to fire when the window changes height/width and report back using the keys from their breakpoints object.

Write Unit Tests

Jest should be highly-considered here as React itself now suggests this framework in its documentation (it's a Facebook product, go figure) and even rolls it out with Create React App.

Consider nesting a document height change listener

This may be more appropriate as a stand-alone package — should be audited based on merit.