React Hook recipe from https://usehooks.com. Demo: https://codesandbox.io/s/qxkr4mplv6

use-local-storage-example.js

import { useState, useEffect } from 'react';

// Usage
function App() {
  // Similar to useState but we pass in a key to value in local storage
  // With useState: const [name, setName] = useState('Bob');
  const [name, setName] = useLocalStorage('name', 'Bob');

  return (
    <div>
      <input
        type="text"
        placeholder="Enter your name"
        value={name}
        onChange={e => setName(e.target.value)}
      />
    </div>
  );
}

// Hook
function useLocalStorage(key, initialValue) {
  // The initialValue arg is only used if there is nothing in localStorage ...
  // ... otherwise we use the value in localStorage so state persist through a page refresh.
  // We pass a function to useState so localStorage lookup only happens once.
  // We wrap in try/catch in case localStorage is unavailable
  const [item, setInnerValue] = useState(() => {
    try {
      return window.localStorage.getItem(key)
        ? JSON.parse(window.localStorage.getItem(key))
        : initialValue;
    } catch (error) {
      // Return default value if JSON parsing fails
      return initialValue;
    }
  });

  // Return a wrapped version of useState's setter function that ...
  // ... persists the new value to localStorage.
  const setValue = value => {
    setInnerValue(value);
    window.localStorage.setItem(key, JSON.stringify(item));
  };

  // Alternatively we could update localStorage inside useEffect ...
  // ... but this would run every render and it really only needs ...
  // ... to happen when the returned setValue function is called.
  /*
  useEffect(() => {
    window.localStorage.setItem(key, JSON.stringify(item));
  });
  */

  return [item, setValue];
}

Is localStorage read on every rerender?

I wonder if it would be an improvement to write to local storage inside useEffect so that it runs after the render finished?

@vitkon Local storage should only be read on the first render since I'm passing a function to useState. Unless I'm missing something..

I would also suggest wrapping localStorage calls in a try/catch block to avoid any unwanted side effects.

useEffect was said to be for side effects. Accessing and manipulating local storage is a side effect.

Mutations, subscriptions, timers, logging, and other side effects are not allowed inside the main body of a function component (referred to as React’s render phase). Doing so will lead to confusing bugs and inconsistencies in the UI.
https://reactjs.org/docs/hooks-reference.html#useeffect

love what you are doing here. thank you for sharing this!

one suggestion, could we swap out this:

const [item, setValue] = useState(() =>
    window.localStorage.getItem(key) !== null
      ? window.localStorage.getItem(key)
      : initialValue);

with this, for readability:

const [item, setValue] = useState(() => window.localStorage.getItem(key) || initialValue);

Looking forward to more recipes. I'm already hooked after just one :)

@skiano @andys8 Good call. Just updated it to use useEffect instead. Thanks!

@deomsj Glad you're liking it and good suggestion! Updated :)

I like the recipe but there is an issue when using numbers and that they will convert to strings after a refresh. Maybe it is an idea to encode and decode as JSON ?

Suggestion: Return a wrapped version of setValue that updates localStorage whenever it's called. With the current setup, localStorage will be written to on every render, which I don't imagine is fast!

Suggested changes:

import { useState } from 'react';

// Usage
function App() {
  // Similar to useState but we pass in a key to value in local storage
  // With useState: const [name, setName] = useState('Bob');
  const [name, setName] = useLocalStorage('name', 'Bob');

  return (
    <div>
      <input
        type="text"
        placeholder="Enter your name"
        value={name}
        onChange={e => setName(e.target.value)}
      />
    </div>
  );
}

// Hook
const useLocalStorage = (key, initialValue) => {
  // The initialValue arg is only used if there is nothing in local storage ...
  // ... otherwise we use the value in local storage so state persist through a page refresh.
  // We pass a function to useState so local storage lookup only happens once.
  const [item, setInnerValue] = useState(
    () => {
      if (window.localStorage.hasItem(key)) {
        try {
          return JSON.parse(window.localStorage.getItem(key));
        } catch (error) {
          // Do nothing
        }
      }
      // Return default value if key is absent or JSON parsing fails
      return initialValue;
    },
  );

  // Return a wrapped version of useState's setter function that persists the new value to
  // localStorage.
  const setValue = (value) => {
    setInnerValue(value);
    window.localStorage.setItem(key, JSON.stringify(item));
  };

  return [item, setValue];
};

@AndyBarron So originally I had a wrapped function like you suggest but was getting some feedback that useEffect was the right way to do it. Now that I think about it, the wrapped function seems fine since it's not being run during render. So the two choices I see:

Your suggestion:

const setValue = (value) => {
  setInnerValue(value);
  window.localStorage.setItem(key, JSON.stringify(item));
};

Or make it an effect but pass array of values that need to change for it to be called:

useEffect(() => {
  window.localStorage.setItem(key, JSON.stringify(item));
},[key, item]);

Any thoughts on which would be the better choice? Anyone feel free to weigh in here.

This is sort of a tangent, but Philip Walton's article about idle until urgent was so inspiring that I can't help but think about it here

https://philipwalton.com/articles/idle-until-urgent/#persisting-application-state

For small cases this gist seems good, but if its being used inside a game or something that is more intensive, I wonder if it worth considering the pattern outlined under the "Persisting application state" example in the article (using an IdleQueue). I'm not suggesting that the gist change :) just thinking its worth considering before plugging this into an app.

@gragland Another issue with useEffect is that it will immediately persist the default value to localStorage on mount, which might not be what you want. The wrapped version will only write to storage when setValue is called. I would consider the wrapped version better for this reason as well.

@AndyBarron Yeah good point, okay going with the wrapped version. I changed your code slightly so that all calls to localStorage are within the try/catch.

  const [item, setInnerValue] = useState(() => {
    try {
      return window.localStorage.getItem(key)
        ? JSON.parse(window.localStorage.getItem(key))
        : initialValue;
    } catch (error) {
      // Return default value if JSON parsing fails
      return initialValue;
    }
  });

Proposed updates:

• You can wrap setValue with useCallback to ensure you don't return new setValue functions on every render
• I think it should be stringifying value, not item
• Might as well wrap this one in try-catch as well (and stringify might throw too)
• call setInnerValue after localstorage in case persistence throws, so you will not silently think it is working

  const setValue = useCallback(value => {
    try {
      window.localStorage.setItem(key, JSON.stringify(value));
      setInnerValue(value);
    } catch (e) {
      console.log(e);
    }
  }, [setInnerValue]);

Cool lil code =)
The localStorage is storing the previous state though, you must change line 42 for using value instead of item:

window.localStorage.setItem(key, JSON.stringify(value));

So it'll actually save the value that is reflected in the input ;)

Cool lil code =)
The localStorage is storing the previous state though, you must change line 42 for using value instead of item:

window.localStorage.setItem(key, JSON.stringify(value));

So it'll actually save the value that is reflected in the input ;)

I also think, it should be value instead of item. By doing this , If we refresh the page the value remains the same in the input box.

@sabir-jamia is right as you save previous version of a string