Last year I was working on a history page for a client that would showcase all of their achievements and milestones over the last 30 odd years. There was a lot of content and we wanted to feature it in an exciting way. Here's the final product. Lets get straight into it and talk about creating parallax in Gatsby.js!

import React from "react";
import { ParallaxProvider } from "react-scroll-parallax";

export const wrapPageElement = ({ element, props }) => {
  return <ParallaxProvider>{element}</ParallaxProvider>
};

Working with Gatsby can be tricky at times as a frontend developer because since it's a static site generator that creates your site during the build phase you can't reference the window object like you're used to. Parallax is all about scrolling so you need this reference and that's where the gatsby-browser.js come is. It lets you respond to actions within the browser, and wrap your site in additional components, which is exactly what's happening in the code above. We import our parallax library and wrap our page element with it. 

I'm a big fan of Prismic and their simplistic methodology of grouping content into single and repeatable types makes this task a breeze. This page was architected by creating a single type of history page, where all the general page information could be kept. Then inside of this type, we initialize the slice-zone, which is basically just content components that you can pre-define. My slice is called timeline section. Inside the slice-zone we again have the option of placing our content into single or repeatable buckets. I'm going to give my slice zone a nonrepeatable property of year and then within the repeatable zone an image, secondary image, description, and a select dropdown that will toggle the size of our desired text. So back in our Gatsby app, our graphQL query is going to look something like this. 

export const query = graphql`
  {
    prismic {
      allHistorys {
        edges {
          node {
            feature_image
            short_description
            heading
            body {
              ... on PRISMIC_HistoryBodyTimeline_section {
                type
                primary {
                  year
                }
                fields {
                  image
                  secondary_image
                  month
                  text
                  text_size
                }
              }
            }
          }
        }
      }
    }
  }
`;

Now that we have all our content in place let's render it on the page. First, don't forget to install our parallax package. 

This package is pretty straight forward to use. You just have to feed each element an X and Y coordinate like so. 

I'm using styled comments here which makes it super easy to add a little more logic to your parallax, such as checking odd and even indexes on the array and then adjusting the styles accordingly to have the content ping pong from left to right. I recently wrote a parallax page from scratch, which is a fun exercise, but for the most part It feels like this react parallax package is completely sufficient for our purposes.

I'm using styled comments here which makes it super easy to add a little more logic to your parallax, such as checking odd and even indexes on the array and then adjusting the styles accordingly to have the content ping-pong from left to right.

Making the YouTube API adaptive and modular with ES6 syntax and prototypal inheritance.

The YouTube iframe API requires a pretty opinionated setup so I want to take a moment to walk through how we managed this integration with our own modern JavaScript setup. The developer docs for the YouTube embed API are very good with one caveat, they require that the onYouTubeIframeReady() be applied to the global window object. For small applications, this is probably fine, but if you're using ES6 modules and Webpack to compile your JS then instantiating methods on the global object is not optimal. Here's an example of how we approached this problem. 

First, we assign our custom YouTube class to a variable. Then with that variable bound to the method found in our custom class, we reassign the global onYouTubeIframeAPIReady() that YouTube API is listening for, with the method we instantiating in our class.

var YT = new YouTubeScript();
window.onYouTubeIframeAPIReady = YT.onYouTubeIframeAPIReady(YT);

Now lets look at our custom onYouTubeIframeAPIReady()

Here things get interesting... We have to pass a parameter of 'instance' into our function and then assign the global YT method back to that instance.

  onYouTubeIframeAPIReady(instance) {
  	window.YT = instance;
  	return function() {
  		jQuery('.yt_player').each(function(index) {

	      YT.YTplayer[index] = new YT.Player(jQuery(this)[0], {
	        events: {
	          'onReady' : YT.onPlayerReady,
	          'onStateChange': YT.onPlayerStateChange
	        }
	      });

	      jQuery(this).parent().find('.you_tube_play_button').on('click', function() {
	        YT.YTplayer[index].playVideo();
	      });

	    });
  	}
  };

We can actually refactor this bit to make it a little easier to read with the use of the bind method in JS. The above code is really just a workaround for the way that JavaScript binds methods to the global object. We can be more explicit by refactoring the code in this way.

  this.onYouTubeIframeAPIReady = this.onYouTubeIframeAPIReady.bind(this);
        this.exitHandler = this.exitHandler.bind(this);
        this.onPlayerReady = this.onPlayerReady.bind(this);
        this.onPlayerStateChange = this.onPlayerStateChange.bind(this);

Here we are specifying the scope of the 'this' keyword by binding it to the appropriate function.

Now we can access the players' lifecycle methods inside our own class and manipulate the video depending on what state it is in. 

  onPlayerStateChange(e) {
    let iframe = e.target.h;
    if (( e.data == 1 || e.data == -1 || e.data == 3 )&& !YT.wasFullScreen) {
      var requestFullScreen = iframe.requestFullScreen || iframe.mozRequestFullScreen || iframe.webkitRequestFullScreen;
      if (requestFullScreen) {
        iframe.style.display = 'initial';
        requestFullScreen.bind(iframe)();
      }
      if (document.addEventListener) {
          document.addEventListener('webkitfullscreenchange', YT.exitHandler, false);
          document.addEventListener('mozfullscreenchange', YT.exitHandler, false);
          document.addEventListener('fullscreenchange', YT.exitHandler, false);
          document.addEventListener('MSFullscreenChange', YT.exitHandler, false);
      }
    }
  }

At this point, we're pretty much off to the races! We can manipulate the player however we see fit and have integrated the YouTube API without too much pollution to the global state object. This setup also keeps things nice and organized and modular!

First, we assign our custom YouTube class to a variable. Then with that variable bound to the method found in our custom class, we reassign the global method that YouTube API is listening for, with the method we instantiating in our class.

Deep Fakes - A guide to building multilanguage applications with Prismic and Redux

There is probably a myriad of ways to go about setting up a multi-language site with React and Prismic. However, since the online examples of this are a little thin I figured I’d do a quick run-through of the approach we took when building this manipulated media site for Reuters.

Prismic is a CMS that is completely free to use for one team member and scales very affordably for small teams. It also has a very intuitive setup for working with multiple languages. You’ll first want to connect Prismic to your existing react application by following the steps here and then you can start adding translations from the Prismic GUI under settings.

If you followed the steps from the article above you will now have a react app set up and an entry point to Prismic that will look something like this:

import "regenerator-runtime/runtime";
import { call, put, takeEvery } from "redux-saga/effects";

import { push } from "connected-react-router";

import Prismic from "prismic-javascript";

const prismicClient = Prismic.client("https://<project-name>.prismic.io/api/v2");

We are going to utilize the Prismic.Predicates method to help us retrieve each newly requested language:

To manage state on the front end we’re going to use Redux and dispatchPageRequest() to update the selected language and then a helper function from `connected-react-router` to redirect the page.

Here’s an example of a Redux dispatch method (you will likely need multiple methods for each section of your application)

export function dispatchPageRequest(langCode, changeRoute, index, currentLang) {
  return { type: "PAGES_REQUESTED", langCode, changeRoute, index, currentLang };
}
export function dispatchLandingDataRequest(
  langCode,
  changeRoute,
  index,
  currentLang
) {
  return { type: "LANDING_DATA", langCode, changeRoute, index, currentLang };
}
export function dispatchNavRequest() {
  return { type: "NAVTEXT_REQUESTED" };
}
export function dispatchGlossaryRequest(langCode) {
  return { type: "GLOSSARY_REQUESTED", langCode };
}
export function dispatchSectionRequest(id, langCode, index) {
  return { type: "SECTION_REQUESTED", id, langCode, index };
}
export function dispatchQuizSectionRequest(id, langCode, index) {
  return { type: "QUIZ_SECTION_REQUESTED", id, langCode, index };
}

For this site, we had 16 different languages to render so in order to sort through them we created a fetchPages method that would switch the lang code depending on which was passed in. The cases in this conditional needed to match up exactly with what was being returned from Prismic.

export function* fetchPages(action) {
  let lang = "en-us";
  if (action.langCode) {
    switch (action.langCode) {
      case "es":
        lang = "es-es";
        break;
      case "fr":
        lang = "fr-fr";
        break;
      case "ar":
        lang = "ar-ae";
        break;
      case "ru":
        lang = "ru";
        break;
      case "he":
        lang = "he";
        break;
      case "bu":
        lang = "bu-my";
        break;
      case "zh":
        lang = "zh-cn";
        break;
      case "da":
        lang = "da-dk";
        break;
      case "de":
        lang = "de-de";
        break;
      case "hi":
        lang = "hi-in";
        break;
      case "id":
        lang = "id";
        break;
      case "ja":
        lang = "ja-jp";
        break;
      case "pt":
        lang = "pt-br";
        break;
      case "sv":
        lang = "sv-se";
        break;
      case "tr":
        lang = "tr";
        break; 
    }
  }

In addition to Redux, Redux-saga was used as middleware, which was accessing the Redux state and managing any change asynchronously. We’re going to import some helper functions from this middleware, call, put and takeEvery. The takeEvery method, helps us fetch the new languages concurrently.

Ok, we’re just about there! Let's look at how we can take the user input and follow it back to updating Redux. For our purposes we wanted different actions to occur with different events. Here is what the hover state looked like:

The inbuilt onMouseEnter() and onMouseLeave() methods are going to do just nicely to help up pull this off. Each button has an id that lines up with one of those lang codes and then when you hover, a functions is triggered that filters through the data and sets the state of the component.

  onMouseEnter(event) {
    const langCode = event.target.id;
    if (this.props.landingData) {
      const langData = this.props.landingData.filter((data) => {
        if (data.lang === langCode) {
          return data;
        }
      });
      this.setState({
        upper_text: langData[0].data.description[0].text,
        title: langData[0].data.title,
        manipulated_image: langData[0].data.manipulated_image.url,
        sponsored_by: langData[0].data.sponsored_by,
      });
    }
  }

When you hover away from the button we access our nested state with the spread operator and reset it based on the default props.

  onMouseLeave(event) {
    this.setState({
      ...this.state,
      upper_text: this.props.page.data.description[0].text,
      title: this.props.page.data.title,
      manipulated_image: this.props.page.data.manipulated_image.url,
      sponsored_by: this.props.page.data.sponsored_by,
      landingData: this.props.page.data.landingData,
      id: this.props.page.lang,
    });
  }

Let's cover the click event where we want to access the Redux store and rehydrate the application with the selected data. When a user clicks the dispatchPageRequest() method we wrote earlier will be called and the langCode from that button id will be passed along. The return will have a type of ‘PAGES_REQUESTED’. Specifying the type like this allows the react-saga middleware to handle this update concurrently as I mentioned earlier.

export function dispatchPageRequest(langCode, changeRoute, index, currentLang) {   return { type: "PAGES_REQUESTED", langCode, changeRoute, index,      currentLang };}

In the meantime we want to be checking for a click event and if the props have been updated on the landing page. We’ll do this in the componentDidUpdate() lifecycle method, which will continue to check recursively for when there is a change.

  componentDidUpdate(prevProps) {
    if (
      this.props.hasClicked !== prevProps.hasClicked ||
      this.props.langCode !== prevProps.langCode
    ) {
      if (this.props.hasClicked) {
        scrollIntoView(document.getElementById("intro"), {
          time: 3000,
        });
      }
    }
    if (this.state.video === "" && this.props.page.data !== undefined) {
      this.setState({
        video: this.props.page.data ? this.props.page.data.landing_video : "",
      });
    }
  }

This has been a pretty broad overview of our solution for implementing multiple languages in a react application. If you have other ways of dealing with multilingual sites I’d love to hear your approach.

In addition to Redux, Redux-saga was used as middleware, which was accessing the Redux state and managing any change asynchronously. We’re going to import some helper functions from this middleware, call, put and takeEvery. The takeEvery method, helps us fetch the new languages concurrently.

Ok, we’re just about there! Let's look at how we can take the user input and follow it back to updating Redux. For our purposes we wanted different actions to occur with different events. Here is what the hover state looked like:

Creating your own bespoke eCommerce store with React & Stripe

E-commerce is booming, and with so many platforms to choose from it can be overwhelming to pick where to start. I’m going to walk you through how to create a completely custom experience and forgo the fees and hidden costs built into the likes of Shopify and Amazon. Let's get started.

Anyone involved with the processing, transmission, or storage of card data must comply with the Payment Card Industry (PCI) Data Security Standard. A good rule of thumb, when building a PCI compliant checkout, is to not store or manage any credit card information yourself. For this reason, we’re going to use Stripe in this demonstration because they do a fantastic job of extracting away this complexity. They’re also free to use and will only take a small cut out of the price of goods sold. You should set up a stripe account and create your products before continuing onto the next steps.

I am using Gatsby, a React static site generator paired with Prismic, which hosts and serves our content. These services are free to use, but you can also follow along with your preferred flavor of React application. Since we’re using Gatsby, we’re going to start by installing our stripe dependencies and adding them to the gatsby-config.js file. 

require('dotenv').config({
  path: `.env.${process.env.NODE_ENV}`
});

Your environment variables will be placed in .env.development and you process them by requiring the dotenv in gatsby-config.js like so.

    resolve: `gatsby-source-stripe`,
      options: {
        objects: ["Sku"],
        secretKey: process.env.STRIPE_SECRET_KEY,
        downloadFiles: false,
      },
    },

Next, you need to create a checkout component. Here’s my entire component for the sake of ease.

import React from 'react';
import { loadStripe } from '@stripe/stripe-js';
import colors from 'styles/colors';
import styled from '@emotion/styled';

const Header = styled.div`
  margin: 6rem auto;
  text-align: center;
`;

const ButtonContainer = styled.div`
  display: grid;
  grid-gap: 1.5rem;
  justify-content: center;
`;

const Button = styled.div`
  font-size: 1.6rem;
  text-align: center;
  background: ${colors.yellow600};
  padding: 1.6rem;
  box-shadow: 2px 5px 10px rgba(0, 0, 0, 0.1);
  color: ${colors.grey900};
  border-radius: 6px;
  letter-spacing: 1.5px;
  cursor: pointer;
  width: 10rem;

  &:hover {
    box-shadow: 2px 5px 10px rgba(0, 0, 0, 0.2);
  }
`;

const stripePromise = loadStripe(process.env.GATSBY_STRIPE_PUBLISHABLE_KEY)

const redirectToCheckoutTwo = async event => {
  event.preventDefault();
  const stripe = await stripePromise;
  const { error } = await stripe.redirectToCheckout({
    lineItems: [{ price: process.env.GATSBY_BUTTON_PRICE_ID_TWO, quantity: 1 }],
    mode: 'payment',
    successUrl: `https://www.kahilnayton.com/payment-success/`,
    cancelUrl: `https://www.kahilnayton.com/`,
  });

  if (error) {
    console.warn('Error:', error);
  }
};
const redirectToCheckoutFive = async event => {
  event.preventDefault();
  const stripe = await stripePromise;
  const { error } = await stripe.redirectToCheckout({
    lineItems: [{ price: process.env.GATSBY_BUTTON_PRICE_ID_FIVE, quantity: 1 }],
    mode: 'payment',
    successUrl: `https://www.kahilnayton.com/payment-success/`,
    cancelUrl: `https://www.kahilnayton.com/`,
  });

  if (error) {
    console.warn('Error:', error);
  }
};
const redirectToCheckoutTen = async event => {
  event.preventDefault();
  const stripe = await stripePromise;
  const { error } = await stripe.redirectToCheckout({
    lineItems: [{ price: process.env.GATSBY_BUTTON_PRICE_ID_TEN, quantity: 1 }],
    mode: 'payment',
    successUrl: `https://www.kahilnayton.com/payment-success/`,
    cancelUrl: `https://www.kahilnayton.com/`,
  });

  if (error) {
    console.warn('Error:', error);
  }
};

const Checkout = (props) => {
  return (
    <>
      <Header>
        <h2>Choose an amount</h2>
      </Header>
      <ButtonContainer>
        <Button onClick={redirectToCheckoutTwo}>$2</Button>
        <Button onClick={redirectToCheckoutFive}>$5</Button>
        <Button onClick={redirectToCheckoutTen}>$10</Button>
      </ButtonContainer>
    </>
  );
};

export default Checkout;


I didn’t have a huge assortment of products in this case so I just created 3 separate functions with their corresponding IDs. 

That’s pretty much it, it’s a super-secure and simple way to receive payment and you have all the flexibility in the world to make your customer’s journey unique. You can check out the final product here. 

Stripe is relatively unknown to the general public and doesn’t give off that hue of trustworthiness that other platforms do. That’s why when I’m building out a checkout for a client I’ll typically stick with the old favorites such as Shopify or WooCommerce. I’m currently working on a React app that leverages the Shopify API, which might just be the best of both worlds. I’ll let you know how that turns out. 

A word on PCI Compliance 

Anyone involved with the processing, transmission, or storage of card data must comply with the Payment Card Industry (PCI) Data Security Standard. A good rule of thumb, when building a PCI compliant checkout, is to not store or manage any credit card information yourself. For this reason, we’re going to use Stripe in this demonstration because they do a fantastic job of extracting away this complexity. They’re also free to use and will only take a small cut out of the price of goods sold. You should set up a stripe account and create your products before continuing onto the next steps.

React / Redux client with a MongoDB / Node / Express server

I worked on a project last year for Reuters that was an application, which educated journalists on identifying manipulated media. You can learn more about it here. This app was translated into 16 languages so it required global state in order to keep track of the language you were reading in at all times. While this was a super fun project to work on I still didn't quite grasp every nuance of working on a complex production-ready Redux app. So, in the spirit of a better and more productive 2021, I decided to test my luck at building the proverbial todo app and freshen up on some of these concepts. 

When it comes to building React applications, using a third-party tool such as redux to manage state can be a tad overkill, and for the most part, you could probably make do with the context API, which comes shipped with React 16. Having said that... I'm going to use Redux purely from an exploratory perspective. Instead of ranting on about how redux works (you can check out their excellent documentation here) I'm just going to point out a couple of places that were significant for me at least or areas that were just very cool. 🤓

export const removeTodo = (user_id, todo_id) => {
  return (dispatch) => {
    return apiCall("delete", `/api/users/${user_id}/todos/${todo_id}`)
      .then(() => dispatch(remove(todo_id)))
      .then(history.push('/'))
      .catch((err) => {
        addError(err.message);
      });
  };
};

Since Redux isn't inherently asynchronous we can leverage middleware (in my case redux-thunk) to create asynchronous actions. 

While the learning curve for Redux at first can seem a little overwhelming and the set up a little tedious, you only need to do this once. When you understand the underlining principles there really isn't all that much more to get and you will be able to scale your applications much more efficiently and with greater modularity. 

import { REMOVE_TODO, LOAD_TODOS, UPDATE_TODO } from '../actionTypes'

const todo = (state = [], action) => {
  switch (action.type) {
    case LOAD_TODOS:
      return [...action.todos];
    case REMOVE_TODO:
      return state.filter(todo => todo._id !== action.id);
    case UPDATE_TODO:
      return state.map(t => {
        if (t._id === action.id) {
          t.done = true;
        };
        return t;
      })

    default:
      return state;
  }
}


export default todo;

MongoDB is pretty awesome... For the longest time, any full-stack application I've been working on has used  PostgreSQL. One of the things I enjoyed about MongoDB was its handy inbuilt methods for interacting with the DB. 

exports.updateTodo = async function (req, res, next) {
  try {
    let updatedTodo = await db.Todo.findById(req.params.todo_id);
    await db.Todo.update(
      { _id: updatedTodo },
      {
        $set: {
          done: true,
        }
      }
   );
    return res.status(200).json(updatedTodo);
  } catch (err) {
    return next(err);
  }
};

I also really like the direction they're going with having to initialize a cluster in order to deploy the server on the backend. While I still really need to look more into the concept of clusters and sharding (way more complicated than necessary for this app) it's still awesome that MongoDB is streamlining this process and basically making it impossible (as far as I know) to deploy a server on Heroku without first setting up a cluster on Atlas. 

The distinction between containers and components

I used to think everything was a component, but I like that with a Redux application you need to deliberately architect the places you want the state to reside with containers, which look a lot like components but have a few extra attributes. Anywhere you want to bring in your state you need to make sure to create your mapStateToProps function and use react-redux connect to hydrate your state.

function mapStateToProps(reduxState) {
  return {
    currentUser: reduxState.currentUser,
    errors: reduxState.errors,
  };
}

export default withRouter(
  connect(mapStateToProps, {
    authUser,
    removeError,
  })(App)
);

I have spent so much of this year as a frontend engineer so it was really nice to re-visit auth and I mean that genuinely and sincerely. I like salt rounds and JWT and all that fun stuff even if it can be a pain to debug and make you feel like you're having an existential crisis. 

exports.signin = async function (req, res, next) {
  try {
    let user = await db.User.findOne({
      email: req.body.email
    })
    let { id, username, profileImageUrl } = user
    let isMatch = await user.comparePassword(req.body.password)
    if (isMatch) {
      let token = jwt.sign(
        {
          id,
          username,
          profileImageUrl
        },
        process.env.SECRET_KEY
      )
      return res.status(200).json({
        id,
        username,
        profileImageUrl,
        token
      })
    } else {
      return next({
        status: 400,
        message: "That is an invalid user name or password mate"
      })
    }
  } catch (e) {
    return next({status: 400, message: "Error in catch of server / handlers - Invalid email or username"})
  }
}

Here we are signing up a user in the user handler with the help of JWT.

if (localStorage.jwtToken) {
  setAuthorizationToken(localStorage.jwtToken);
  try {
    store.dispatch(setCurrentUser(jwtDecode(localStorage.jwtToken)))
  } catch (e) {
    store.dispatch(setCurrentUser({}))
  }
}

Then in the index.js of the client using it again to decode the user token that was stored in local storage. 

In my experience, I rarely get the opportunity to crank out a production-ready full-stack application by myself in a matter of days. Usually, I am hyper-focusing on a specific problem or really getting granular on some UX UI front-end development that needs to be primo. Now, this todo app is far from anything to write home about, but It's a great exercise to go through the motions of building a full-stack application from start to deployment, even if it's just a small silly app like this one. I implore you to try and do this from time to time whether you're primarily a frontend or backend dev. It's a great exercise. We all need to know what we're building on top of even if it's just at a higher level.

- You can check out this app here or go straight to the repo here. 

All this buzz about generating static files... 

When researching different React frameworks for a new project we are barraged with an array of features that both Gatsby.js and Next.js tout to have, such as improved SEO, server-side rendering, and superior performance. However, to find out how these frameworks work and how they differ takes a little more digging beneath the surface. Let's take a little trip back in time so that we can better understand how they fit in the greater scheme of things. 

The year is 1989 and a rather gifted computer scientist by the name of Tim Berners Lee was coming up with a system for the increasingly complicated task of computers communicating with one another. At this point, the precursor to the internet was nothing more than a few machines spread out across different university campuses in the USA sharing data. It was becoming a complicated task and Lee’s solution was a way of mitigating this complexity and it turned out to become one of the cornerstone concepts of the Internet as we know it today. 

Essentially Lee borrowed a concept from a fellow colleague at CERN Ted Nelson. This was the concept of the hypertext and Berners Lee applied it to a protocol he was creating that would become known as HTTP and subsequently the WorldWideWeb. Now there are dissertations written on this topic and I am by no means qualified to get into the details, but at its core HTTP is a series of links that point to different resources, and since it's a protocol it needs to operate with certain parameters. One such parameter is the relationship between a server (the system that serves the information) and the client (the system that receives it).

One aspect of the new information management system that Berners Lee had created was a language known as HyperText Markup Language (HTML). So this might be common knowledge for most of us because HTML is still widely used today and is still the first file a browser will begin compiling when it gets a website's data back from a server. 

A lot has changed since 1989 and we need to take a lot more into consideration, but this underlining principle remains the same, the client asks the server for some information to build the site and will begin with the HTML document. Before we start talking about parsing this data let’s quickly look at the other crucial steps that must happen nowadays. 

To start with we need to verify our IP address and in order to do this, we make a request to the DNS server and verify our own address as well as get the IP of the address we are requesting. Also, we don’t actually use the original HTTP these days and for scalability and security reasons HTTP/1.1, HTTP/2, and SSL/TLS are all much more widely used because of the aforementioned issues. 

Let’s not forget these are computers we’re dealing with so the browser isn’t actually going to read the HTML itself, but rather it consumes the HTML as bytes of data and then converts that data into characters, which are further processed into tokens. So your browser sees HTML and it will trigger this chain reaction. HTML - bytes - characters - tokens. The browser then takes the tokens and creates a tree-like data structure that we refer to as the document object model, DOM. 

So the browser is busy away constructing the DOM from top to bottom and it comes across a style tag. Well, what does it do? Yep, you guessed it... It converts the CSS into data. Then characters. Then tokens, and begins creating another object model, this time the CSS Object Model or CSSOM. This new CSSOM can actually be constructed concurrently as the DOM is being put together. In fact, it's critical that these are the first things that the browser starts creating. This is one of the reasons we’ll often see the styles included at the top of our HTML file, the other being, that we can't start parsing our JS until the CSSOM has completed, so let's talk about that a little now. 

When the HTML parser finds a <script> tag, it pauses the parsing of the HTML document and has to load, parse, and execute the JavaScript code. This is because JavaScript might be used to change the shape of the document model. Yes, that's right the browser has to stop processing the HTML and the construction of the DOM in order to interpret the JS. We will often leave our JS code at the bottom of the HTML for this reason so that you can allow the DOM to be created first before processing it. So the browser encountering a script tag will stop it in its tracks. By default, the DOM will stop being compiled if it encounters a script, but this is not the case for the CSSOM, which will actually take precedence over the JS. So that pretty much rounds out the default order of priorities when compiling our code. 

How can we be more deliberate with how we want our code to run?

So I still want to move onto server-side rendering, but a quick note on performance and some important keywords to keep in mind. We can use the async and defer keywords on a script tag to instruct the browser to run our code asynchronously and continue parsing the document when they encounter a script tag. With async, the file gets downloaded asynchronously and then executed as soon as it's downloaded. With defer, the file gets downloaded asynchronously but executed only when the document parsing is completed. With defer, scripts will execute in the same order as they are called.

So what's the difference here? If you compare them by the questions they're answering then essentially they're solving the same problem, but they're doing it in very different ways. With Gatsby.js, we're going to physically create our static assets during the build phase, but by contrast, Next.js performs automatic server-side rendering so it renders your assets on the server and then sends them to the client. Applying our history lesson here. What exactly happens when you type a URL into the browser when using these frameworks? With Gatsby.js and Next.js you get an HTML file, but the mechanics differ behind the scenes. However, it's important to be aware of how this will be parsed. In Next.js, when you request something, it goes to Node.js. Node.js pre-renders all the content on the server, and it serves it right down to you as if your browser had rendered itself. They are both fantastic and have their own individual pros and cons depending on your situation.

So much is done for us these days when we spin up a new react app, which is fine because it lets us focus our attention on actually building things, but how the browser works and renders your files is a crucial aspect to grasp in order to debug your applications and to improve performance. As always, the browser dev tools are your friend and are constantly rolling out new and improved features so I'd encourage you to keep up to date with those developments and don’t forget to run reports on your sites to catch any underlining issues.

When the HTML parser finds a <script> tag, it pauses the parsing of the HTML document and has to load, parse, and execute the JavaScript code. This is because JavaScript might be used to change the shape of the document model. Yes, that's right the browser has to stop processing the HTML and the construction on the DOM in order to interpret the JS.

A CMS solution for a client that was set up with Prismic and Gatsby. Also took advantage of Netlify for email notification and cloud hosting. The newsletter subscription was set up through Mail Chimp.

Often times you’ll have a fairly complicated assortment of resources to filter through on the front end. I’m going to walk you through our approach to filtering through a resource room with Prismic and Gatsby. If you’re new to Prismic or Gatsby be sure to check out their excellent docs to get started.

Templates to the rescue! If we structure our CMS in a thoughtful way then we can abstract away a lot of the complexity of filtering on the front-end. In Prismic you’ll need to create a repeatable content type of category and assign a category for each blog. Or in traditional back end speak there needs to be a one-to-many relationship between blogs and categories. This way we’re able to assign the data with its own designated endpoint for each category. Let’s explore how.

Here’s an example of how a blog content type could look. The essential takeaway here is including a unique uid, which we will use for our routing and dynamic page generation.

In our application, we’re going to generate templates with the help of gatsby-source-prismic-graphql

I would recommend this plugin over gatsby-source-prismic because it comes with content previewing right out of the box, which is a pretty essential feature if your client is not tech-savvy and are going to be updating the application independently.

 {
      resolve: 'gatsby-source-prismic-graphql',
      options: {
        repositoryName: 'leading-edge',
        path: '/preview',
        previews: true,
        pages: [
          {
            type: 'Post',
            match: '/post/:uid',
            path: '/post-preview',
            component: require.resolve('./src/templates/post.js'),
          },
          {
            type: 'Person',
            match: '/bio/:uid',
            path: '/bio-preview',
            component: require.resolve('./src/templates/bio.js'),
          },
          {
            type: 'Person',
            match: '/author/:uid',
            path: '/author-preview',
            component: require.resolve('./src/templates/author.js'),
          },
          {
            type: 'Resource',
            match: '/resource/:uid',
            path: '/resource-preview',
            component: require.resolve('./src/templates/resource.js'),
          },
          {
            type: 'Topic',
            match: '/topic/:uid',
            path: '/topic-preview',
            component: require.resolve('./src/templates/topic.js'),
          },
          {
            type: 'Simple_page',
            match: '/page/:uid',
            path: '/simple-page-preview',
            component: require.resolve('./src/templates/simple-page.js'),
          },
          {
            type: 'Category',
            match: '/blog/:uid',
            path: '/category-preview',
            component: require.resolve('./src/templates/category.js'),
          },
        ],
      },
    },
    {
      resolve: 'gatsby-plugin-react-svg',
      options: {
        rule: {
          include: /vectors/,
        },
      },
    },

The pages attribute is what finds all our uid’s and dynamically creates our routes. Here’s what the post.js template could look like: 

export const query = graphql`
  query getPost($uid: String!) {
    prismic {
      postByUID: post(uid: $uid, lang: "en-us") {
        _meta {
          uid
          firstPublicationDate
        }
        title
        unlisted
        deck
        publish_date
        category {
          ... on PRISMIC_Category {
            title
            _meta {
              uid
            }
          }
        }
        authors {
          author {
            ... on PRISMIC_Person {
              _meta {
                uid
              }
              name
              short_bio
              image
              hide_bio
            }
          }
        }
        feature_image
        preview_image
        related_posts {
          post {
            ... on PRISMIC_Post {
              title
              deck
              _meta {
                uid
              }
              category {
                ... on PRISMIC_Category {
                  title
                }
              }
              feature_image
              preview_image
            }
          }
        }
        body {
          ... on PRISMIC_PostBodyText {
            type
            primary {
              content
            }
          }
          ... on PRISMIC_PostBodyPullquote {
            type
            primary {
              text
            }
          }
          ... on PRISMIC_PostBodyBlock_image {
            type
            primary {
              image
              caption
              credit
            }
          }
          ... on PRISMIC_PostBodyCustom_html {
            type
            primary {
              content
            }
          }
        }
        social_title
        social_description
        social_image
      }
    }
  }
`;

Our qraphQL query is set up to take a UID as a parameter and fetch the corresponding data depending on what UID is passed in. 

Now that we have all our posts rendered as their own page we can move on to the categories and define a template for those.

 {
            type: 'Category',
            match: '/blog/:uid',
            path: '/category-preview',
            component: require.resolve('./src/templates/category.js'),
          },

Again the important take away is the uid that we’re passing into our graphql query.

const postQuery = graphql`
  query getCategoryPosts($first: Int = 12, $after: String, $id: String!) {
    prismic {
        categoryPosts: allPosts(first: $first, after: $after, sortBy: publish_date_DESC, where: {category: $id}) {
            edges {
                node {
                    unlisted
                    deck
                    feature_image
                    publish_date
                    title
                    category {
                        ... on PRISMIC_Category {
                            title
                            description
                        }
                    }
                    preview_image
                    _meta {
                        uid
                    }
                }
            }
        }
    }
  }
`

The where keyword in graphql defines the condition for the data we are querying so the above code will define an endpoint for each category and fetch all blog posts that are under that category. 

If you have a second factor to sort by then we’ll need to take this one step further and drill into each section on the front end. 

Let’s create a select element and use the handle change to trigger a filterByType() method. There will of course have to be a type associated with each of our blog posts so make sure you have that set up in your CMS.

Here we’re taking the target from the select and beginning the filtering process:

async fetchPosts() {     this.props.prismic       .load({         variables: {           after: getCursorFromDocumentIndex(this.state.loadedPostTotal - 1)         }       })       .then(res => {         const loadedPosts = res.data.allPosts.edges;          this.setState({           loadedPostTotal: this.state.loadedPostTotal + loadedPosts.length,           posts: this.state.posts.concat(loadedPosts.filter(post => !post.node.unlisted)),           total: res.data.allPosts.totalCount,         });          return this.state.loadedPostTotal;        })       .then(newTotal => {         if (newTotal < this.state.total) {           this.fetchPosts();          } else {           this.setState({             loaded: true,             currentPosts: this.state.posts.slice(this.state.firstPost, this.state.lastPost),           });         }       })      return true;   }

Since the data is going to be a changing variable we need to first set the state with the blogs by category.

The setCurrentBlogs() method is going to asynchronously splice, depending on how many blogs we want to see per page, and set the state with the new posts. 

 async setCurrentPosts() {
    await this.setState({
      loaded: false,
    })

    await this.setState({
      currentPosts: this.state.posts.slice(this.state.firstPost, this.state.lastPost),
      loaded: true,
    })
  }

That’s pretty much it! Now you have the filtered blogs in state that are going to change dynamically in your render method in a clean and concise way. You can check out the finished product here.

Filtering a complicated resource room for a client can take a bit of planning at times, but with the right setup on the backend, graphQL, React and a bit of es6 thrown in you can get it together is a pretty readable and maintainable way. 

Templates to the rescue! If we structure our CMS in a thoughtful way then we can abstract away a lot of the complexity of filtering on the front-end. In Prismic you’ll need to create a repeatable content type of category and assign a category for each blog. Or in traditional back end speak there needs to be a one-to-many relationship between blogs and categories. This way we’re able to assign the data with its own designated endpoint for each category. Let’s explore how.

Here’s an example of how a blog content type could look. The essential takeaway here is including a unique uid, which we will use for our routing and dynamic page generation.

This CMS application was built with Gatsby and Prismic. The checkout process is powered by Stripe and there is also extensive interaction with the Three.js JavaScrip library. Cloud hosting for this project is set up through Netlify.

Over the last couple of weeks, I’ve been in the process of revamping my personal site to coincide with the release of some new content. Here’s the final result. I’ve been really loving the look of three.js and was committed to integrating it into the site.

In order to build a site that could handle complex rendering, I chose a static site generator and Gatsby has been my go-to for its ease of use and flexibility with third-party plugins. Since Gatsby is powered by React I was at first a little unsure about how this library would be integrated. I love that React is an unopinionated framework, but you really need to have a solid understanding of their lifecycle methods so you can understand the order of operations. The way that we can work with the three.js library is by appending a canvas to the virtual DOM. Then we’re able to interact with it as you would any other dom element. Let’s take a look at two approaches to doing this.

Option One — Using packages and React hooks

This option utilizes the React Three Fiber package. Click on that link to get started with the docs or here is my starter code if you’d like to jump ahead to a working example.

After you clone down and start that repo you should see a 3D box that you can interact with and resize by clicking and dragging.

What I love about this package is that even though the canvas is still its own stand-alone element, we now have the capability to interact with the three.js library through state management. The way this is achieved is by returning the mesh method from three.js, which has been appended onto the animation attribute from React Spring. Having this setup means we can dynamically affect different attributes of the library with the inbuild mouse events.

const Box = () => {
  const [hovered, setHovered] = useState(false)
  const [active, setActive] = useState(false)
  const props = useSpring({
    scale: active ? [1.5, 1.5, 1.5] : [1, 1, 1],
    color: hovered ? "green" : "blue",
  })

  return (
    <a.mesh
      onPointerOver={() => setHovered(true)}
      onPointerOut={() => setHovered(false)}
      onClick={() => setActive(!active)}
      scale={props.scale}
      castShadow
    >
      <boxBufferGeometry attach="geometry" args={[1, 1, 1]} />
      <a.meshPhysicalMaterial attach="material" color={props.color} />
    </a.mesh>
  )
}

With this option, we are appending the canvas to our application with the useRef hook, which lets us create mutable variables inside functional components. If you’ve never used React refs before they are a great way to access DOM nodes or React elements, but it must be done within a functional component.

Options two — a lighter package free approach

The second approach I found and actually the method I ended up using doesn’t use any third-party packages except three.js.

This time our entry point will be a class component inside the componetDidMount lifecycle method.

import React, { Component } from 'react';
import styled from '@emotion/styled';
import threeEntryPoint from '../components/findTheDay/threeEntryPoint';

const ThreeContainer = styled.div`
`
export default class FindTheDayCanvas extends Component {

  componentDidMount() {
    threeEntryPoint(this.threeRootElement);
  }

  render() {

    return (
      <ThreeContainer>
        <div
          className="header-header"
          ref={element => (this.threeRootElement = element)}
        />
      </ThreeContainer>
    );
  }
}

Here’s what your canvas manager could look like:

import SceneManager from './SceneManager';

export default container => {
    const canvas = createCanvas(document, container);
    const sceneManager = new SceneManager(canvas);

    let canvasHalfWidth;
  let canvasHalfHeight;

    bindEventListeners();
    render();

    function createCanvas(document, container) {
        const canvas = document.createElement('canvas');     
        container.appendChild(canvas);
        return canvas;
    }

    function bindEventListeners() {
        window.onresize = resizeCanvas;
        window.onmousemove = mouseMove;
        resizeCanvas();	
    }

    function resizeCanvas() {        
        canvas.style.width = '100%';
        canvas.style.height= '100%';
        
        canvas.width  = canvas.offsetWidth;
        canvas.height = canvas.offsetHeight;

        canvasHalfWidth = Math.round(canvas.offsetWidth/2);
        canvasHalfHeight = Math.round(canvas.offsetHeight/2);

        sceneManager.onWindowResize()
    }

    function mouseMove({screenX, screenY}) {
        sceneManager.onMouseMove(screenX-canvasHalfWidth, screenY-canvasHalfHeight);
    }

  function render(time) {

        requestAnimationFrame(render);
        sceneManager.update();
    }
}

I really like this approach because it makes our code more modular and organized. The next steps would be to create your subject matter and then lighting.

Working with three.js is really exciting. There is, however, a substantial amount to take in given the nature of 3D graphics and the intricacies they involve. I’ve just covered a couple of ways to get you started within a React setting, but to get something truly awesome on the screen I’d recommend having a solid understanding of this library and its capabilities by checking out the official docs.

Building and scaling an application with the use of a frontend framework has changed the way we approach the separation of concerns. Traditionally HTML, CSS, and JavaScript were all considered separate and maintained from their respective directories. 

When building with a framework, such as React, there is a component methodology that already has our elements broken down into rendered logic and UI logic. This is clearly an intentional effort to make our code more modular that we can assemble into various UI elements, components, and pages.

React components and their smaller building blocks, called elements, take care of everything that you would require to build a scalable application, such as event handlers, state changes, and rendering data. They achieve this by blending JS and HTML to create JSX, a syntax extension of JavaScript.

In this guide, we'll go over how we adopted styled-components and transitioned from a Sass/SCSS approach to build this application.

While you don't have to be familiar with styled-components, you should have an understanding of React and Sass. This particular project used Gatsby and Prismic so feel free to dive into either of those to get started quickly you can check it out here.

Naming conventions are important to keep our style structure organized and modular. Coming from the Block Element Modifier (BEM) convention I would often find myself falling back on this habit. So what convention should we use for styled-component? Well as it turns out BEM might be a little obserlete given the problems that it was originally solving don't really apply to a frontend framework.

1. When styling a new component - we can easily see which modifiers and children already exist. We might even realize we don't need to write any CSS because there is a pre-exisiting modifier.

2. Reading the markup - We quickly get an idea of which elements depond on another.

3. Shared declaritive syntax - Everyone on the team can consistently name components for easier communication between team members.

I haven't come across a naming convention that works particularly well for styled components, but I would encourage everyone to follow the cardinal rule when naming anything. Try and be descriptive as possible and create your components in a way that allows them to be modified.  

Get your project running with your preferend setup. You'll want to install styled-components npm i styled-components or yarn add styled-components. I'm actually going to use emotion, which is heavily inspired by styled components so if you would like to use that yarn add @emotion/react @emotion/styled. 

Structure you files in an organized way that makes sense for you. 

The way we structured this project there are three main places for styles. 

1 - /styles - Settings, globals styles, how to layout your structure and other reusable information.

2 - /components - Just like any react application we're going to have all our components here with corresponding sub-directories for UI elements.

3 - Each page, compoennt or template can contain styles that correspond just to that element and don't need to be re used.

We need to pass all our global and layout styles down to the applications ancestors so in order to do this we wrap the root level component with the styles attribute. 

import css from "@emotion/css";
import colors from 'styles/colors';
import dimensions from 'styles/dimensions';

const globalStyles = css`
  html {
    font-size: 62.5%;
    -webkit-font-smoothing: antialiased;
  }

  html,
  body,
  #root {
    margin: 0;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
    min-height: 100%;
  }

  body {
    width: 100%;
    margin: 0 auto;
    font-size: 1rem;
    line-height: 1.5;
    color: ${colors.grey900};
    -webkit-font-smoothing: antialiased;
    
    &.is-locked {
      overflow: hidden !important;
    }

import styled from "@emotion/styled";
import dimensions from "styles/dimensions";

const fractionStrToDecimal = str => str.split('/').reduce((p, c) => p / c);

export const Inner = styled("div")`
  position: relative;
  width: 100%;
  margin: 0 auto;
  padding-left: 3.2rem;
  padding-right: 3.2rem;
  max-width: 136rem;
  
  @media(min-width: ${dimensions.tabletLandscapeUp}px) {
    padding-left: 4rem;
    padding-right: 4rem;
  }
  
  @media(min-width: ${dimensions.desktopLargeUp}px) {
    max-width: 148rem;
  }
`;

const Layout = ({children}) => (
  <LayoutContainer>
    <Global styles={[resetStyles, globalStyles, typeStyles]}/>

    <div className="Layout">
      <Header/>

      <main>
        {children}
      </main>

      <Footer/>
    </div>

    <ModalSignup />
  </LayoutContainer>
);

Since I'm using Gatsby.js the root component is the layout file, but if you're using create-react-app or built your's from scratch then in your index.js where you wrap app.js is where you would want to instanciate the global styles.

Lets look at the button element. first create a button component and import your necessary dependencies, then create a variable for your button. 

import React, { Component } from 'react';
import styled from '@emotion/styled';
import colors from 'styles/colors';

const ButtonContainer = styled.button`
  padding: 0.8rem 4.8rem 0.8rem;
  background: ${colors.red500};
  height: 6rem;
  display: inline-block;
  vertical-align: center;
  font-weight: 600;
...

In our render we're going to accept parameters we pass in from where we render our button and then with the help of the spread operator set them as individual attributes. 

class Button extends Component {   render() {     const { children, ...props } = this.props;     return (       <ButtonContainer         onClick={this.props.onClick}         {...props}>         <div>           {this.props.children}         </div>       </ButtonContainer>     );   } }

This is just one example of how you can pass around props to extend the functionality of our UI components, other examples can be found in their docs.

The way we approached this was by passing in the variation you want and then conditionally creating a className. 

 <ProductSection id='overview'>         {product.overview_content && (           <ContentBlock             intro={product.logline}             heading={product.overview_heading}             image={product.overview_image}             illustration={product.overview_illustration}             content={product.overview_content}             variant='large'           />         )}

Here in the product section, we are passing in the modifier of large. And then in the ContentBlockContainer:

const ContentBlock = ({ intro, heading, content, image, illustration, variant }) => {   return (     <ContentBlockContainer className={variant && `ContentBlock--${variant}`}>       <Inner>         {(intro || heading) && (           <header>             {intro && <Rubric>{intro}</Rubric>}             {heading && <h2>{heading}</h2>}           </header>         )}

If this variant is present then we can style with that className  like so:

  @media(min-width: ${dimensions.tabletLandscapeUp}px) {     flex: 1 1 50%;     padding: 4rem;          .ContentBlock--large & {       p {         font-size: 2.1rem;       }     }   } `;

Here we are increasing the size of our paragraph with that className. The sky's the limit for conditional rendering and you can set it up in a way that makes sense to you, but I would encourage you to lay it out in a consistent way so that you can follow the style logically. 

As always it doesn't matter what tools we use, but how we use them. Styled components can add some nice extra tricks to your frontend, but don't throw the baby out with the bathwater... Sass being the baby I think. It brought a lot of structure to our projects and for a log time the best option for making our styles modular. Keep it structured and keep it modular and you're good to go. 

When building with a framework, such as React, there is a component methodology that already has our elements broken down into rendered logic and UI logic. This is clearly an intentional effort to make our code more modular that we can assemble into various UI elements, components, and pages.

React components and their smaller building blocks, called elements, take care of everything that you would require to build a scalable application, such as event handlers, state changes, and rendering data. They achieve this by blending JS and HTML to create JSX, a syntax extension of JavaScript.

Making the switch from SASS to Styled Components

Blog

Parallax and Gatsby.js

YouTube iframe API integration

Deep Fakes - multilanguage application

eCommerce store with React & Stripe

Todo - the MERN stack

Choosing the right static site generator

Leading Edge - filtering

React & THREE.js

Making the switch from SASS to Styled Components