DEV Community: Eddy Sims

Create a themed favicon for color modes

Eddy Sims — Wed, 29 Sep 2021 23:21:23 +0000

There are 2 types of people in this world. Those who use dark mode and the other people.

I'm not sure about you, but I am basically a 100% user of dark mode on everything I do. There is nothing worse then sitting down at my desk to do some work or reading, opening a website and being hit with a solar flare from the bright white screen in front of me. However, this has caused me some issues when it comes to favicons on the web. A favicon is the small icon that you see in your browser tab that allows you to navigate the madness of your many tabs. If your like me and prefer to save your eyes from the blinding brightness of light mode, you may have noticed that some of these favicons are kind of hard to see.

In this post we will go over how to toggle your favicon based on whether the user has their settings on dark mode or light mode.

Note: In this example I will be using a NextJS website, however this will work in any React application.

Lets start

Create our project

First thing we will do is create a new project.

npx create-next-app themeable-favicons

Create a custom hook

Next, we are going to create a custom hook called useSystemTheme. For our custom hook we are going to simply wrap an already created npm package. So lets install the package.

npm install react-use-system-theme

Now let's create a new file called useSystemTheme.js under a hooks directory. Our directory structure should look something like this.

│   └── components
│   └── hooks
|       ├── useSystemTheme.js
│   └── pages
|       ├── index.js

Inside our useSystemTheme.js file, we are going to import the useTheme function from our react-use-system-theme and return the value from it.

// useSystemTheme.js
import useTheme from 'react-use-system-theme';

export function useSystemTheme() {
  const theme = useTheme();
  return theme;
}

This is called "wrapping". The reason that we want to take this approach rather than just using the useTheme function directly is that if in the future, we decide to re-write this hook or use a different package, we will only need to make the change in one place.

Create our favicons

Next we want to create our favicons. I like to use RealFaviconGenerator.net as I think that it gives you the most robust options for your favicons.

Once you have created your two favicon packages (one for your dark mode and one for your light mode), you will want to rename the files in them from favicon.ico -> favicon-dark.ico etc.

│   └── public
|       ├── favicon-dark-16x16.png
|       ├── favicon-dark-32x32.png
|       ├── favicon-dark.ico
|       ├── favicon-light-16x16.png
|       ├── favicon-light-32x32.png
|       ├── favicon-light.ico

Use our hook to toggle favicons

Note: This step will be very specific to how NextJS works. However, you can do the same thing in any project that has a favicon.

By default, NextJS adds a favicon to our pages/index.js file. We will want to go in and remove this, as we are going to move the favicon to our pages/_app.js file.

Next, in our pages/_app.js file we will want to include our favicon. To do this, we are going to import the Head component from next/head. This will allow us to add to our html head tag.

Inside of our Head component, we will want to add our favicon that we removed from our pages/index.js.

import Head from "next/head";
import "../styles/globals.css";

function MyApp({ Component, pageProps }) {
  return (
    <>
      <Head>
        <link rel="icon" href={`/favicon-${theme}.ico`} />
      </Head>
      <Component {...pageProps} />
    </>
  );
}

export default MyApp;

Finally, we want to import and use our hook to toggle between the two favicons.

import Head from "next/head";
import { useSystemTheme } from "../hooks/useSystemTheme";
import "../styles/globals.css";

function MyApp({ Component, pageProps }) {
  const theme = useSystemTheme();
  return (
    <>
      <Head>
        <link rel="icon" href={`/favicon-${theme}.ico`} />
      </Head>
      <Component {...pageProps} />
    </>
  );
}

export default MyApp;

You will see in the code above that I am including the favicon with favicon-${theme}.ico. This will use the dark favicon that we created earlier on.

Now, when we switch our system theme from light mode, to the more appropriate dark mode, we will be able to toggle our favicon with it.

Some extra notes

While this technique works for system preferences, it can also be used with different color themes if you use something like Theme UI or Chakra UI.
You can find an example repo of this working here
You can find a working demo here
You can find this content in video form here

My first WordPress Plugin. Why? How? What I Learned.

Eddy Sims — Fri, 03 Jan 2020 19:12:28 +0000

Over the last year I have had the responsibility of maintaining and updating our company website. It's a pretty simple WordPress website with a few hundred pages and a few dozen editors. In April of 2019, I made the brave move of updating to WordPress 5 and embarking on a journey of moving our content over to custom Gutenberg blocks.

At that time, I'll admit, I knew nothing about Gutenberg. I found [an article] about how ACF worked with Gutenberg, read through it and created our first block, then our second, then our third, and before I knew it we had quite a few pages fully moved over. It wasn't until a few months in that I realized that ACF with Gutenberg was a good starting point, but really wasn't the best user experience for our editors.

An actual screenshot from our site.

Why I built a WordPress plugin.

As a team, we decided to ditch ACF, move over to ParcelJS and start building custom blocks that are a nice experience for our users and our editors.

This however presented new issues. We had new, better, stronger, faster blocks going out, but there was no way for us to know where the ACF blocks were used for us to replace them.

I got fed up with these types of issues so I spent some time working on a simple function that gave us a WP rest endpoint that showed what pages a block was used on. From there we could be sure that when updating a block, we had found all the instances in which it was used.

This proved to be way more helpful then I could have imagined. Issues went down, QA became much easier, and I was a 🙂 🏕️er. A co-worker of mine mentioned that we couldn't be the only ones having this issue, and this would probably be useful for others as well.

From there I took a few weeks of my spare time and wrote a plugin — Find My Blocks, re-wrote the plugin, submitted it to WordPress and the rest is history!

How I built a WordPress plugin.

As I mentioned, I had originally written an endpoint that did 90% of the work already. From here is was quite simple, take that endpoint, clean it up, consume it by some frontend library, and display a bunch of content. It made sense to me to make a small React app, as Gutenberg is written in the same thing. So my decisions were made and I was off.

I won't get into too much detail about the code. If you would like to take a look you can do so on Github.

What I learned building a WordPress plugin.

I believe that you everything you do is a learning opportunity, and this was no exception. Besides the obvious "How to build a WordPress plugin" there was a tonne of learning from this project.

1. React and WordPress work nicely together.

This was a surprise to me, although I don't know why. At first I thought that setting up a React app on a WordPress plugin would be a pain. The truth is that it was as easy as setting up a React app anywhere. All I needed was a <div id="find-my-blocks"></div>, and the rest was very straight forward.

2. Getting a WordPress plugin into the Plugin Repository is easier than expected.

I have built plenty of WordPress sites, and I have used plenty of WordPress plugins. I always thought that the people who develop plugins are some type of star developer and that getting a plugin into WordPress was super challenging.

Spoiler: It's not.

There are tonnes of guides that show exactly what you need to do. I followed this one in combination of the WordPress Guidelines and found this process to be way easier then I expected.

3. If you build it, they will not come.

This is a lesson that I, and anyone who has released something has learned multiple times.

On Dec 3, 2019 I received my email saying that my plugin was accepted. I screenshot it, sent it to everyone and bragged about how I proud I was!

On Dec 5, 2019 my plugin had 1 active installation... My own... 😔

I couldn't believe it! I had created something that was so useful to me! Why wasn't anyone using it?!

Answer: Because no one knew it existed.

I took some action and sent a message to a few slack communities that I am part of, hoping that people would evangelize my great work.

As of writing this line, my plugin has 87 all time downloads and I am very happy with that. I quickly learned unless I wanted to dedicate a large amount of time to this, I needed to not care about the numbers and just hope that my work is helping to make someone else's life easier.

4. Anyone can do it.

Imposter syndrome is real and it keeps a lot of people back from doing amazing things.

I don't think I have created the greatest thing of all time, But I also never thought that I would have a project out in the wild. I hummed and hawed about whether I should submit my plugin, and I'm glad I did. Something so small was able to give me a confidence boost I needed to start my next, bigger project, and then hopefully another one after that, and another one after that.

I realize now that people who put these projects out are not some sort of star developer. They are people who most likely started with something small, learned from it and let their ideas grow.

Try my plugin?

If you want to try out my plugin you can find it here. I would appreciate it if anyone wants to try it out and leave me feedback on their thoughts!

If you have any questions, let me know in the comments and I will try to get back to everyone!