DEV Community: Babs Craig

The JavaScript Execution Context, Call-stack & Event Loop

Babs Craig — Mon, 22 Jul 2019 11:14:08 +0000

This is going to be a long one - grab a ☕️ and dig in...

Have you ever looked at a piece of JS code and known what the result of executing that piece of code would be, and yet deep in your mind, you knew you had no idea how the result came about. Or perhaps you've looked at some asynchronous code like an on click handler or an AJAX call and wondered how the heck the callback function knew when to fire?

JavaScript is everywhere. In the browser, on the desktop, in mobile apps, in everyday things around us. Atwood's Law seems to fulfill itself more and more each day - "Any application that can be written in JavaScript, will eventually be written in JavaScript."

It's not news that JavaScript's reach extends far and wide and with it, the number of developers who use it on a daily basis, and yet, a deep knowledge of JavaScript is often hard to come by. This is because JS is one of those languages where you can know just enough to get by and never bother to go really deep.

This article is about deepening our knowledge of JS by understanding how our JS code gets executed. These laws are governed by the interaction of the Execution Context, Call-stack and Event Loop. The interplay of these three concepts is what allows our code to be executed. A good understanding of these foundational concepts is crucial in order to understand more advanced stuff such as scopes and closures. Let's step right in.

Whenever you write JavaScript and run it, you are relying on an engine to execute the code for you. This engine can vary depending on the environment you are in and even between different implementations of the same environment. For instance the Chrome browser and Firefox browser use different engines (V8 for the former and SpiderMonkey for the latter).

The engine is what takes your code and executes it. It follows a series of steps - the first of which is to create a global execution context. This global execution context is usually an anonymous function that serves as a space to run all the code you have written.

The Execution Context

var a = 42;

function foo(num) {
  return num * num;
}

var b = foo(a);

Let's look at a fairly straightforward piece of code. In this sample, we assign a number value to the a variable, we declare a function foo and then we call foo passing in a as a parameter and then store the return value of that function in b. If I asked you what the result of this piece of code is, I'm sure you'd have no problems following along and getting the correct answer. If however, I asked how JavaScript arrived at the answer, you might not be able to give a straight answer. Let's examine the answer to that question together.

The first thing the engine would do, in the code above would be to create an execution context. There are precise steps which the engine follows and there are two phases to this. The creational phase and the execution phase.

The first time the code runs, a Global Execution Context is created. During this creational phase the engine will do a couple of things:

Create a global object. This object is for instance, called window in the browser or global in Node.
Create a this object binding which points to the object created above.
Set up a memory heap for storing variables and function references
Store function declarations in the memory heap above and store every variable within the context with undefined being assigned as the value.

In our example, during the creational phase, the engine will store the variables a and b and the function declaration foo. It will also assign undefined to both variables initially.

After this phase is done, the engine moves to the execution phase. During the execution phase, the code is run line by line. It is in this phase that variables are assigned their values and functions are invoked.

If there are no function calls in your code, the story ends here. However, for every function you call, the engine creates a new Function Execution Context. This context is identical to the one above, but instead of creating a global object, this time around an arguments object is created containing a reference to all the parameters passed into the function.

To return to our example above, during the execution phase, the engine would first get to the variable declaration, a, and assign the value 42 to it. Then it would move on the line where we assign a value to b. Seeing that that line makes a function call, it would create a new Function Execution Context and repeat the steps it followed above (with an arguments object being created this time around).

But how does it keep track of all these execution contexts? Especially in a scenario where there are multiple nested function calls or conditionals? How does it know which one is active or which one has been completely executed?

This introduces us nicely to our next concept - the Call-stack.

The Call-stack

The call-stack is a data structure used to keep track of and manage function execution in a piece of JS code. It's job is to store of all the execution contexts created during code execution and to record which execution context we're actually in as well as those that are still remaining on the stack. When you call a function, the engine pushes that function to the top of the stack, then creates an execution context. From our exploration of the execution context above, we know that this context will either be the global one or a function execution context.

As each function runs, the call-stack pops it off and moves on to the next function until it is empty and all functions have been run.This sequence is known as LIFO - Last In First Out.

When a function is called, a stack frame is created. This is a location in memory where parameters and variables are stored (remember the memory heap we talked about above?). This memory gets cleared when the function returns (implicitly or explicitly) and the whole context then gets popped off the call-stack.

Execution contexts are popped off the stack one by one as they complete execution with each one creating a stack frame and when we throw an error, we get what is known as a stack trace, which is what it sounds like - tracing all the execution contexts from the point of the error through to all the contexts we have passed through.

It is also possible to blow the call-stack by having more frames than the stack is designed to hold. This could happen when calling a function recursively without some sort of exit condition or as I'm sure we have all done at some point in time - when an infinite for-loop is run.

Take a look at this piece of code:

function thirdFunc() {
  console.log("Greetings from thirdFunc()");
}

function secondFunc() {
  thirdFunc();
  console.log("Greetings from secondFunc()");
}

function firstFunc() {
  secondFunc();
  console.log("Greetings from firstFunc()");
}

firstFunc();

// Greetings from thirdFunc()
// Greetings from secondFunc()
// Greetings from firstFunc()

Again, how do we get the result we did?

When we run this piece of code, the first thing the engine does is make a call to the call-stack and place a main() or global() function on the call-stack. This is the main thread of execution of your JS code. The execution context we described in the previous section will enter the creation phase first and then the execution phase will be invoked. When the engine gets to the call to firstFunc() during this phase, the call-stack will be referenced again and the function execution context for firstFunc() will be pushed onto the call-stack on top of main() (Step 2 below).

Now the engine will start to execute firstFunc() since it is at the top of the call-stack. It will in turn create a local execution context and local memory allocation to store the variables, parameters and function declarations in this new context. (The concept of scope is tied to this).

The very first line of firstFunc() calls secondFunc(). At this point, the engine will again reference the call-stack and place secondFunc() at the top of the stack repeating the process again. In secondFunc() the first line again references another function called thirdFunc() and the process is repeated one more time.

Now in thirdFunc(), we do not make any function call, instead we simply console.log the string "Greetings from thirdFunc()". This gets executed and then since there are no more instructions in the function, it returns implicitly. At this point, the call-stack pops thirdFunc() off (Step 4 above) and now secondFunc() is at the to the top of the stack. The engine will continue where we left off and console.log the string "Greetings from secondFunc()". Again, as there are no more instructions in this function, the function will return and call-stack will pop off secondFunc() bringing us back to the execution context of firstFunc() where we continue and log out the string "Greetings from firstFunc()". After executing that code, firstFunc() is popped off and control returned to the main execution context which has no further instructions to execute and will be popped in turn. Once our stack is empty, the program will stops running.

The nature of the call-stack reflects the fact that JavaScript is essentially single threaded and only one execution context can be run at a time. This means that while a function is being executed, the engine cannot run another context at the same time. It also means that every time a function is pushed onto the call-stack, it then becomes the active executing context and takes control flow away from whatever function called it, until it returns either explicitly (with a return statement) or implicitly (when all instructions have been executed).

Now if this was where the story ended, then JavaScript would not be much use in anything but the most trivial of applications and certainly not in a web application with a multitude of concurrent events firing at once - user inputs, resource requests, API calls. Each event would block the other until it had finished running. This would mean that when a function was called - perhaps one making a request to a server for an image - nothing else could happen on the page till that image was loaded. If you clicked a link before the image got loaded, the event would not be handled until after the image got loaded.

So how then do we achieve asynchronous JavaScript with it's illusion of multiple things happening all at once? Enter the event loop.

The Event Loop

As we've seen above, the JavaScript engine can really only do one thing at a time. It starts at the top of our code and works it's way down creating new execution contexts as required and pushing and popping them onto and off of the call-stack.

If you have a blocking function that takes a long time to execute, then the browser cannot do anything during the time that the function is at the top of the call-stack. No new execution contexts or code execution can take place. This means that even user input like scrolls and button click events would not work.

Instead, when we have a function that might take a long time to complete, oftentimes we provide a callback function. This function encapsulates the code we would like to run at a later time when the blocking action (e.g a network call) has been resolved. This allows us to return control to the JS engine and defer the rest of the execution until after the call-stack has been cleared. This is the concept of asynchrony in JavaScript.

Let's tweak our code from before into something requiring this new concept:

function thirdFunc() {
  setTimeout(function() {
    console.log("Greetings from thirdFunc()");
  }, 5000);
}

function secondFunc() {
  thirdFunc();
  console.log("Greetings from secondFunc()");
}

function firstFunc() {
  secondFunc();
  console.log("Greetings from firstFunc()");
}

firstFunc();

// Greetings from secondFunc()
// Greetings from firstFunc()
// approx. 5 seconds later...
// Greetings from thirdFunc()

In the code above, the execution begins as in the previous example. When the engine reaches the third function however, instead of immediately logging the message to the console, it invokes setTimeout() which is an API provided to us by the browser environment. This function accepts a "callback" function which will be stored in a structure we have not discussed yet called the callback queue. thirdFunc() will then complete it's execution, returning control to secondFunc() and firstFunc() in turn. Finally after at least 5 seconds (more on this below), the message from thirdFunc() is logged to the console.

In JavaScript, the mechanism by which we achieve asynchronous execution of code is via environment APIs (Node and the browser both provide certain APIs that expose low level features to us), the callback queue and the event loop,.

Concurrency (or the illusion of it) is achieved via these extra mechanisms.

Just as we said the call-stack was used to keep track of the currently executing function context, the callback queue keeps track of any execution contexts that need to be run at a later time. Such as a callback passed to a setTimeout function or a node async task. While our code is being invoked, the event loop periodically checks if the call-stack is empty. Once the call-stack has run all the execution contexts in our code, the event loop takes the first function that entered the callback queue and places it on the call-stack to be executed. Then repeats the process again continually checking both the call-stack and the callback queue and passing functions from the callback queue onto the call-stack once the call-stack is empty.

Remember when we said the setTimeout callback would run "at least" 5 seconds from the point of invoking setTimeout? This is because setTimeout does not just insert it's code into the call-stack when the timeout completes, it must pass it to the callback queue and then wait for the event loop to place it onto the call-stack when the call-stack is empty. So long as there are still items in the call-stack, the setTimeout callback will not be run. Let's take a look at this in detail.

Our code runs as above until we get to the thirdFunction at this point, setTimeout is invoked, taken off the call-stack and begins a countdown. Our code continues on to secondFunc and firstFunc and console.logs their messages in turn. In the meantime, setTimeout completed it's countdown almost immediately - in 0 seconds - but there was no way for it to get it's callback directly onto the call-stack. Instead when it completed it's countdown, it passed the callback to the callback queue. The event loop kept checking the call-stack but during that time secondFunc and in turn firstFunc occupied space on the call-stack. It was not until these two functions completed execution and the call-stack was emptied, that the event loop takes the callback function we passed to setTimeout and places it on the call-stack to be executed.

This is why sometimes you find the pattern of calling setTimeout with 0 as a way to defer execution of the code in the callback passed to it. We simply want to ensure that all other synchronous code runs before the code in the setTimeout callback.

It's important to also note that a "callback" is a function that's called by another function, but the callbacks we've discussed above, such as the one that is passed to setTimeout are "asynchronous callbacks". The distinction being that async callbacks are passed to the callback queue to await being placed (by the event loop) onto the call-stack for execution at a later time.

And with this, we've covered the major concepts when it comes to JavaScript code execution and how the JavaScript engine handles asynchronous code. We've seen that the JS engine is single threaded and can only execute code synchronously. We've also seen the mechanism for achieving asynchronous code without blocking the thread of execution. We also have a better understanding of the order in which functions are executed and the rules surrounding this process.

These concepts can be a lot to understand but it's worth taking the time to really grasp them as they form the basis for an in-depth knowledge of JavaScript. Not just the var a = 2 syntax but a wholistic view of what exactly happens when JavaScript takes that syntax and runs it. These concepts also act as a building block for a greater understanding of other concepts such as scopes and closures. A subject like this requires further resources so feel free to dig in below:

From Chrome To Firefox Quantum in 4 Easy Steps

Babs Craig — Wed, 06 Mar 2019 17:16:20 +0000

Bookmarks, extensions, history and more - How to pull the plug on Chrome and jump right into Firefox

I recently got the 15 inch, 2017 MacBook Pro, a radical upgrade from the 3 different MacBook Airs I’ve used for the last 6 years. It’s been a wonderful new world of retina color, huge bump in screen real estate and faster operating speeds. But this is not a review of the MacBook Pro, it’s a story of how the morning after, while running my usual developer workflow (Chrome, Visual Studio Code and iTerm), my MacBook Pro started to run hot, so hot the fans started blowing loudly. I immediately checked Activity Monitor and lo and behold, Google Chrome was the culprit. I’d heard before how much RAM Chrome loves to hog and it seemed that it was gunning for all 16GB of memory that I had.

This reminded me that I’d tried several times to get weaned off Chrome for a variety of reasons. The first is that I’ve found Firefox Developer Edition to have a better user experience when it comes to developer tools. I just like the look and feel of debugging a web app in Firefox. I’m also a tad bit nostalgic about the browser I used as a kid when the internet was a new and exciting place to me. I’d also read that the new Quantum browser used up to 30% less memory than Chrome and perhaps most importantly, I like the way Firefox treats user privacy and shies away from aggressive collection of data and tracking.

That said, I’ve always found myself drawn back to Chrome because I have all my browser history, bookmarks, extensions and passwords in Chrome from years of using it as my daily browser. Every time I tried it would end up going go like so:

This time around though, I promised myself that I would make the jump and give Firefox a fair shot at winning me over. Here’s how I finally got everything over from Chrome into Firefox Developer Edition. If you’re like me and looking to try out Firefox for a bit to see if it sticks, then follow the steps below and you’ll be up and running in no time. With the exception of the last step, which I haven’t had the opportunity to try on another laptop, most of these instructions will work on any machine regardless of OS.

Let’s get cracking.

Step One: Download Firefox

The easy part - download your new browser. You can get Firefox Quantum Developer Edition here. Follow the instructions and fire it up.

Step Two: Bookmarks & History

Let’s import our bookmarks and history. This will ensure you feel more at home in Firefox. Autocomplete in the url field, all your sites just a click away and bookmarks from those sites we promised we would visit one day 😉 . To do this, click on the stacked books icon in the toolbar, select Bookmarks scroll all the way down to Show all Bookmarks (or cmd+shift+B) and click on the star icon. Select Import Data From Another Browser and choose Chrome.

Make sure you quit Chrome. You might also want to check your Activity Monitor and make sure no Chrome processes or helpers are running in the background. Now you can select the items you want to import.

After selecting the data you want, click continue and let Firefox do it’s work. Once the process is compete, you should have your cookies, history and bookmarks in Firefox.

Step Three: Extensions

The next thing is our extensions. You can open up the extensions manager in Chrome and then in your Firefox browser, search for any extensions you want to use. I found a Firefox counterpart for every Chrome extension that I intended to keep. I also used this process as a time to do some house-keeping and pull a Marie Kondo on my extensions list. You might be surprised at the number of extensions that no longer serve a useful purpose or “spark joy” 😂 . It’s also a great idea to keep extensions light, especially those that run in the background. They add to your browser’s overall load and affect how much memory is consumed. You can find Firefox "Add-ons" as they're called, here

Step Four: Passwords and Login

This step is a bit more involved but we’ve come so far and we can do it. This one was really big for me. I have dozens of variations of my password and I have come to rely on a carefully worked out system, where the browser takes care of some of them and the rest I carry in my head or delegate to social logins. This proved to be my undoing the last time I tried to move over from Chrome as I just got tired of having to reset so many account passwords.

First, get your passwords exported from google in a .csv file. This can be done by going into Chrome and going into your settings. Click on passwords in the Autofill section and then click the three dot menu button and select Export passwords. Make sure to keep this file local. Don’t put it in any shared folders. It’s extremely sensitive information.

You’ll be asked to enter your computer password. Do this and choose the target local folder (see above), leave the file type as .csv and input “password” as the name of the file.

Next, you’ll need to install a command line tool called ffpass. You can find the GitHub repo here.

To install this tool, you’ll need Python 3. If you don’t have version three, you can use homebrew by running:

$ brew install python3

This will also install pip3 which is the python installer. If your MacBook is setup like mine, you’ll need to change the command line aliases for both python and pip commands to point to the newly installed python3 and pip3 and not the python and pip versions 2.* which ships with MacBooks by default.

To do so, open your .bash_profile and set up some new aliases.

$ open ~/.bash_profile

In the text file that appears add these two lines.

alias python='python3'
alias pip='pip3'

Now we can install ffpass by running:

pip install ffpass

It shouldn’t take long to install, but once it does, we can now import our password.csv file’s data into Firefox . Make sure Firefox is closed and then enter the following command.

ffpass import --from /path/to/passwords.csv -d /Users/YOUR_HOME_FOLDER_NAME_HERE/Library/Application\ Support/Firefox/Profiles/91ybe9eg.dev-edition-default

What we’re doing here is importing from the path where our passwords.csv file is and writing to the location where Firefox can view and consume the data. Be sure to permanently delete the password file once this command runs as this is sensitive information and shouldn’t sit around on your computer or be shared with anyone.

And that’s it! Open up Firefox again and it should feel more like the browser you’re used to. You’d still be logged out of most your accounts but the form autofill data should have you easily setting things up again with just a click.
I’m hoping to use Firefox for a few weeks and see how I feel and more importantly, how my computer feels about it. So far I haven’t really missed Chrome and even with my web development, I’m finding the Firefox environment to be a welcome change. Let’s see how it goes.

How about you? Are you planning on giving Firefox Quantum a try or have you done so already? Let’s compare notes in the comments below!

Content Management with Gatsby, Netlify and Contentful

Babs Craig — Fri, 22 Feb 2019 02:55:23 +0000

Gatsby, Netlify and Contentful - The Triple Tag Team For Content Management Success

I've been using Gatsby for the better part of 6 months now. And it's quickly become my go-to for building static sites. The advantages are huge. You get:

A lot of configuration and boilerplate done out of the box.
Speed, SEO and performance optimizations.
A great community, great docs, a growing plugin ecosystem.
And my personal favourite - getting to write all the React & GraphQL code I want.

It's been a great developer experience, to say the least. However, when building static sites, one of the major concerns in choosing a tool is how content gets updated on the site. Lots of older platforms have solved this one way or another, Wordpress being the most popular of them, but using the triple threat of Gatsby, Netlify, and Contentful, we can build a pretty good alternative to the traditional CMS tools out there while retaining our SEO compatibility.

This article will show you how you can set up a system for managing content on any page of your Gatsby site. In our case, we'll be using Gatsby's powerful gatsby-node API to pull in content from Contentful and to dynamically generate pages. You can also use Contentful data on any existing page via the provided graphql queries.

Let's begin.

You'll need the gatsby-cli tool to get started. Run npm i -g gatsby in your terminal and once that has run, create a new project with

$ gatsby new gatsby-contentul-blog

This will create a new Gatsby project in a folder called gatsby-contentful-blog. cd into the new project and run gatsby develop. Now you have the default Gatsby starter homepage:

Open up the project in your favourite text editor and navigate to the pages folder. Let's tweak some of the content in the index.js: (You can just copy and paste this in)

    import React from "react";
    import { Link } from "gatsby";

    import Layout from "../components/layout";
    import Image from "../components/image";
    import SEO from "../components/seo";
    import "./index.css";

    const IndexPage = () => (
      <Layout>
        <SEO title="Home" keywords={[`gatsby`, `application`, `react`]} />
        <div className="home">
          <h1>Hello There</h1>
          <p>Welcome my awesome blog</p>
          <div>
            <div
              style={{
                maxWidth: `300px`,
                margin: "0 auto 1.45rem"
              }}
            >
              <Image />
            </div>
          </div>
          <Link to="/blogposts/">View all posts</Link>
        </div>
      </Layout>
    );

    export default IndexPage;

Next, find page-2.js and change the filename to blogposts.js. Gatsby uses the name of any file in the pages folder as a route name and will make the exported React component available on said route. This means we now have a /blogposts route. We'll come back to this file later but in the meantime, let's also change a few values in the gatsby-config.js file. This file sits in the project root.

siteMetadata: {
        title: `My Awesome Blog`,
        description: `An awesome blog displaying my awesome posts.`,
        author: `YOUR_NAME`,
    },

Great! We now have our basic site set up. So we'll go to the Contentful website and create a new account. It's pretty painless and you should be set up in no time. By default they provide an example space but let's create a fresh one for the project.

Open up the sidebar and click on Create Space. Choose the free option and give your space any name. I'll call mine gatsby-blog. Select the empty space option, click Proceed to confirmation, and confirm your options.

After confirming, on the dashboard, click either the "Create Content Type" button or the "Content Model" button in the header and fill in the form that appears. Let's call the content type Blog Post and leave the API Identifier as is. Enter any description you'd like.

After creating the content type, we'll start to add some fields to it A field is a building block for our content. If you have a blog post for instance, a few fields could be the title, the body, the tags and an image. This will generate a form that you'll fill later on when we start to create actual blog posts. Follow the next steps to create a title field.

Click on the Add Field button to the right of the dashboard.
Select Text as the type of field you want.

Add another field. Select Media as the type instead of Text and call it image.
Add a tags field by selecting Text as the type. Give it tags as a name, and then select the list option on the screen below since we will be storing a list of tags in this field.

Lastly, create a slug field. Start by selecting Text as the type and call it slug. This time, instead of clicking Create as above, click on Create and Configure. On the next screen go to the Appearance tab and select slug as the way the field should be displayed. Also, in the Validations tab select unique field to be sure that no two blog posts have the same slugs

Your content model should now look like this:

A content model is like a schema that our actual content will follow. You can create all types of models such as case studies, blog posts, product data, page content and so on.

Save your changes and click on the Content button at the top of the page and select Add Blog Post. I'm going to add three posts with placeholder data, feel free to add as many as you'd like. For images, you can grab some free, open license ones from unsplash.com. Notice how the slug field gets auto-generated as you enter the title? This will come in handy later.

Awesome! That was a lot but we're halfway there...

At this point we have our first couple of blog posts and it's time to bring them into our Gatsby site. For this, we'll depend on Gatsby's awesome GraphQL API for pulling in the data. Let's work on that next.

Go to your settings in Contentful and click on the API Keys option in the dropdown menu. Create a new API Key and keep the details close by.

Back in your terminal, install the Gatsby plugin we need to start pulling in our Contentful data.

$ yarn add gatsby-source-contentful

We'll be using Contentful's Content Delivery API since we want to retrieve published data only, so be sure to grab the Content Delivery API key and not the Content Preview API key.

In your gatsby-config.js file, add the configuration object to the plugins array:

plugins: [
        ...
    {
      resolve: `gatsby-source-contentful`,
      options: {
        spaceId: `YOUR_SPACE_ID`,
        accessToken: `YOUR_CONTENT_DELIVERY_API_KEY`
      }
    }
],

You should restart your development server again at this point for the new configs to kick in. When the server restarts, gatsby-source-contentful's GraphQL queries will be available to use.

We can easily test if everything is working by using the GraphiQL playground that Gatsby provides for us. Open http://localhost:8000/___graphql in your browser and run the query below by pasting it into the left window on the page. The query name is allContentfulBlogPost because our content model is called Blog Post. If we had called it Product or Case Study, then the query made available to us would have been allContentfulProduct or allContentfulCaseStudy.

{
  allContentfulBlogPost {
    edges {
      node {
        id
    slug
        title
        tags
        image {
          file {
            url
          }         
        }
      }
    }
  }
}

The gatsby-source-contentful plugin handles all the behind the scenes fetching from the Contentful API using the keys we provided in the gatsby-config file. It then makes a semantically named GraphQL query available to us.

If it all works, you should see the content you added in the results window to the right of the GraphiQL window in JSON format.

Now that we have connected our Gatsby blog with our Contentful data, we can start building the pages for the blog. Gatsby provides us with a file called gatsby-node.js. This file can be used to dynamically add pages to your site. When Gatsby runs, it will look at the code here and create any pages you tell it to. In the gatsby-node.js file, let's place the following code:

const path = require(`path`);
const slash = require(`slash`);

exports.createPages = ({ graphql, actions }) => {
  const { createPage } = actions;
  // we use the provided allContentfulBlogPost query to fetch the data from Contentful
  return graphql(
    `
      {
        allContentfulBlogPost {
          edges {
            node {
              id
              slug
            }
          }
        }
      }
    `
  ).then(result => {
      if (result.errors) {
        console.log("Error retrieving contentful data", result.errors);
      }

      // Resolve the paths to our template
      const blogPostTemplate = path.resolve("./src/templates/blogpost.js");

      // Then for each result we create a page.
      result.data.allContentfulBlogPost.edges.forEach(edge => {
        createPage({
          path: `/blogpost/${edge.node.slug}/`,
          component: slash(blogPostTemplate),
          context: {
                        slug: edge.node.slug,
            id: edge.node.id
          }
        });
      });
    })
    .catch(error => {
      console.log("Error retrieving contentful data", error);
    });
};

This module exports a function called createPages. This function has two parameters, graphql and an actions object. We extract the createPage action then call the same Graphql query we ran in the GraphiQL playground earlier. We take this result and for each result (each blog post) we call the createPage function. This function accepts a config object which Gatsby reads when rendering the page. We set the path equal to the concatenated string "/blogpost" plus the slug. Notice that we also reference a template file at ./src/templates/blogpost.js, not to worry, we'll create that file soon.

At this point, kill your server and start it up again. If you enter a dud route like http://localhost:8000/some-non-existent-route/ you'll see Gatsby's development 404 page. This page has a list of all the routes and as you can see the newly created pages have been set up.

See why we chose to have a unique slug field? Each post has to have a unique route and using slugs looks so much nicer than using nonsensical ID strings in the URL. Also since Gatsby generates a static site which can have a sitemap, it's much better for SEO to have your route names match the kind of content you want to rank for.

Now we can concentrate on building out the actual pages.

Create a templates folder inside your src folder and add a file called blogpost.js. This will be our template component which will be used every time Gatsby calls the createPage function in the gatsby-node.js file.

NOTE: Be sure to restart your server at this point if you get any errors. We're doing a lot of config stuff and Gatsby may need a restart in order to run everything properly.

import React from "react";
import { Link, graphql } from "gatsby";
import Layout from "../components/layout";
import SEO from "../components/seo";

const BlogPost = ({ data }) => {
  const { title, body, image, tags } = data.contentfulBlogPost;
  return (
    <Layout>
      <SEO title={title} />
      <div className="blogpost">
        <h1>{title}</h1>
        <img alt={title} src={image.file.url} />
        <div className="tags">
          {tags.map(tag => (
            <span className="tag" key={tag}>
              {tag}
            </span>
          ))}
        </div>
        <p className="body-text">{body.body}</p>
        <Link to="/blogposts">View more posts</Link>
        <Link to="/">Back to Home</Link>
      </div>
    </Layout>
  );
};

export default BlogPost;

export const pageQuery = graphql`
  query($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      slug
      body {
        body
      }
      image {
        file {
          url
        }
      }
      tags
    }
  }
`;

At the bottom of the page, we export a Graphql query. Gatsby will run this query at runtime and will pass a data prop to BlogPost containing the Contentful data. Note that in this case we are querying a single post and passing the slug along as a filter parameter. We're basically asking for the post which matches the passed in slug (contentfulBlogPost(slug: { eq: $slug })). This slug is made available to us because we passed it in as a page context in our gatsby-config.js.

The rest is straightforward React. We create a component and using the data prop, we populate the page content. We have no styling yet but we'll get to that in a bit.

What we need now is a page to list all the available blog post pages. We cannot rely on going to the 404 page every time we need to read a blog post!

Let's head back to the blogposts.js file in the pages folder that we created at the beginning of this project and tweak it.

import React from "react";
import { Link, graphql } from "gatsby";

import Layout from "../components/layout";
import SEO from "../components/seo";

const BlogPosts = ({ data }) => {
  const blogPosts = data.allContentfulBlogPost.edges;
  return (
    <Layout>
      <SEO title="Blog posts" />
            <h1>{"Here's a list of all blogposts!"}</h1>
      <div className="blogposts">
        {blogPosts.map(({ node: post }) => (
          <div key={post.id}>
            <Link to={`/blogpost/${post.slug}`}>{post.title}</Link>
          </div>
        ))}
        <span className="mgBtm__24" />
        <Link to="/">Go back to the homepage</Link>
      </div>
    </Layout>
  );
};

export default BlogPosts;

export const query = graphql`
  query BlogPostsPageQuery {
    allContentfulBlogPost(limit: 1000) {
      edges {
        node {
          id
          title
          slug
          body {
            body
          }
          image {
            file {
              url
            }
          }
          tags
        }
      }
    }
  }
`;

The pattern should be familiar now.

At the bottom of the page, we export a GraphQL query. The query is the same as the one we used in gatsby-nod.js to generate the blogpost pages. It pulls all the Contentful data of the BlogPost type. Gatsby makes the result of the query available to us in the data object just as with the individual blogpost page. For this page though, we only need the id, title, slug and tags fields.

At this point, let's add some very basic styling. For the sake of this example, we'll just add a few lines to the end of the layout.css file, but in a real-world project you'd probably not want to do this. Go with whatever method you are comfortable with.

/* Add these lines to the end of the layout.css file */
@import url("https://fonts.googleapis.com/css?family=Open+Sans:300,400,600");
html {
  font-family: "Open Sans";
}

header {
  /* We use !important here to override
  the inline styles just for this example.
  in production code, avoid using it where
  possible*/
  background-color: cadetblue !important;
}

header div {
  text-align: center;
}

header div h1 {
  font-weight: 600;
}

.home {
  text-align: center;
}

.home img {
  margin: auto;
}

.blogpost {
  font-size: 18px;
  width: 35em;
}

h1 {
  font-weight: 400;
  margin-top: 48px;
  font-family: "Open Sans";
}

img {
  margin-bottom: 8px;
}

.tags {
  margin-bottom: 24px;
}

.tags span.tag {
  font-weight: bold;
  margin-right: 8px;
  background: cadetblue;
  padding: 2px 12px;
  border-radius: 4px;
  color: white;
  font-size: 12px;
}

.blogpost p.body-text {
  margin-bottom: 32px;
}

p {
  line-height: 1.8;
  color: #929191;
  font-weight: 300;
}

.blogpost a {
  display: block;
  margin-bottom: 8px;
}

.blogposts a {
  display: block;
  margin-bottom: 8px;
}

footer {
  margin-top: 120px;
}

.mgBtm__24 {
  display: inline-block;
  margin-bottom: 24px;
}

Now we have our blog, the next step is to deploy it and make it available for all the world to see. With Netlify this is super easy. Netlify integrates really well with GitHub. In your terminal, run:

    $ git init

Go to your GitHub and create a new repo called gatsby-contentful-blog-starter, then follow the commands for pushing to an existing repository.

    $ git add .
    $ git commit -m 'initial commit'
    $ git remote add origin git@github.com:YOUR_GITUHB_USERNAME/gatsby-contentful-blog-starter.git
    $ git push -u origin master

With your code pushed to GitHub, head over to Netlify and create an account. In your dashboard click on'New site from Git, select GitHub as a provider and go through the authorization process selecting whatever options you feel comfortable with.

Next, select a repo from the list provided. if you can't find the repo we just created, select Configure the Netlify app on GitHub. This will open a popup allowing you to choose the repo you want to authorize for use with Netlify. Follow the prompts till you find the repo. After selecting our blog project, you'll be redirected to the Netlify deploy screen and you should now be able to select the gatsby-contentful-blog-starter repo. As you can see, Netlify knows how to build Gatsby sites so you can just click the Deploy Site button at the end of the page.

Netlify runs Gatsby sites really easy with minimal configuration. Your new site should be ready in a few minutes.

Remember how we had to kill the server and restart it to fetch new data? Well we don't want to have to trigger a redeploy manually every time someone adds or changes content in Contenful. The solution to that is to use Contentful's hooks to trigger an automatic Netlify redeploy of our site (Yup, this triple tag-team thought of everything).

This means that new pages will get added to your blog automatically for each new blogpost you add. Also, if you're using the Gatsby sitemap plugin, the new pages will be included in the sitemap when it get regenerated on deployment, making it much easier to rank for keywords and help your SEO efforts with minimal fuss.

On Netify click on Site Settings and then in the left menu, select Build & Deploy. Look for the Add build hook button and click on it, giving the build hook a name (I am using "contentful") and then click on Save.

Now copy the buildhook url and go back to your Contentful dashboard. Hit the settings dropwdown and select Webhooks. The Webhooks screen already has a template for Netlify in the bottom right. Click on this.

In the form that appears, add the Netlify build hook url and click Create Webhook.

Now go back to the Content page and add a new blog post. As soon as you hit publish, Contentful will make an API call to the build hook you provided. This will in turn, cause Netlify to redeploy your site. Gatsby will pull in the Contentful data all over again, which now includes the new post you added, and create a new page based on the new blog post.

And that's it! It's been quite a journey, but now we have a working blog using three awesome tools that work so well together. From here you can add more content types and pages, expand the site or start a new project from scratch. Happy hacking!

P.S: I know this was quite a long one, and I'm glad to answer any questions you may have if you get stuck. If you do, leave me a line in the comments below or hit me up on Twitter at @thebabscraig, I'm always happy to learn together. I'm also looking to connect with other developers on Instagram, so also hit me up at @thebabscraig there too!