Problem building the dark mode CSS variable example (Gatsby SSR) #531
-
Bare with me please, I haven't been using React for too long so this could just be something I'm missing. I added a gatsby-ssr.js to the sandbox mentioned here with Gatsby + styled-components and noticed something really peculiar with the build. It pretrains to this part in components/themeContext:
In development, this means first time loading the app will default in dark mode, and if you change it to light mode and refresh th page, you'll get that in storedPrefs. This is more or less what happens in the production build too, but with a minor difference. Loading the production build in light mode produces the correct defaults, until the content of your storedPrefs is the 'light' mode. Then there's a tiny instance where you can see dark mode before it immediately refreshes. I'm assuming this is unavoidable due to the way react hydration works. But the SVG icon doesn't change. I've tried adding a key to it and everything. As long as storedPrefs are contrary to the bottommost return statement, it displays the wrong icon until it's clicked. I was wondering how to fix that? Posting this here because I don't feel like this is an issue with Twin, but I could be wrong. I should probably also mention that this behavior seems shared between styled-components and emotion. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Apologies, it was indeed just a React thing, and I needed to use some sort of method to get the image component to re-render. I was a bit thrown off when keys didn't work and how it worked differently on the server-side. Setting up an initially null useState to defer and ensure a correct first render on the icon's part did the trick. Marking this as answered, thank you. |
Beta Was this translation helpful? Give feedback.
Apologies, it was indeed just a React thing, and I needed to use some sort of method to get the image component to re-render. I was a bit thrown off when keys didn't work and how it worked differently on the server-side.
Setting up an initially null useState to defer and ensure a correct first render on the icon's part did the trick. Marking this as answered, thank you.