
The idea of utilizing a [digital garden](https://maggieappleton.com/garden-history) as a way of learning in public (over and against the practice of monetizing the self) is extremely appealing and simpatico with some things I'm trying to develop around issues of knowledge, community, and access in web development. In beginning to think about the content and structure of my own digital garden, or in thinking about what an ideal digital garden would be, I've spent a lot of time considering the metaphor of gardening. What I appreciate about Mike Caufield's description ('Every walk through the garden creates new paths, new meanings, and when we add things to the garden we add them in a way that allows many future, unpredicted relationships' [['The Garden and the Stream: A Technopastoral'](https://hapgood.us/2015/10/17/the-garden-and-the-stream-a-technopastoral/)]) is that it places central focus on the user -- the person navigating the garden. What I want to think a bit more about is gardening as a socio-spatial metaphor and practice. Who gets to garden? Where does the garden come from, or what space does the garden occupy? What counts as gardening?

### [aside]

[To lay some cards on the table, I'm interested in working towards a workflow and relational structure that enables the proliferation of free learning resources. I see digital gardening as a great way for people to (1) develop their ideas through iterative practicing and writing in public and (2) find others' writing, which might in turn help them. I see digital gardening as a reciprocal practicing in a larger ecology of knowledge practicing(s), and I see it as potentially beneficial for lowering the barrier to entry for a lot of the work that I do as a software engineer.

In this note, I'm attempting to stay very high level about some of the questions I'm thinking through and allowing some of these concepts to develop further later on.]

### gardens have walls

One major upshot of digital gardening, over and against formal blogging, is that it promotes a transitory and provisional style of writing. Gardening allows, if not encourages, us to write more for ourselves and others -- notes, working examples, missives, among other things. One thing that was exciting to learn was the amount of thinking happening around non- or antihierarchical models of knowledge in digital gardening. One example is [Aravind Balla's blog](https://notes.aravindballa.com/), which takes an index page as a central nodal point (it's where the site begins) and moves outwards to different posts or notes. The spatial arrangement helps to refuse an informational hierarchy the privileges a kind of performance of mastery (what Maggie Appleton identifies as 'cultivated performance' [['A Brief History of the Digital Garden'](https://maggieappleton.com/garden-history)]) in favor of allowing the user to move between informational nodes.

This arrangement also highlights one of the problems with the garden metaphor: gardens are bounded and domesticated spaces. A garden has a wall and the wall is meant to keep some things in and some things out. We can see Mr. McGregor chasing Peter Rabbit from the garden as an apt metaphor for young learners being kept from cultivated knowledge. I don't want to be the gardener keeping others from tilled soil, and as generous as a gardener can be with others, it doesn't negate the way gardens (literally and metaphorically) delineate space outside larger ecologies. In some ways, it makes sense to talk about a digital garden in a larger ecology that is the internet or that is a set of knowledge practices. So maybe what I'm trying to say is that 'digital garden' is an apt metaphor for internet writing, but one I want to think around or beyond rather than within.

The concept of the '[quoteback](https://quotebacks.net/)' is helpful here because it pulls in information from beyond the garden walls, drawing from the larger digital ecology we inhabit.

### gardens are anti-ecological

When I think about digital gardens as being 'anti-ecological', I mean that digital gardening can quickly become a kind of feedback loop that devolves into the 'cultivated performa[tivity]' Maggie Appleton describes in her article. I'm interested in the question of who and what is the garden for? If it's to learn in public, I see it as serving a few disparate audiences:

1. The gardener: I want to use the garden to test out and develop ideas for myself. I want to write notes that I can return to. I want to allow those notes and ideas to accrete into something beyond their own scope.
2. The garden wanderer: I want to offer pieces of information to help others. I want what I know and what I've learned to be freely accessible to everyone.
3. The onlooker: I want to demonstrate my thinking and abilities in a publicly facing forum as a stand in for or augmentation of credentials.

In general, I'm interested in thinking in service of the gardener and wanderer rather than the onlooker. For one, the onlooker (again: literally and metaphorically) doesn't inhabit the garden -- they do not participate in its co-constitution. Second, in serving the gardener and wanderer, digital gardening can cultivate an alternative topological arrangement that does not necessarily entail walls. What I'm trying to think through is the relation between public, ecology, and gardening (as a practice). This is what I mean when I say I am thinking about gardening as a socio-spatial metaphor and practice -- can we use gardening to develop a more robust ecology for learning? How is the practice of learning in public related to the co-constitution of what we might call 'alternative ecological arrangements'?

### gardens are tilled and disciplined

Your garden doesn't contain everything -- you've selected seeds and tilled the soil carefully to plant them in the hopes that something grows. While I want to hold on to projection into the future, I wonder what would come from resisting or modulating that selection impulse. I am thinking about this in terms of both form and content:

- Blogs and posts are linear whereas our gardens can be rhizomatic -- what are some alternative approaches to authoring and presenting information? What might these alternatives elucidate for both reader and writer?
- Blogs tend to focus on one topic -- what can we learn from other forms of content curation and production (even as I try to avoid 'content production' as a practice) that are multi-layered and multi-modal? What comes from juxtaposing different kinds of stuff?

What I'm wondering about and thinking towards is not so much the standard blog augmented by personal musings. I'm instead wondering about how differing modalities of thought transposed onto other content might elucidate new forms of knowledge practicing(s) (I'll leave this open ended).

### digital garden v. digital gardening

I want to stick with the term digital garden by dragging along or pulling into focus the practice of digital gardening. I want to reshape some of the issues I've outlined above by continuing to practice digital gardening. This means experimenting with low friction authoring, alternative data arrangements that lack explicit hierarchy, and presentational layers.

### further reading

- [Tom Critchlow's Blog](https://www.notion.so/ifdesign/examples-abbedb239c984882ba76301fb2158455#b65447849b4740fb9960707e9ed1f648)
- [johno's digital garden starter](https://www.notion.so/ifdesign/examples-abbedb239c984882ba76301fb2158455#30fa6dd5d4b24f4294b3111d08925e3d)
- [Setting up your own digital garden with Jekyll 🌱](https://maximevaillancourt.com/blog/setting-up-your-own-digital-garden-with-jekyll)

digital garden tooling

styled system, variants, overrides

(re)thinking the digital garden

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.


blog relaunch


My personal website, *inadequate futures*, has been rewritten a total of three times. I was inspired to pick html and css back up after learning about static site generators, specifically [Jekyll](https://jekyllrb.com/), after reading about [Alex Gil's 'Ed' theme](https://elotroalex.github.io/ed/about/) for minimal editions (I am in the process of porting this over to Gatsby. More on that at the end of this post). The first version of the site was launched about a year ago on GitHub pages with the help of [Hugo](https://gohugo.io/), which quickly shifted my focus from building *my* website back towards the world of frontend development. Not long after launching '[if-ver01](https://inadeqtfuturs.github.io/),' I started reading about the JAMStack and React, which offered what seemed like a robust alternative for turning markdown files into blog posts.

For the second version of the site, I moved to [Gatsby](https://www.gatsbyjs.org/), which I chose after looking around for other blogging frameworks built on Javascript. I liked Gatsby because it remained atomistic and modular (things that initially attracted me to Hugo), but also because it was built on React, providing the opportunity to learn one of the major javascript frameworks. Having worked with Gatsby for the past year, I think it offers some great features for anyone developing for the modern web:

### JAMStack and Modern JS Technology

The [JAMStack](https://jamstack.org/) undergirds much contemporary frontend web development. By leveraging javascript, APIs, and markdown, static site generators are able to deploy lightweight and fast websites without much data overhead. Gatsby, in my experience, offers the best modern JAMStack experience out of the box with prefetched links, page caching, and a pre-installed service worker. By prefetching content (i.e. rendering pages before you've even clicked on the links), Gatsby offers a fast and smooth navigation experience. Additionally, between the client side rendering and pre-installed service worker, users nearly always have access to a minimum-viable version of the website.

This is all to say that Gatsby helps developers build simple progressive web apps out-of-the-box. A [progressive web app](https://developers.google.com/web/progressive-web-apps/) functions on your smart phone or tablet like any other app--you can add it to your homescreen, it's fully immersive, and you can use it on- or offline. For my blog, and for future projects, it was important for me to develop for mobile and the modern web. Gatsby solved many of the problems I was having trying to implement many of these technologies with other static site generators.

### Easy to Set Up // Easy to (Re)Use

Gatsby has some of the best documentation for learning a completely new stack, teaching developers a variety of technologies along the way. I began working with Gatsby with little to no formal javascript experience. However, getting up and running was anything but daunting. Not only does the [tutorial](https://www.gatsbyjs.org/tutorial/) walk you through everything you need to start building a simple blog, it also introduces users to Gatsby's layout logic, GraphQL, and Google's Lighthouse audit.

Installation is as easy as running a handful of commands in terminal, but what I really like about Gatsby is the reusability of components and project structure. Because the frontend is largely data agnostic--GraphQL will give you whatever data you ask it for and then you simply pass it into [jsx](https://reactjs.org/docs/introducing-jsx.html)--users are able to reuse, refactor, and upgrade components to fit whatever particular use case they're working on. Updating *inadequate futures* was as easy as starting a new Gatsby project, dropping my content into the project root, and utilizing some existing components to get up and running.

### GraphQL and the Mesh

Gatsby utilizes [GraphQL](https://graphql.org/) to fetch data. Prior to working with Gatsby, I had never used a query language before. Returning to work on a few WordPress projects over the past six months, I can't quite imagine frontend development *without* GraphQL. Whereas WordPress offers a largely 'what you see is what you get' editing experience, GraphQL and Gatsby's frontend are  uncoupled. This means that you can query whatever information you might need from a markdown file, and inject it wherever you want it on the front end.

As a really simple example, here's a simplified snippet for querying individual blog posts:

```js
markdownRemark(fields: { slug: { eq: $slug } }) {
  html
  excerpt(format: PLAIN)
  frontmatter {
    title
    author
    date(formatString: "MMMM DD, YYYY")
  }
}
```

Here, I'm just asking GraphQL to give me the body of the markdown file, a plaintext formated version of the body to pass into an SEO component, and I get some basic information from the frontmatter, including a formatted date string. I then pass this into various post and excerpt components, allowing me to display the data using html and css:

```js
<h2 dangerouslySetInnerHTML={{ __html: title}} />
<p><i>{date} by {author}</i></p>
<div>
  { ... }
  <p dangerouslySetInnerHTML={{ __html: html }} />
</div>
```

While I'm only querying my own markdown files, GraphQL *can* be used with other content management systems, including WordPress, Drupal, and others. This means that you can utilize Gatsby with existing projects even if they're already tied to a CMS. In the future, I'd be interested experimenting with this approach, allowing for editors and developers to work in tandem without committing wholesale to something like WordPress.

### What's Next

I rewrote *inadequate futures* to integrate some of the lessons I learned about javascript, react, and component composition over the past year or so. I'm currently at work putting this knowledge into practice by porting the [Jekyll theme Ed](https://elotroalex.github.io/ed/) over to Gatsby with the sense that editors would be interested in integrating some of the above advantages of the modern JAMStack into their minimal editions and other humanities projects. I see this as an effort to contribute to both digital humanistic inquiry and add to the growing number of Gatsby starters.

I made this section of the website to start documenting some of my experiences with Gatsby, React, and web development. If you'd like to talk about static site generators, Gatsby, or [my research](https://www.inadequatefutures.com), don't hesitate to reach out on [twitter](https://twitter.com/inadeqt_futurs) or via email (alexj [dot] christie [at] gmail [dot] com).