The latest updates on your projects. Learn more about Vercel for Git ↗︎

As said above, there might also be an other way to approach this:

Supporting the above mentioned three storage-solution will increase the bundle-size.
Since all of them however rely on browser-storage solutions, the required overall changes, are not too complex.

However, it might also be of interest to allow for async-storage solutions, which would require even more changes under-the-hood and compared to the above mentioned three storage solutions, will not be trivial.

Imagine the following API:

Creating a theme-provider using browser storage

const { useTheme, ThemeProvider } = createThemeProvider({
  // Based on the attribute passed to the factory-method, we could return a theme-provider that contains only the required code for the chosen storage method.
  storage: < one of 'localStorage' | 'sessionStorage' | 'cookie' >
  storageKey: <key-to-use>
})

Creating a theme-provider for another storage solution

const { useTheme, ThemeProvider } = createThemeProvider({
  storage: 'custom'
  get: async (): Promise<string> => {…}
  set: async (theme: string): Promise<Void> => {...}
})

Basically with this approach, we would create a optmised ThemeProvider based on the users need.
This approach would also allow for other cool benefits, such as strong typing on the possible theme values.

I would find this approach quite interesting, perhaps even a nice addition to the v1 release.
@pacocoursey if that would be of interest, I'd be very interested in discussing it with you.