Welcome to Jeremy Builds, a site openly sharing and documenting both the design and code process of Jeremy Barnes through invididual projects.
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.
// for illustration purposes:// a color objectconst color = {primary: "#1200E5",black: "#19191A",gray9: "#3D3D40",gray8: "#7D7D82",}// a react componentconst Header = () => {return (<h1 style={{color: color.primary}}>Hello World</h1>)}
By using Design Tokens, you can create a single source of truth for all of your site styles:
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 = {// paletteprimary: "#1200E5", // blue backgroundyellow: "#F0C800",green: "#00E5BF",magenta: "#E500BF",// monochromeblack: "#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.jsimport { 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>)}
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:
# create a new Gatsby site using the hello-world startergatsby new bytesize-dev https://github.com/gatsbyjs/gatsby-starter-hello-world
I can also see my site on my localhost by running:
cd bytesize-devgatsby develop
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.
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.
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.
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.
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.