#Codeblocks dark mode code#

Note how it requires us to pass the innerHTML, our script, as a Well, in our use case, we actually do want to inject and run a script. React also provides a way to override this behaviour using dangerouslySetInnerHTML, reminding us that it is dangerous. If a user tries to set their name to I'm dangerous!, React encodes characters like < into <. React protects us from this by default, by sanitising the contents before rendering it.

#Codeblocks dark mode code#

Usually, setting HTML from code is risky business because it is easy to inadvertently expose users to a cross-site scripting (XSS) attack. The browser DOM provides us with innerHTML to get or set the HTML contained within an element. ,, and are required for the page to be properly rendered. Unless.there was a way run some code before all of our page is loaded and rendered to the user!

Since we're using Next.js with its Static Generation, there's no way for us to know at code/build time what the user's preference is going to be 🤷‍♂️ The biggest challenge (surprisingly) was being able to run all these checks before anything is shown to the user. Great! We've got a toggle working, and we're also able to store and retrieve the correct state in our page Back to Basics Whenever the user toggles the checkbox to turn dark mode on or off, we save their preference to localStorage for future use.The localStorage.getItem() call returns null if they haven't set one, and we move on to checking their system wide preference is dark mode.When our page is loaded and our IndexPage component has been mounted, we retrieve the user's set preference if they've already set one from their earlier visit.Let's start by putting together a simple Next.js page with a pretty basic dark mode toggle: JSX Allow the user to toggle dark mode, and save their preference for future reference.All the above checks need to be run before our page is rendered/shown to the user.

If the above two methods don't return a preference still, then we default to a light theme.

If the user hasn't visited our site before or hasn't saved a preference, then we check if their Operating System has a preference and use the same.

If the user has visited our site before, then we use their saved preference.

Here's a rough list of what we need to implement: So what should we do? We need to find a way to be able to run some code and apply the appropriate background-color (and by extension, the theme) before the entire page has loaded. This means that until all this has been done, our user still sees only what the HTML has described: a transparent background. If there's any preference for dark mode that has been stored (usually using local storage), it's also loaded by the JS.

The JS loaded first needs to be parsed before it starts to 'hydrate' the page.

The HTML can contain inline CSS to set the background color so that we don't see the 'flicker' but currently, inline CSS doesn't support media queries so we can't find out if the user even prefers dark mode.

By default, a webpage has a transparent background color, which means that you'll get a white background unless you're using certain extensions.The HTML gets loaded first, which in turn loads the JS and CSS.This is because when our page loads up, here's that happens: This is a problem that is not limited to static/hybrid websites but extends to pretty much any website that uses JavaScript to 'hydrate' its components. MDXJS' website flicker before toggling dark mode on refresh If you take a look at a website which has support for dark mode like, you'll notice something if you try to refresh the page once you've enabled dark mode. So what's the big deal? What really is the perfect dark mode? Storing (and retrieving) user preference.