In finalizing the current version of my [portfolio](/portfolio), I wanted to offer a dark mode toggle as a proof of concept, practice working with [emotion.js](https://emotion.sh/docs/introduction), and just for usability because my blog and portfolio are so light. To implement this, I utilize a toggle component to control state, `emotion.js`'s `<Global />` styles to inject some styles at `:root`, and browser supported variables to change everything from font color to backgrounds to link colors.

### Set Up

Big picture things you'll need to do:

1. Add state to your parent component/container
2. Pass state down to a `ThemeToggle` and `ThemeWrapper`
3. Use `emotion.js` to pass themes into `:root` in the `ThemeWrapper` component

I'm assuming you have [Gatsby.js](https://www.gatsbyjs.org/docs/quick-start) and have [emotion installed](https://www.gatsbyjs.org/docs/emotion/.). I'm also using browser variables to style text and background colors. You can read an excellent write up on theming with variables at [CSS Tricks](https://css-tricks.com/theming-with-variables-globals-and-locals/).

### Adding State

I built my portfolio as a standalone component, so I'm just adding state to the upper most component:

``` javascript
class Portfolio extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      dark: false
    };
    this.toggleTheme = this.toggleTheme.bind(this);
  }
  componentWillUnmount() {
    this.setState({ dark: false });
  }
  toggleTheme() {
    this.setState({ dark: !this.state.dark });
  }

  render() {
    return (
      <Wrapper>
        <ThemeWrapper
          dark={this.state.dark} />
        <Header>
          {...}
          <ThemeToggle
          toggleTheme={this.toggleTheme}
          dark={this.state.dark} />
        </Header>
        {...}
      </Wrapper>
    );
  }
```

Here, I'm initializing `this.state.dark` to false and binding a toggle function to state. I'm using `componentWillUnmount()` in case someone moves away from the portfolio to the rest of the site (which isn't set up for dark mode yet), and then using `toggleTheme()` to set dark to `true` or `false`. I'm passing state into `ThemeWrapper` as a prop so it knows whether or not to return our darkUI. Because `ThemeWrapper` is going to change `:root` level variables, we don't need to wrap the rest of the page in it, but keeping it near the top of the component makes it syntactically clear what it's for. I'm also passing our `toggleTheme()` function and state into the `ThemeToggle` component so we can visually render what state is set to.

### Theme Wrapper and Themes

Before we build our `ThemeWrapper`, we need to have a javascript file with our themes. I wrote a module that exports two themes--lightUI and darkUI. lightUI repeats the variables I have in my `global.css` and functions as a fallback. darkUI repeats these variables with new colors:

``` javascript
  const lightUI = {
    textColor: `#333`,
    {...}
    backgroundColor: `#fcfcfc`,
  }

  const darkUI = {
    textColor: `#fcfcfc`,
    {...}
    backgroundColor: `#333`,
  }

  module.exports = {
    lightUI: lightUI,
    darkUI: darkUI
  }
```

`ThemeWrapper` takes these themes and uses `emotion.js`'s global styles to inject our theme at the `:root` level:

``` javascript
import React from 'react';
import { Global, css } from '@emotion/core'

import { darkUI, lightUI } from './styles/themes'

const ThemeWrapper = props => {
  const { dark } = props;

  return (
    <Global
      styles={css`
        :root {
          --textColor: ${dark ? darkUI.textColor : lightUI.textColor};
          --backgroundColor: ${dark ? darkUI.backgroundColor : lightUI.backgroundColor};
        }
      `}
    />
  );
};

export default ThemeWrapper;
```

Here, we're importing `Global` and `css` from `@emotion/core` as well as our themes. We've passed state into our `ThemeWrapper` as a prop that's either true or false. We return a `Global` component with a style that initializes, at `root:`, our variables. We then use a ternary operator to return the associated variable depending on whether dark is set to true or false. You can read more about `Global` [here](https://emotion.sh/docs/globals).

### Theme Toggle

So far we've set up state, written some themes, and a component that will render our theme based on state. The last thing to do is provide a toggle that users can actually press to change the theme.

``` javascript
import React from 'react';

const ThemeToggle = props => {

  const { toggleTheme, dark } = props;

  return (
    <button onClick={toggleTheme}>
      {dark
        ? `light`
        : `dark`}
    </button>
  );
}

export default ThemeToggle;
```

Remember that we've passed our `toggleTheme()` function and state into this component. So we're returning a button that, when clicked, toggles state and, based on the state, toggles the words `light` and `dark`. This is a very minimal implementation--you could add a sun and moon icon to signify the same thing.

### Wrapping Up and Further Thinking

You can check out my implementation [here](https://www.inadequatefutures.com/portfolio/) and the source code on [GitHub](https://github.com/inadeqtfuturs/if/tree/master/src/components/portfolio). There's more thinking to be done here about translating variables from dark to light UI. For example, the slider navigation could be tweaked a bit more for better contrast in dark mode, but this would require renaming or adding variables. As I note above, we could also simplify state by using hooks, but that might be for another weekend.

If you have different, better, or slicker implementation, I'd love to hear about it on [twitter](https://twitter.com/inadeqt_futurs) or via email (alexj [dot] christie [at] gmail [dot] com).


tangle

programmatic menus in Gatsby

adding dark mode to your gatsby site with emotion js

Programmatically generating menus is a difficult concept at first because it seems simple enough just to hard code your menu into a component. However, making a reusable and data agnostic menu component is really easy and can travel with you from project to project. Here, I want to outline two approaches to generating menus from your data. The first involves defining menu items in markdown frontmatter, which can be useful when designing sites for folks less familiar with javascript or coding more generally. The second is an iteration on the current Gatsby documentation that skips using GraphQL fragments in favor of a meta config file.

### Markdown Frontmatter

I'm currently working on a Gatsby site template designed specifically for folks with minimal, if any, javascript knowledge. With these users in mind, I'm trying to define most things through really basic global variables in `gatsby-config.js` and frontmatter. I think performing tasks by querying markdown frontmatter can simplify user experience immensely, especially if users are given clear guidelines and a fairly robust set of options.

I wanted users to be able to define their menu from frontmatter for a few reasons:

- It's fairly semantic. Users don't need to write out objects or arrays to get some nice menus.
- Users can distinguish between pages, posts, and pages that should be menu items from the markdown file itself.
- Users don't have to think about slugs because `gatsby-node.js` programmatically generates them. So there's never a time where a slug changes and your menu doesn't reflect that change.  

That being said, this method surely has some downsides:

- Menu is no longer centralized -- you have to go to different files to edit and reorder the menu.
- It's arguable whether this is a major upgrade from just defining a menu in `gatsby-node.js`, especially if users are already defining *other* site data there.
- Implementing sub menus this way is going to be difficult.

With these things in mind, let's take a look at some example frontmatter:

``` markdown
---
title: 'hi.'
author: 'ed.'
date: 2018-12-29T10:52:33-6:00
type: 'page'
menuItem: 1
menuTitle: 'home'
draft: true
---
```

The important things here are just that I've defined a menuItem to position the item in the menu, and I have a label or menuTitle for the item in case I want the title and what shows up in the menu to be different.

Here's our menu component:

```javascript
import React from 'react';
import { Link } from 'gatsby';
import { graphql, StaticQuery } from 'gatsby';

export default (props) => (
  <StaticQuery
    query={graphql`
      query MenuQuery {
        allMarkdownRemark(
          filter: { frontmatter: { type: { eq: "page" } } },
          sort: {fields: [frontmatter___menuItem], order: ASC},
        ) {
          edges {
            node {
              frontmatter {
                menuTitle
              }
              fields {
                slug
              }
            }
          }
        }
      }
    `}
    render={data => {
      const items = data.allMarkdownRemark.edges
      return (
        <nav>
          {items.map(({node}) => {
            const { frontmatter: { menuTitle }, fields:{ slug }, } = node;

            return (
              <Link
                to={slug}
                activeClassName={'active'}
                key={menuTitle}>
                {menuTitle}
              </Link>
            )
          })}
        </nav>
      );
    }}
  />
)
```

StaticQuery is doing the majority of the heavy lifting here. We're filtering all of our markdown files for anything that's listed as a 'page,' and then ordering them by `frontmatter.menuItem`. Any page that doesn't define a menuItem in its frontmatter is excluded from the search. This query also exposes the `menuTitle` and `slug`, so all that's left to do is map our object into Link. What we're left with is a set of easily styled list items nester in `nav` tag.

If you're looking for a simple way to generate single level menus, this is a really great way to go. But what if you're looking for something a little more robust, specifically with nested sub-menus?

### Meta Config File

The approach I ended up taking was siloing metadata about the site into a siteConfig file. Here, I define some site wide settings, and map out my menu. While this can be done in `gatsby-config.js` (and Gatsby docs even offer this as a solution for [mapping programmatic menus](https://www.gatsbyjs.org/docs/centralizing-your-sites-navigation/)), I decided to forego writing another GraphQL fragment of just use an object with some arrays. So the main difference and benefit here is just slimmer syntax at the cost of passing the object through the top level layout component.

There are two parts of this setup: the `siteConfig.js` file, and the menu components. I keep my siteConfig in `content/meta`, though it could be stored anywhere. Here, I define my menu with a series of objects listing the item label, and the page we're navigating to. Additionally, I wanted to be able to define sub-menu items, so I giving 'teaching' a subItems array with objects that are constructed the same way as the top-level objects:

``` javascript
const menu = [
  { label: 'home', to: '/' },
  { label: 'about', to: '/about' },
  { label: 'teaching', to: '/teaching', subItems: [
    { label: 'teaching philosophy', to: '/teaching' },
    { label: 'course descriptions', to: '/classes' },
  ]},
  { label: 'cv', to: '/cv' },
  { label: 'code', to: '/code' },
]

...

module.exports = {
  menu: menu,
  ...
}
```

The final bit of code here is just exporting a bunch of arrays from `siteConfig.js`, but we're just looking at menu for now.

The second part is my `menu.js` and `menuItem.js` component. `menu.js` simply maps the array into the `menuItem.js` component. This is where we use the arrays to define and programmatically generate out menu:

``` javascript
import React from 'react';
import { Link } from 'gatsby';

import { FontAwesomeIcon } from '@fortawesome/react-fontawesome'
import { library } from '@fortawesome/fontawesome-svg-core'
import { fas } from '@fortawesome/free-solid-svg-icons'

library.add(fas)

const MenuItem = ({ item }) => {
  const { label, to, subItems } = item;

  return (
      subItems
        ? (
          <li key={label}>
            <Link to={to}>
              {label} <FontAwesomeIcon icon={['fas', 'angle-down']} size='sm' />
            </Link>
            <ul>
              {subItems.map((subItem) => {
                const { label, to } = subItem;

                return (
                  <li key={label}><Link to={to}>{label}</Link></li>
                )
              })}
            </ul>
          </li> )
        : ( <li key={label}><Link to={to}>{label}</Link></li> )
  )
};

export default MenuItem;
```

So, what's happening here?

- We're deconstructing the item so we can use 'label', 'to', and check for subItems.
- We then use a [ternary operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator) to differentiate arrays that do and do not have 'subItems'.
- If one does, we map the 'label' and 'to' properties to a list item and Link tag, respectively. We also add an 'angle-down' icon to signify that the link has a dropdown menu.
- Then, we map the subItems in similar fashion, iterating over the subItem object.
- The second half of the ternary just gives us a standard Link nested in a list item.

I like this approach because it gives us the separation of concerns that Gatsby's documentation recommends without having to write a static GraphQL query. Additionally, the example above should give you an idea of how to start working with sub-menus, which is absent in the current Gatsby documentation. Check out [my Github](https://github.com/inadeqtfuturs/if/blob/master/src/components/styles/menu.js) for styling.

### Wrap Up

I hope these two models of dealing with menus provide useful examples for folks working on their own Gatsby projects. In future iterations of these menu designs, I'd like to work on rendering a collapsible (hamburger) menu for mobile.
