
CSS properties, known as CSS variables, allow developers to bind key-value pairs to an HTML element. These key-value pairs can be accessed by any ancestor of the bound element. When combined with media queries, a style sheet can allow for more consistent themes and layouts.

> It's worth noting that CSS variables are not supported by every use case. Check [caniuse][caniuse] for more information about whether your use case is supported.

## Using a CSS variable

The format for _declaring_ a CSS variable uses the same syntax as declaring a value for any other CSS property, but it _must_ be prefixed by double-hyphens `--`. The name can include numbers, letters, and hyphens. Letters in the name can be mixed-case. Here are some examples of valid CSS variables:

```CSS
:root {
  --blue: #0d6efd;
  --font-size-base: 2rem;

  ---leading-hyphen: pink;
  ---mixedCase: red;
  --font-700-bold: 700;
}
```

### Consuming a CSS variable

Consuming a CSS variable is pretty straight-forward. A variable can be used in place of any part of any value in any property on an element. It _can't_ be used as a property _name_.

```CSS
p {
  /* valid usage */
  --font-size-base: 2rem;
  font-size: var(--font-size-base);

  /* invalid  usage */
  --prop: color;
  var(--prop): red;
}
```

### Composition with CSS variables

As mentioned, CSS variables can be used in _any_ part of _any_ value. This allows composition of multiple values.

```CSS
p {
  --border-color: black;
  --border-width: 1px;
  border: var(--border-width) solid var(--border-color);
  /* border: 1px solid black; */
}
```

### Additional behaviors

Interestingly, CSS variables can be defined anywhere in the body of an element:

```CSS
p {
  color: var(--color);
  --color: black;
  /* color: black; */
}
```

CSS variables can also be defined multiple times, but the last defined variable is used:

```CSS
p {
  color: var(--color);
  --color: black;
  --color: red;
  /* color: red; */
}
```

CSS variables won't prevent invalid values. The browser will try to interpret the value, but may not have an implementation for the value:

```CSS
p {
  --font-size-base: blerb;
  font-size: var(--font-size-base);
  /* font-size: blerb; */
}
```

Finally, variables can refer to each other, but can also compute to a guaranteed invalid value:

```CSS
p {
  --one: calc(var(--two) + 20px);
  --two: calc(var(--one) - 20px);
  font-size: var(--two);
  /* font-size: calc(var(--one) - 20px); */
  /* invalid value */
}
```

## Media Query interactions

[Media queries][mediaquery] are a CSS feature that help cascade styles based on media conditions. They are used often to provide responsive layouts for web applications.

Here's an example of a media query that changes font size on a paragraph as the width of the browser increases:

```CSS
p {
  --font-size: 2rem;
  font-size: var(--font-size);
}

@media (min-width: 500px) {
  p {
    font-size: calc(var(--font-size) * 2);
  }
}

@media (min-width: 1000px) {
  p {
    font-size: calc(var(--font-size) * 3);
  }
}
```

### Using `var()` in the media query

Unfortunately, since `var()` can only be used to compute the _value_ of a CSS property, it can't be used in the media query itself. This example would not affect the page layout:

```CSS
:root {
  --sm: 500px;
  --md: 1000px;
}
p {
  max-width: 100%;
}

@media (min-width: var(--sm)) {
  p {
    max-width: 90%;
  }
}

@media (min-width: var(--md)) {
  p {
    max-width: 75%;
  }
}
```

## Conclusions

While there are some compatibility issues to consider, CSS variables using the `var()` function are a powerful way to create dynamic components for web applications. Combining the power of CSS variables with media query, one can implement dynamic behavior based on all manner of queries.

By combining CSS variables with media query, an application can be optimized for all manner of screen sizes and orientations, dark mode themes, even some sensor-based queries like [`light-level`][lightlevel].

## References

- [caniuse CSS Variables][caniuse] shows browser compatibility.
- [CSS Properties spec][csspropertiesspec].
- [MDN Using media queries][mediaquery].

[caniuse]: https://caniuse.com/#feat=css-variables
[csspropertiesspec]: https://drafts.csswg.org/css-variables/#defining-variables
[mediaquery]: https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries
[lightlevel]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/light-level


CSS variables are a powerful way to build dynamic styles. Here are some tips for using CSS variables with media queries.

CSS Variables in media queries


[`localStorage`][localstorage] is a browser technology that allows an application to save data in key-value pairs. When used with [react hooks][reacthooks], a web application can subscribe to a value in `localStorage`. Let's look at a common implementation of `useLocalStorage` and see how it can be improved.

## The common `useLocalStorage` hook

The common `useLocalStorage` hook wraps `localStorage.getItem` with a `useState` initializer and returns a tuple with the value and a value setter. Here is an implementation of the common `useLocalStorage` hook:

```ts
const useLocalStorage = (key: string) => {
  // initialize the value from localStorage
  const [currentValue, setCurrentValue] = useState<string | null>(() =>
    localStorage.getItem(key)
  );

  // update localStorage when the currentValue changes via setCurrentValue
  useEffect(() => {
    localStorage.setItem(key, currentValue);
  }, [key, currentValue]);

  // use as const to tell TypeScript this is a tuple
  return [currentValue, setCurrentValue] as const;
};
```

This works for the majority of use cases. However, there is a use case where another tab can change the underlying value stored by `localStorage`. When this happens, the application won't be using the value in storage, it will be using the value stored _in memory_. Here's an explanation from the [MDN documents][storageevent] (emphasis mine):

> The `storage` event of the `Window` interface fires when a storage area (`localStorage` or `sessionStorage`) has been modified in the _context of another document_.

Next, let's look at how we can keep our components updated by consuming the this event.

## An improved useLocalStorage hook

In order to inform our component that a property in `localStorage` has been updated, we need to subscribe to the `storage` event exposed by the `window`. The emitted event object has `storageArea`, `key`, and `newValue` properties that can be used to determine whether the hook should inform consumers of the change. By utilizing the `useEffect` hook, we can set up a subscription to the `storage` event that obeys the react lifecycle.

```ts
const useLocalStorage = (key: string) => {
  // initialize the value from localStorage
  const [currentValue, setCurrentValue] = useState<string | null>(() =>
    localStorage.getItem(key)
  );

  // on every render, re-subscribe to the storage event
  useEffect(() => {
    const handler = (e: StorageEvent) => {
      if (e.storageArea === localStorage && e.key === key) {
        setCurrentValue(e.newValue);
      }
    };
    window.addEventListener('storage', handler);
    return () => {
      window.removeEventListener('storage', handler);
    };
  });

  // update localStorage when the currentValue changes via setCurrentValue
  useEffect(() => {
    localStorage.setItem(key, currentValue);
  }, [key, currentValue]);

  // use as const to tell TypeScript this is a tuple
  return [currentValue, setCurrentValue] as const;
};
```

Now that our component subscribes to changes to the `localStorage` property, there is an opportunity to create a new, reusable hook! Since our new `useLocalStorage` hook is subscribing to a _specific_ window event, we can make a hook that wraps any arbitrary window event.

## The `useWindowEvent` hook

The `window` object has a large number of events that it supports. By using TypeScript and loading the [`dom` library][libdom], we can access the entire series of events and provide a type-safe way to handle any event defined in the `WindowEventMap`. This technique will require us to apply a _generic_ type parameter that links to the `WindowEventMap`.

```ts
interface EventHandler<T extends Event = Event> {
  (e: T): void;
}

interface WindowEventHook {
  <K extends keyof WindowEventMap>(
    eventName: K,
    handler: EventHandler<WindowEventMap[K]>
  ): void;
}

const useWindowEvent: WindowEventHook = (eventName, handler) => {
  // optimization: using useRef here helps us guarantee that this function is
  // is only mutated during effect lifecycles, adding some assurance that the
  // function invoked by the event listener is the same function passed to the
  // hook.
  const handlerRef = useRef<typeof handler>();

  useEffect(() => {
    handlerRef.current = handler;
  }, [handler]);

  useEffect(() => {
    const eventListener: typeof handler = event => handlerRef.current(event);
    window.addEventListener(eventName, eventListener);

    return () => {
      window.removeEventListener(eventName, eventListener);
    };
  }, [eventName]);
};

const useLocalStorage = (key: string) => {
  // initialize the value from localStorage
  const [currentValue, setCurrentValue] = useState<string | null>(() =>
    localStorage.getItem(key)
  );

  const handler = (e: StorageEvent) => {
    if (
      e.storageArea === localStorage &&
      e.key === key &&
      e.newValue !== currentValue
    ) {
      setCurrentValue(e.newValue);
    }
  };

  // set up the event listener
  useWindowEvent('storage', handler);

  // update localStorage when the currentValue changes via setCurrentValue
  useEffect(() => {
    localStorage.setItem(key, currentValue);
  }, [key, currentValue]);

  // use as const to tell TypeScript this is a tuple
  return [currentValue, setCurrentValue] as const;
};
```

Here, we've introduced an interface `WindowEventHook` that defines a default function `<K extends keyof WindowEventMap>(eventName: K, handler: EventHandler<WindowEventMap[K]>): void;`. This definition can be read in three parts:

- `<K extends keyof WindowEventMap>` Some input `K` must be a key of the `WindowEventMap` type. This will be the basis for how we create a relationship between arguments in the next section of the function definition.
- `(eventName: K, handler: EventHandler<WindowEventMap[K]>)` The function signature takes arguments `K` and an `EventHandler` of type `WindowEventMap[K]`.
- `: void;` The function has no meaningful return value.

One might notice the use of the built-in hook `useRef` to hold a reference to the `handler` argument. This is done purely as an optimization to provide some assurance that the _reference_ to the `handler` doesn't change outside of the react component lifecycle.

If `useRef` is useful for keeping references to functions, why doesn't the second (that uses `window.addEventListener` directly) version of `useLocalStorage` also use `useRef`? This is because `useLocalStorage` uses `addEventListener` directly, the reference to the handler never changes, so `useRef` is not useful here.

With the `useWindowEvent` hook in place, the updated `useLocalStorage` hook can consume it in a type-safe way. Here is the type information revealed when consuming the `storage` event:

```ts
const useWindowEvent: WindowEventHook <"storage">(
  eventName: "storage",
  handler: EventHandler<StorageEvent>
) => void
```

If the user tries to subscribe to an event that doesn't exist, TypeScript will throw a compilation error. Here's an example:

```ts
useWindowEvent('foo', () => {});
// Argument of type '"foo"' is not assignable to parameter of type etc...
```

This is TypeScript's way of saying "the string `foo` can't be used as an argument here because it is not found in `WindowEventMap`." Since we created the type constraint `<K extends keyof WindowEventMap>`, and our `K` argument isn't found, TypeScript can't complete the type inference needed to compile the `handler` argument.

## Testing the `useWindowEvent` hook

Testing react hooks using [`@testing-library/react`][testinglibraryreact] is generally a great way to test react components. The best way to utilize this library to test our hook is to create an _integration_ test that allows us to test how our hook is consumed, and how a consumer responds to its side-effects.

```tsx
import React, { useState } from 'react';
import { render, fireEvent } from '@testing-library/react';

const Example = () => {
  const [count, setCount] = useState(0);
  useWindowEvent('click', () => {
    setCount(count + 1);
  });

  return <span data-testid="click-count">{count}</span>;
};

test(`Example renders the number of clicks`, async () => {
  const { getByTestId } = render(<Example />);
  const elem = getByTestId('click-count');
  expect(elem.textContent).toBe('0');

  fireEvent.click(window);
  expect(elem.textContent).toBe('1');

  fireEvent.click(window);
  expect(elem.textContent).toBe('2');
});
```

In this example, a purpose-specific component is used to test the activity of the `useWindowEvent` hook. By using the `fireEvent` API, user interactions are simulated in such a way that we can create fluid user scenarios, and the `testing-library` utilities will keep the component tree updated throughout the test.

## Conclusions

React hooks are a powerful mechanism for abstracting logic away from components. In the case of `localStorage`, we found a way to improve the logic inside the hook, allowing us to avoid changes to the consuming component. We then found a way to reuse the logic in interesting ways by creating the `useWindowEvent` hook, and learned how to test the hook by using the `testing-library` for react.

One idea that occurred to me while writing this post is the idea of an even more generic `useDOMEvent` hook. While implementing the `useDOMEvent` hook, I found complications in creating the correct TypeScript overrides that would be compatible with the react hooks lifecycle. This would be an interesting challenge for another time!

## Resources

- [react-dom-event-hooks repository][domeventhooks] is a repository where the code in this post was developed.
- [react-use][reactuserepo] has examples of react hooks that inspired this post.
- [useHooksBlog][usehooksblog] has an example of a `useLocalStorage` hook that inspired this post.

[localstorage]: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
[storageevent]: https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event
[reacthooks]: https://reactjs.org/docs/hooks-intro.html
[reactuserepo]: https://github.com/streamich/react-use
[usehooksblog]: https://usehooks.com/useLocalStorage/
[libdom]: https://github.com/microsoft/TypeScript/blob/master/lib/lib.dom.d.ts
[mdnwindow]: https://developer.mozilla.org/en-US/docs/Web/API/Window
[eventtarget]: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget
[testinglibraryreact]: https://testing-library.com/docs/react-testing-library/intro
[testinglibraryhooks]: https://github.com/testing-library/react-hooks-testing-library
[domeventhooks]: https://github.com/jmptr/react-dom-event-hooks


Using local storage in react web applications has some caveats that we'll explore before learning how we can use TypeScript to create an improved useLocalStorage hook.

Improving the local storage react hook using TypeScript


One of my favorite math instructors taught me to challenge myself to solve my math problems in 3 ways: with a function, with a graph, and with a set of values. Now that JavaScript has 3 relatively recent versions, you can challenge yourself to solve problems in JavaScript using ES3, ES5, and ES6.

At first glance, it might not make sense to try using older versions of JavaScript, especially now that ES5 enjoys such high levels of support. But I think there's still a lot of value in knowing how to read and use the syntax from old versions because our ecosystem of transpilers can sometimes hide the fact that the code we write isn't always the code we use.

Let's take a look at an ES3 version of flatten:

<p class="codepen" data-height="265" data-theme-id="light" data-default-tab="js,result" data-user="jmptr" data-slug-hash="vrjZjd" style="height: 265px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;" data-pen-title="flatten es3">
  <span>See the Pen <a href="https://codepen.io/jmptr/pen/vrjZjd">
  flatten es3</a> by JM Presley (<a href="https://codepen.io/jmptr">@jmptr</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

What I found interesting here is that Array.isArray() and Array.prototype.reduce() don't exist yet. Without access to the ES5 Array improvements, JavaScript has a hard time revealing itself as a functional programming language.

The ES5 version of flatten will look much more familiar:

<p class="codepen" data-height="265" data-theme-id="light" data-default-tab="js,result" data-user="jmptr" data-slug-hash="PaaZmL" style="height: 265px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;" data-pen-title="flatten es5">
  <span>See the Pen <a href="https://codepen.io/jmptr/pen/PaaZmL">
  flatten es5</a> by JM Presley (<a href="https://codepen.io/jmptr">@jmptr</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

Having access to reduce makes the function much more compact, but now I miss my arrow functions.
Let's see how ES6 can flatten (see this [great article by Casey Morris][es6recursive]):

Doesn't that feel nice? Having access to arrow functions and the spread operator allows us to create code that minimizes syntax noise. Does it increase or decrease readability? I think it can be difficult to read at first, but I also realize that it represents a pattern that I can apply in a number of places.

The recursion technique is neat and all, but it might be a little too neat. As Ryan Dahl recently said "I regret trying to do cute things." Let's look at an ES6 example that just uses arrow functions:

<p class="codepen" data-height="265" data-theme-id="light" data-default-tab="js,result" data-user="jmptr" data-slug-hash="qKKbPx" style="height: 265px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;" data-pen-title="flatten es6">
  <span>See the Pen <a href="https://codepen.io/jmptr/pen/qKKbPx">
  flatten es6</a> by JM Presley (<a href="https://codepen.io/jmptr">@jmptr</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

This one ultimately feels the most expressive and readable to me.

Once I had a good idea of how I wanted to express my flatten variants, I set up a [JSPerf test to see how they compare in terms of performance][jsperf]. After running the test a few times on Chrome 67, I found that the ES3 version was ever-so-slightly faster.

I guess this gives me something to think about when I'm targeting a run-time version of JavaScript for my transpilers!

[es6recursive]: https://medium.com/dailyjs/functional-js-with-es6-recursive-patterns-b7d0813ef9e3
[jsperf]: https://jsperf.com/flatten-comparison


Software designer, crafter, and buttercream connoisseur.

CSS Variables in media queries

Improving the local storage react hook using TypeScript

3 Generations of Flatten in JavaScript