Design Tokens are a good way to help me think systematically about the entire ecosystem I am building. It's a very responsive feedback loop, where the mantra "less is more" rings true.

Now that I have my basic Gatsby site set up, I’d like to start defining my CSS styles. I prefer to start with styles because they have global impact, and there is an abundance of shared code ( several components on your site should use the same colors, typefaces, spacing units, etc ). It’s also an opportunity for me to implement DRY (don’t repeat yourself) principles into my code base immediately.

If you’ve been in the dev world for any length of time, you're sure to have come across heated debates about how CSS gets implemented, particularly when it’s used with Javascript. There are CSS Modules, CSS in JS, Styled Components, SASS, and even particular class naming convention systems like BEM. The landscape is vast. And some of these can even be mixed and matched, depending on your needs. Most recently, I’ve discovered a method called Design Tokens. Design Tokens are essentially key, value pairs that allow you to create meaningful names and scalable values for your site’s global CSS values. The following illustrates the general set up of Design Tokens and how they flow throughout your app.

By using Design Tokens, you can create a single source of truth for all of your site styles:

Global, Consistent Values

Setting up the Design Tokens File

Now, how do I decide what styles to define in here? My approach is quite simple: if a style is shared across multiple components then it should probably go in here. I’ll be using my design system to identify which styles should go in here:

To start, I need to define Design Tokens for color, spacing, and typography. For my naming conventions, I’ll be borrowing from Storybook’s approach. Storybook is a platform for building documented design systems and code components. I find their naming and structure memorable and easy to use. Altogether, here are my design tokens:

export const color = {
  // palette
  primary: "#1200E5", // blue background
  yellow: "#F0C800",
  green: "#00E5BF",
  magenta: "#E500BF",
  // monochrome
  black: "#19191A",
  gray9: "#3D3D40",
  gray8: "#7D7D82",
}
export const spacing = {
  padding: {
    xxsmall: 5,
    xsmall: 15,
    small: 30,
    medium: 45,
    large: 60,
    xlarge: 75,
    xxlarge: 90,
    xxxlarge: 120,
  },
  borderRadius: {
    large: 20,
    medium: 15,
    small: 8,
    xsmall: 4,
  },
}
export const typography = {
  family: {
    display: "GT-Pressura-Pro-Mono-Regular",
    displayBold: "GT-Pressura-Pro-Mono-Bold",
    primary: "Calibre-Regular",
    code: `"IBM Plex Mono", monospace`,
  },
  weight: {
    regular: "400",
    medium: "600",
    bold: "800",
  },
  size: {
    s1: 1.3,
    s2: 1.6,
    s3: 1.8,
    m1: 2.2,
    m2: 2.6,
    l1: 3.4,
    l2: 4.8,
    l3: 6.4,
    xl1: 20,
  },
}

One of the things to notice here, is how I am using numbers for all of my increments. When I end up using them in my components, I’ll be using rems for my typography and px for my spacing. The idea is that I export these styles and then import them into a react component. I can then interpolate the value using template strings. Here’s a pseudo-code example of that:

// Navigation.js
import { color, spacing, typography } from "./styles.js"
const Navigation = () => {
  return (
    <div style={{color: color.magenta, 
                fontSize: `${typography.size.s3}rem`, 
                margin:`${spacing.padding.xxlarge}px`}
                }>
                my navigation 
    </div>
  )
}

Driving the point home

Additional Resources: Theme UI

I can't recommend Gatsby's tutorials enough. I regularly reference them to remind myself of techniques and syntax. Additionally, Gatsby is kicking off "100 days of Gatsby" in 2020 to onboard new developers.

In my previous code post, I gave an overview of Gatsby, Contentful, and Netlify, and how these three technologies will form the foundation for my new blog, Bytesize Dev. To initiate my project, I’ll start by creating a new Gatsby site. I won’t be walking through a comprehensive setup guide, but Gatsby does have great docs and tutorials for getting started. Furthermore, Gatsby offers a wealth of templates to build from. I particularly like their hello world template. It’s a bare essentials setup that gives you the structure of a basic Gatsby site, without any extra bells or whistles. Which, for me, means less I have to remove in the long run. Once I’ve got the Gatsby CLI installed, I’ll run the following command to initiate a new site:

I can also see my site on my localhost by running:

cd bytesize-dev
gatsby develop

Gatsby's File Structure

However, I don’t want to just build all of my UI in each page file. I want my code to be shareable and abstracted so it can be used for multiple purposes. In other words, I want my site to really leverage the power of React. So, I’m going to create a components folder in my src folder. All of my files in the components folder will be used to construct my site’s User Interface, such as Navigation, Footers, and Text Fields.

The Gatsby Config File

Using GraphQL in Gatsby

http://localhost:8002/___graphql

On the left, I can see the “Explorer” panel. This shows me all of the data currently available to my Gatsby site. I can also see some instructional comments that tell me how to get started with this interface. As always, Gatsby supplies thorough docs that explain the inner workings of their GraphQL layer and how to use it.

Our First Gatsby Plugin

http://localhost:8002/___playground

If I go to that link, I’ll see my new Gatsby Playground. Awesome. I’ll be using this IDE ( Integrated Developer Environment ), throughout the course of my project to test out my API requests. I’ll also be using it to explore what data I have available to me and how I need to structure my requests to get that data.

Moving Forward

With code, you can hardly anticipate all of the needs up front. However, I find it very helpful to consider the larger architectural requirements before starting a project. The main reasons are that it helps you consider how your project may need to scale and what expertise is needed.

Welcome back to round two of the open code process around Bytesize Dev, a blog I’m building for developers. In my previous post, I spoke about the JAMstack, and how this collective of technology is driving the next generation of website development and management. In this post, I’ll be covering my tools of choice for my website. And then, from here on out, we’ll be jumping into the code and implementation. So, before building a website, I like to understand what kind of workflows, information architecture, and customization this website will need to support. At a high level for my blog, I need a way to display content ( Javascript ), a way to manage content ( a CMS ), and a way to deploy my site ( a hosting service ). At the risk of getting lost in the weeds, I’d like to dive into each of these areas for just a minute.

The UI and IA Layer

The Content Management Layer

The Deployment Layer

Have no fear, the triforce is here

Gatsby

Contentful

Netlify

Moving Forward

I also try to map out my components up front, deciphering which pages and user workflows they will need to accommodate. This helps me to have a clear folder structure.

Over the next few months, I will be documenting my process for a website I am building called “Bytesize Dev.” The website will be a blog full of code snippets, musings, and methodologies for developers. In general, when I set up a new dev project, my first considerations are — what tools am I using to build this? And, what is my workflow?

Through the years, I have narrowed my essential tools down to React as a Framework, and more recently the JAMstack as an approach. The JAM stands for Javascript, API’s, and Markup. I find JAMstack WTF to be a helpful site for any one who is new to this idea. At it’s core though, JAMstack aims to empower developers to make and deploy secure, performant sites without all of the hassle of strenuous database management and devops.

The JAMstack Breakdown

A Quick Detour into Markup

Where to From Here?