Added the ability to toggle the header icon on or off using the theme

[PaulMorel1]

This addresses this old issue: #16

I added a toggle to allow users to toggle off the icon that is shown in the header by default. Along with the pull request to disable the dark mode toggle (#65), this gives users full control over what is shown in the header.

Here's what the home page looks like without the header icon.

Here's the theme toggle.

[PaulMorel1]

@spbyrne I'd love to get upgraded permissions for this project. This project doesn't appear to be dead, but I don't see anyone else who is interested in it right now.

I am interested in modern FOSS blogging platforms, and I'd love to work on this starter as a side-project. I'd love to solve some of the problems that remain here out of curiosity and as a learning exercise.

I'm a silicon valley veteran who recently abandoned a lifelong love of WordPress and is thinking a lot about what the future of blogging looks like - I think it looks something like Gatsby and Tina; maybe I'm alone in this?

This is me: https://evanxmerz.com/
This is my day job (nextjs): https://www.vrai.com/

Mainly I want to fix the linting issues, and upgrade old packages (https://www.gatsbyjs.com/docs/reference/release-notes/image-migration-guide/), and I don't feel like anyone else is interested in maintaining this starter right now.

[DirtyF]

Hey Paul, in order to add more flexibility, as Scott mentioned in #16 it would be nice to add more options as we did for the demo

Feel free to take a look at the source for inspiration: https://github.com/tinacms/tina-demo

[PaulMorel1]

Hey Paul, in order to add more flexibility, as Scott mentioned in #16 it would be nice to add more options as we did for the demo

@DirtyF Thanks for this feedback.

I considered this. There are two issues with this from a usability perspective, and one from a technical perspective.

1. Is it a good option to give people a choice of icons in the dropdown, as you did in the demo? No. Nobody is going to use a pre-selected list of the dozen or so icons that would be in the source code. They will want to use their own icon, if they want an icon at all.
2. The other use case that would call for a dropdown is that you imagine a user frequently changing their icon. So maybe we code a dropdown as an example so that users can code their own dropdown. Is this a realistic use case? No. Sites don't realistically change their icon so regularly that it requires a dropdown. Usually people pick a logo once then stick with it or maybe change it once a year.
3. So the only real option here (in reference to picking another icon) is a text field that allows a user to pick from the icons in the massive icon library that you use for the coffee icon. This would be great, but it would require a dynamic import which I think conflicts with how the icon is currently used (although I'm not 100% sure of this). EDIT: Actually, I think you could also import * here, but I think that would add massive bloat to the downloaded package size that is rendered by Gatsby because you're importing hundreds or thousands of icons (I'm not 100% sure of this though, because I'm not exactly sure if anything in the existing render pipeline is smart enough to optimize this).

The color option is a good idea though. This weekend I will see if I can make the dynamic import work. Maybe I will add another PR for a icon color option.

I tend to think that this icon, along with the dark mode toggle, are over-designing though. Does WordPress have a hardcoded icon or darkmode toggle? No. Of course not. Most sites aren't going to want either of those things the way that they are implemented in the existing project. Not that this site is supposed to be WordPress, I know that's not the goal, but just from a general problem-solving perspective, the existing implementation adds little to no value to implementers. Both the icon and the dark mode toggle are trivial to implement from a UI perspective (given that the dark mode CSS selectors already exist), and since they are hardcoded in there they actually require coding work to remove them, so you could make the argument that they are anti-patterns or anti-features in this project.

Sorry for the essay! ;)

This is not a criticism of you or this project. This is an interesting problem that I have enjoyed thinking about.

[PaulMorel1]

@DirtyF @spbyrne Yeah, actually the more I look at this implementation the more problems I see.

1. The existing logo setting is not actually tied to anything. It's non-functional. It says coffee, but changing it does nothing. You can see that in this screenshot. Coffee is just hardcoded in there.
   

2. Realistically, there should be a logo option for the header and a separate icon option for the favicon. This would match platforms like WordPress, Jekyll, and Ghost. And a logo could be a RGB image OR an SVG icon, but it probably won't come from an icon library (although this one you guys are using is massive and interesting and I see you use it on the tina blog).

So I actually think that there should be two different options here, rather than expanding on this existing implementation. There should be an option for a header logo that could connect to the existing Logo field (although that should be an image field). There should be a separate option for the favicon, which can be built off the existing icon implementation, but maybe using a dynamic import.

Yeah, so this PR is sort of re-arranging the deck chairs on the Titanic, because this isn't the right way to go in the first place.