Cannot read properties of null (reading 'setItem')

[bhoodream]

Summary

TypeError
Cannot read properties of null (reading 'setItem')

Found this error in sentry. The reason is clearly that the localStorage at the time setItem is called is null. The error occurs quite rarely.

Unfortunately, I don't have time to try to reproduce it.

[dai-shi]

Hope anyone can reproduce it.

[bhoodream]

All devices with an error are something like this

[dbritto-dev]

In fact we can do something like this:

const memoryStorage = {
  setItem(name, value) {
    this[`_${name}`] = value
  } ,
  getItem(name) { 
    return this[`_${name}`]
  },
  removeItem(name) {
    this[`_${name}`] = undefined
  },
}

const localStorageSupported = () => {
  try { 
    const x = "__storage_test__"
    localStorage.setItem(x, x)
    localStorage.removeItem(x)
    return true
  } catch {
    console.warning(`localStorage is unsupported or unavailable`)
    return false
  }
}

storage: createJSONStorage(() => {
  if (localStorageSupported()) return localStorage
  return memoryStorage
})

[bhoodream]

Yes, that's what I was talking about. When using the default implementation, you do not expect that you will still have to handle some edge cases. With such a check, the code will work, even if the localStorage is unavailable for some reason.

And thanks to the warning in the console, users of this middleware will be able to understand what is wrong.

[dbritto-dev]

@bhoodream would youd mind using that solution for now?

@dai-shi any thougts? I can add it to persist middleware or add it to the persist middleware guide. In both cases people can take into account what could happen.

[dai-shi]

@dbritto-dev I think that is usage issue, so improving docs should help.

This pattern should be something we can recommend in docs.

const myStorage = {
  getItem(name) {
    const value = JSON.parse(localStorage.getItem(name));
    // preferably validate value
    return value;
  },
  setItem(name, value) {
    try {
      localStorage.setItem(name, JSON.stringify(value));
    } catch (e) {
      console.warn(...);
    }
  },
  removeItem(name) {
    localStorage.removeItem(name);
  },
};

export const useBearStore = create(
  persist(
    (set, get) => ({
      bears: 0,
      inc: () => set((state) => ({ bears: state.bears + 1 })),
    }),
    {
      name: 'bear-storage',
      storage: myStorage
    }
  )
)

[bhoodream]

Yes, now I agree that this problem should be solved on the side of the middleware user. If you focus on this a little in the documentation, I think there will be no such misunderstanding. And if it does, then you won’t have to spend a lot of time explaining it, but immediately point to the recommendations.

Thanks for the quick help :)

[dbritto-dev]

Cool, I'll add it to docs

[dai-shi]

Cool, I'll add it to docs

@dbritto-dev Sounds great.

Meanwhile, you could create your own storage without using createJSONStorage to fit with your use case. createJSONStorage isn't designed to cover all cases.

Note again that createJSONStorage isn't ideal, as it relies on JSON.parse which isn't type safe, and there's no validations.
We should consider that createJSONStorage is a fallback mechanism. Preferably, people are encouraged to create their own storage for their needs with type safety and validations.

[dbritto-dev]

Cool, I'll add it to docs

@dbritto-dev Sounds great.

Meanwhile, you could create your own storage without using createJSONStorage to fit with your use case. createJSONStorage isn't designed to cover all cases.

Note again that createJSONStorage isn't ideal, as it relies on JSON.parse which isn't type safe, and there's no validations.
We should consider that createJSONStorage is a fallback mechanism. Preferably, people are encouraged to create their own storage for their needs with type safety and validations.

@dai-shi yeah, that makes sense.