kgilles
commented
3 months ago We might need to consider if we're overloading the term theme. We seem to be using it both to refer to a tailwind theme / color scheme and to refer to a light/dark mode.
Agreed. Theme in this sense should generally mean more than just light or dark. As we want to allow instance owners to have multiple different themes. This may require us to update the contract with the API to add another user setting that only tracks light/dark.
There's still an issue if the user is authenticated and the user has chosen the light theme then the dark theme still flashes as that's what the server renders and the user theme is applied client side. I'm not totally sure the "right" way to address that. But if anyone has ideas on that I'm open to pursuing it.
To make sure there's no flashing the light/dark mode needs to be applied on the server. Meaning we can't only rely on the useEffect block to handle it. In the main layout file we set the "dark" class to the html. I believe this needs to be done dynamically rather than being static. We can pull in the user's theme setting from the site GET that's already happening, and set the appropriate class during SSR.
chasingtheflow
Adds the ability to save and restore the theme style (light or dark) to/from the database.
We might need to consider if we're overloading the term theme. We seem to be using it both to refer to a tailwind theme / color scheme and to refer to a light/dark mode.
This PR will load the theme from the DB if present, else will check localStorage, else use default theme from the server.
There's still an issue if the user is authenticated and the user has chosen the light theme then the dark theme still flashes as that's what the server renders and the user theme is applied client side. I'm not totally sure the "right" way to address that. But if anyone has ideas on that I'm open to pursuing it.