My thoughts on: #71 (comment)

Don't you think having a generic option might be a bit over engineered for the common use cases?

I thought of the following implementation would solve #72 quiet nicely.

• Add a storage property: the accepted values are : none, sessionStorage, localStorage.

In regards to a 'generic' custom solution :
I think it would be cool if it was possible to hook into the theme changes, to for example allow
the syncing of a users theme-preferences with a data-storage.

• For custom storage options we could define a simple interface. I believe something like this might make sense:

   interface ExternalThemeStorage extends EventTarget { // EventTarget could be an overkill tbh
      get: () => Promise<string | null>
      set: (value: string) =>  Promise<void>
      delete: () => Promise<void>
   }

An object implementing this interface could then be passed to the customStorage property to be used inside the ThemeProvider.

I think allowing the user to combine both the storage property and customStorage property could be very useful,
since saving a users preferences over multiple devices is fairly common.

I don't want to be picky, it is a very nice integration.

But...

I am looking to store the theme info in Redux and have the provider read directly from Redux store instead.

I don't want to be picky, it is a very nice integration.

But...

I am looking to store the theme info in Redux and have the provider read directly from Redux store instead.

Have you made any progress on that?

Hey, any news on this? Having the theme in a session storage if you need this option, sounds like a good use case to me.

@ciruz a pr for this is open and waiting for pacos review.