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

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.

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.