DEV Community: Nate Arnold

Simple, Typesafe React Modals using Portals and Custom Hooks

Nate Arnold — Sun, 27 Sep 2020 20:50:08 +0000

Modals, for better or worse are an often requested feature in web applications. I recently ran across a pattern that allows for managing modal state and placement in a React application that not only works, but feels OK to implement. The use of a custom hook allows the management of modal state without relying on a state management lib and without polluting your component or application state. React Portals allow us to attach components anywhere we want in our application. In this example, we will hoist the component completely out of our component's parent scope and append it to the body element.

`useModal.ts`

useModal.ts is a custom hook that manages the visibility of our modal. The hook returns the visibility of the modal and a toggleVisibility function that does exactly what the name implies.

import React from "react";

export const useModal = () => {
  const [modalIsVisible, setModalIsVisible] = React.useState(false);
  const toggleModalVisibility = () => setModalIsVisible(!modalIsVisible);

  return [modalIsVisible, toggleModalVisibility] as const;
};

`Modal.tsx`

Modal.tsx is the modal component. Notes:

The custom useModal hook gives us access to the state of the modal from within the modal itself and allows us to toggle visibility by passing the toggleVisibility function into our modal UI.
ReactDOM.createPortal allows us to hoist the modal component outside of the scope of it's parent node and attach it to the body of our application.

import React from "react";
import ReactDOM from "react-dom";

type ModalProps = {
  isVisible: boolean;
  toggleVisibility: () => void;
  modalContent: React.ReactNode;
};

export const Modal = ({
  isVisible,
  toggleVisibility,

}: Readonly<ModalProps>): JSX.Element | null => {
  const modal: JSX.Element = (
    <>
      <div className="backdrop" onClick={toggleVisibility} />
      <div className="modal" aria-modal aria-label="Modal Details" role="dialog">
        {modalContent}

        <span
          className="modal-close"
          aria-label="Close Modal Details"
          onClick={toggleVisibility}
        >
          &times;
        </span>
      </div>
    </>
  );

  return isVisible ? ReactDOM.createPortal(modal, document.body) : null;
};

`modal-styles.css`

CSS is needed to display the modal correctly. Styles will be incredibly application-dependent, but I usually start with some fixed positioning and a close button in the top right corner.

.backdrop {
  background-color: rgba(255, 255, 255, 0.6);
  bottom: 0;
  left: 0;
  position: fixed;
  right: 0;
  top: 0;
}

.modal {
  --var-rhythm: 1.8rem;

  align-items: center;
  background-color: white;
  border: 1px solid gray;
  border-radius: 6px;
  display: flex;
  flex-direction: column;
  justify-content: center;
  left: 50%;
  max-width: calc(100vw - var(--rhythm));
  max-height: calc(100vh - var(--rhythm));
  min-width: 300px;
  padding: calc(var(--rhythm) * 2) calc(var(--rhythm) * 2) var(--rhythm);
  position: fixed;
  text-align: center;
  top: 50%;
  transform: translate(-50%, -50%);
  overflow-y: scroll;
}

@media (min-width: 600px) {
  .modal {
    min-width: 600px;
  }
}

.modal > * {
  margin: 0;
  margin-bottom: var(--rhythm);
}

.modal-close {
  color: gray;
  cursor: pointer;
  font-size: 2rem;
  line-height: 1rem;
  padding: 0;
  position: absolute;
  right: calc(var(--rhythm) / 2);
  top: calc(var(--rhythm) / 2);
}

`Component.tsx`

Now, all that is needed to use our modal is to import the hook and Modal.tsx anywhere we need it in our application.

import { Modal } from "../components/Modal";
import { useModal } from "../../hooks/useModal";

export const Component = (): JSX.Element => {
  const [modalIsVisible, toggleModalVisibility] = useModal();
  const modalContent: React.ReactNode = (<p>This goes in the modal.</p>);

  return (
    <Modal
      isVisible={modalIsVisible}
      toggleVisibility={toggleModalVisibility}
      modalContent={modalContent}
    />
  )
};

Have fun making modals ಠ_ಠ! If you have a better pattern for implementing them I would love to be schooled... keep learning!

Debounced and Typesafe React Query with Hooks

Nate Arnold — Wed, 23 Sep 2020 18:31:03 +0000

I recently worked on a project with a search input that loaded results from an external API. The basic problem is simple: User enters search text > component displays a list of results. If you have built one of these before though, you know it's not as easy as it sounds. How do we ensure that a search for "React" doesn't also turn into a search for "R", "Re", "Rea", "Reac" and "React"?

The answer lies in debouncing the fetch calls to the API to give the user time to stop typing. I looked for a lot of solutions to this problem using React Query, and pieced together a couple hooks that work really well together to achieve the desired "debounced query" result I was looking for.

Setup

The following packages are needed to follow along (assuming you are already using a newish version of React in your project):

react-query
axios
typescript

Hooks

Create 2 files for your hooks:

`useDebounce.ts`

This file creates a custom hook that will set a timeout delay on updating state (in this case, to wait on user input). If the timeout exists, it will clear it as well.



import React from "react";

export default function useDebounce(value: string, delay: number = 500) {
  const [debouncedValue, setDebouncedValue] = React.useState(value);

  React.useEffect(() => {
    const handler: NodeJS.Timeout = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    // Cancel the timeout if value changes (also on delay change or unmount)
    return () => {
      clearTimeout(handler);
    };
  }, [value, delay]);

  return debouncedValue;
}

`useReactQuery.ts`

This file creates a custom hook that will accept our query arguments and return a React Query useQuery hook, wrapping an axios.get(), which will hopefully return a Promise with data from our getStuff function.



import { useQuery } from "react-query";
import axios from "axios";

export type QueryResponse = {
  [key: string]: string
};

const getStuff = async (
  key: string,
  searchQuery: string,
  page: number
): Promise<QueryResponse> => {
  const { data } = await axios.get(
    `https://fetchurl.com?query=${query}&page=${page}`
  );

  return data;
};

export default function useReactQuery(searchQuery: string, page: number) {
  return useQuery<QueryResponse, Error>(["query", searchQuery, page], getStuff, {
    enabled: searchQuery, // If we have searchQuery, then enable the query on render
  });
}

Consumption

`Container.tsx`

That's basically it! Now all we have to do is go to our container component and put the hooks to work! Notice we are passing the searchQuery into our debounce hook and passing the result of the debounce to our React Query hook and responding to changes in data or fetching status. You can activate the React Query dev tools and see the resultant queries run in real time (pretty sweet!).



// import { ReactQueryDevtools } from "react-query-devtools";
import useDebounce from "../../hooks/useDebounce";
import useReactQuery from "../../hooks/useReactQuery";

export type ContainerProps = {
  searchQuery: string;
  isFetchingCallback: (key: boolean) => void;
};

export const Container = ({
  searchQuery,
  isFetchingCallback,
}: Readonly<ContainerProps>): JSX.Element => {
  const debouncedSearchQuery = useDebounce(searchQuery, 600);
  const { status, data, error, isFetching } = useReactQuery(
    debouncedSearchQuery,
    page
  );

  React.useEffect(() => isFetchingCallback(isFetching), [
    isFetching,
    isFetchingCallback,
  ]);

  return (
    <>
      {data}
      {/* <ReactQueryDevtools /> */}
    </>
  );
};

Building a Headless WordPress Theme

Nate Arnold — Thu, 10 Sep 2020 17:20:11 +0000

I recently developed a WordPress theme for headless WordPress projects. This post is a simple explanation of the decisions that were made after implementing the theme on a few JAMstack projects.

Highlights

The index route forwards to the /wp-admin login screen so there is no need for any front-end code:

<script type="text/javascript">
    window.location.replace(window.location.protocol + "//" + window.location.hostname + "/wp-admin");
</script>

There is an example Custom Post Type already set up to display in the API as well as in the Graph if you are using WPGraphQL:

  add_action( "init", "create_custom_post_type" );

  function create_custom_post_type() {
    register_post_type("custom_posts", // Register Custom Post Type
      array(
        "labels" => array(
          "name"                => "Custom Posts", // Rename these to suit
          "singular_name"       => "Custom Post",
          "add_new"             => "Add New",
          "add_new_item"        => "Add New Custom Post",
          "edit"                => "Edit",
          "edit_item"           => "Edit Custom Post",
          "new_item"            => "New Custom Post",
          "view"                => "View Custom Post",
          "view_item"           => "View Custom Post",
          "search_items"        => "Search Custom Posts",
          "not_found"           => "No Custom Posts found",
          "not_found_in_trash"  => "No Custom Posts found in Trash"
        ),
        "menu_position"         => 5,
        "menu_icon"             => "dashicons-awards",
        "public"                => true,
        "show_in_rest"          => true,
        "show_ui"               => true,
        "show_in_menu"          => true,
        "publicly_queryable"    => true,
        "capability_type"       => "page",
        "hierarchical"          => false,
        "has_archive"           => true,
        "supports"              => array("title","thumbnail","editor","revisions","excerpt","author"), // Other Options: trackbacks, custom-fields, page-attributes, comments, post-formats
        "can_export"            => true, // Allows export in Tools > Export
        "taxonomies"            => array(), // Add supported taxonomies,
        "show_in_graphql"       => true,
        "graphql_single_name"   => "CustomPost",
        "graphql_plural_name"   => "CustomPosts",
      )
    );
  }

There are example Custom Shortcodes and Custom Taxonomies set up to display in the API as well as in the Graph:

function headless_shortcode( $atts , $content = null ) {
    // Attributes
    $args = shortcode_atts( array(
        "link" => "",
        "target" => "_self",
        "rel" => "",
        "class" => "",
    ), $atts );

    return '<a href="' . $args['link'] . '" target="' . $args['target'] . '" rel="' . $args['rel'] . '" class="btn ' . $args['class'] . '">' . $content . '</a>';

}
add_shortcode( "headless", "headless_shortcode" );
add_filter("acf/format_value/type=textarea", "do_shortcode");

function headless_taxonomy() {
    $labels = array(
      "name"                       => "Taxonomies",
      "singular_name"              => "Taxonomy",
      "menu_name"                  => "Taxonomies",
      "all_items"                  => "All Taxonomies",
      "parent_item"                => "Parent Taxonomy",
      "parent_item_colon"          => "Parent Taxonomy:",
      "new_item_name"              => "New Taxonomy",
      "add_new_item"               => "Add Taxonomy",
      "edit_item"                  => "Edit Taxonomy",
      "update_item"                => "Update Taxonomy",
      "view_item"                  => "View Taxonomy",
      "separate_items_with_commas" => "Separate Taxonomies with commas",
      "add_or_remove_items"        => "Add or remove Taxonomies",
      "choose_from_most_used"      => "Choose from the most used",
      "popular_items"              => "Popular Taxonomies",
      "search_items"               => "Search Taxonomies",
      "not_found"                  => "Not Found",
      "no_terms"                   => "No Taxonomies",
      "items_list"                 => "Taxonomies list",
      "items_list_navigation"      => "Taxonomies list navigation",
    );
    $args = array(
      "labels"                     => $labels,
      "hierarchical"               => false,
      "public"                     => true,
      "show_ui"                    => true,
      "show_in_quick_edit"         => false,
      "meta_box_cb"                => false,
      "show_admin_column"          => false,
      "show_in_nav_menus"          => false,
      "show_tagcloud"              => false,
      "show_in_rest"               => true,
      "show_in_graphql"            => true,
      "graphql_single_name"        => "Taxonomy",
      "graphql_plural_name"        => "Taxonomies",
    );

    register_taxonomy( "taxonomy", array( "page" ), $args );
  }

  add_action( "init", "headless_taxonomy", 0 );

There are some utility functions that help with reorganizing/removing menu items and disabling RSS:

function remove_menus() {
    remove_menu_page( "index.php" ); //Dashboard
    remove_menu_page( "jetpack" ); //Jetpack*
    remove_menu_page( "edit-comments.php" ); //Comments
}

add_action( "admin_menu", "remove_menus" );

function headless_custom_menu_order( $menu_ord ) {
    if ( !$menu_ord ) return true;

    return array(
        "edit.php?post_type=page", // Pages
        "edit.php", // Posts
        "edit.php?post_type=custom_posts", // Custom Post Type
        "separator1", // First separator

        "upload.php", // Media
        "themes.php", // Appearance
        "plugins.php", // Plugins
        "users.php", // Users
        "separator2", // Second separator

        "tools.php", // Tools
        "options-general.php", // Settings
        "separator-last", // Last separator
    );
}
add_filter( "custom_menu_order", "headless_custom_menu_order", 10, 1 );
add_filter( "menu_order", "headless_custom_menu_order", 10, 1 );

All ACF fields that are empty are nullified by default:

// Return `null` if an empty value is returned from ACF.
if (!function_exists("acf_nullify_empty")) {
  function acf_nullify_empty($value, $post_id, $field) {
      if (empty($value)) {
          return null;
      }
      return $value;
  }
}
add_filter("acf/format_value", "acf_nullify_empty", 100, 3);

Headless is available over on GitHub. Download it, peruse it, use it and let me know what you think!

Deploying Gatsby to GitHub Pages

Nate Arnold — Sun, 06 Sep 2020 00:48:07 +0000

Sometimes you just want a simple hosting solution. For Gatsby projects I have been using Gatsby Cloud for builds and pushing to Netlify for hosting. It works well. However, I recently built a couple personal projects with Gatsby that don't need a cloud pipeline and decided to use GitHub pages to host. What follows is everything I had to do to get that working with a project directory as well as with a personal subdomain.

Setting up GitHub to Receive Your Built Files

First, create a branch in your project named gh-pages and push it to your repo.
Next, go to your repo on GitHub and click on "Settings", then "Options" and scroll down to the Pages section:

In the source drop-down menu, select your gh-pages branch:

This will set up the website to deploy from the gh-pages branch to a project directory off your GitHub user domain. For me, the default is arnonate.github.io/<project-name>/.

Setting up Gatsby to Deploy to GitHub

There are a few changes you will need make in your Gatbsy project in order to resolve this directory url:

Install the gh-pages package:

yarn add gh-pages -D

In your gatsby-config.js, add the following line (which should match the project directory created in step 4 above):

module.exports = {
  pathPrefix: `/<project-name>`,
}

Add a deploy script to your package.json:

"scripts": {
  "deploy:github": "gatsby build --prefix-paths && gh-pages -d public",

Run the deploy! Note: If you ever change the pathPrefix setting be sure to run gatsby clean before the next deploy to clear the build cache.

Deploying to an Apex or Subdomain

If you don't want to prefix your pages/assets paths and would rather push to the root directory of an Apex or Subdomain, there are a couple extra steps:

Remove the prefixPaths setting in your gatsby-config.js:

module.exports = {
  pathPrefix: `/<project-name>`, // Delete this line
}

If you have already deployed with this setting, make sure you run gatsby-clean to clear the build cache.
Remove --prefix-paths from your deploy script:

"scripts": {
  "deploy:github": "gatsby build && gh-pages -d public",
}

In your project settings on GitHub, enter your custom domain name or subdomain:

Add/change records for your domain at your domain provider. Specifically, if you are using a subdomain, then add a CNAME that points to your root domain on GitHub (username.github.io). If you are using an apex domain, then you need to point an A record or an ALIAS to GitHub Pages:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Add a CNAME file in the static/ directory of your Gatsby project with your custom domain address:

my-domain-name.com

For an example of a CNAME file, check out my Gatsby/Wordpress starter repo. Check out the full project if you want a starting point for Gatsby, WordPress, TypeScript and Jest!

Loading Gatsby Images Above the Fold

Nate Arnold — Sat, 05 Sep 2020 01:25:36 +0000

Gatbsy ships with a nice utility called gatsby-image (You can check out the API here). When using the <Img /> component in conjunction with gatbsy-image-sharp and gatbsy-transform-sharp you get a modern and graceful way to handle image loading and responsive image sizing.

The default loading prop on a Gatsby Image component is "lazy", however, and this can cause some flickering when navigating from page to page IF your image is above the fold.

Background on Gatsby Image

gatsby-image works by drawing on GraphQL fragments to generate a React component for handling your images. When the component loads it will load with a srcSet of different image qualities, sizes and types. Following a simple example, we query for a local project image using prepared GraphQL fragments:

file(relativePath: { eq: "images/default.jpg" }) {
  childImageSharp {
    fluid(maxWidth: 400) {
      ...GatsbyImageSharpFluid
    }
  }
}

This returns an object with the following interface:

export interface FluidObject {
  aspectRatio: number
  src: string
  srcSet: string
  sizes: string
  base64?: string
  tracedSVG?: string
  srcWebp?: string
  srcSetWebp?: string
  media?: string
}

The API is fairly robust and all the options can be found from the link above. You can use the data returned in a gatsby-image component:

<Img
  fluid={data.file.childImageSharp.fluid}
  alt="Gatsby Docs are awesome"
/>

The result is actually a <picture> element with a srcSet that will load lazily and only load the appropriate image (the image that is best suited for a user's browser).

<div class="gatsby-image-wrapper" style="position: relative; overflow: hidden;">
  <div aria-hidden="true" style="width: 100%; padding-bottom: 16%;"></div>
  <picture>
    <source type="image/webp" srcset="srcSet" sizes="sizes">
    <source srcset="srcSet" sizes="sizes">
    <img sizes="(max-width: 400px) 100vw, 400px" srcset="srcSet" src="src" alt="Gatsby Image" loading="lazy" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; object-fit: cover; object-position: center center; opacity: 1; transition: none 0s ease 0s;">
  </picture>
</div>

Gatbsy Image handles JPEGs, PNGs, WebP and Base64 and will output all of them if you tell it to. I really love this pattern.

Fixing the Flicker

Recently I developed a Gatsby/Wordpress starter repo and used Gatsby Image for the logo in the header. Clicking from page to page the content loads incredibly fast, but the logo image in the header would flicker every time I changed pages. The fix is incredibly simple. When using the <Img /> component above the fold override the default loading behavior.

This:

<Img
  fluid={data.file.childImageSharp.fluid}
  alt="Gatsby Docs are awesome"
/>

Becomes this:

<Img
  fluid={data.file.childImageSharp.fluid}
  alt="Gatsby Docs are awesome"
  loading="eager"
/>

I love simple solutions to slightly annoying UI bugs 😊. Check out my starter repo if you are thinking of starting a Gatsby/WP project soon: https://github.com/arnonate/gatbsy-wordpress-starter.

Gatsby Images and Safari

Nate Arnold — Fri, 04 Sep 2020 22:21:21 +0000

By default Gatsby image places a loading: "lazy" attribute on all images created by the gatbsy-image package. This attribute causes images on the page wait to load until they are in view. When used in conjunction with Low Quality Image Placeholders, the result is a really nice experience in most modern browsers that is performant and aesthetically pleasing.

Safari, however, is yet to implement an important browser API that gatsby-image depends on... Intersection Observer. This can lead to images never loading or loading in an lqip state and never updating.

According to the MDN docs:

The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document's viewport.

This feature is necessary in order to update the image's source once it is in view, which never happens in Safari desktop or iOS.

Luckily, the fix is easy. Simply install the polyfill:

yarn add intersection-observer

Next, let Gatbsy know that you want to load the polyfill once the browser APIs are available. Open up gatsby-browser.js and copy the following snippet:

/**
 * Implement Gatsby's Browser APIs in this file.
 *
 * See: https://www.gatsbyjs.org/docs/browser-apis/
 */

export const onClientEntry = async () => {
  if (typeof IntersectionObserver === "undefined") {
    await import("intersection-observer")
  }
}

Viola! Performant images in Safari with gatsby-image!

You can check out my Gatbsy/WordPress Starter repo for an example of this polyfill in action.

Using CSS Variables to Tame Styled Component Props

Nate Arnold — Tue, 09 Jun 2020 01:46:19 +0000

When I started writing React components about 3 years ago our code base was full of SCSS. This quickly became unmanageable, not because of SCSS, but as a result of all the styles being overwritten in new components as I was converting an Angular library. At the time, afaik(new), there were only 2 ways to keep your styles isolated and scoped in React: Style objects in JS and CSS Modules. The ecosystem has evolved a lot in 3 years. Today we have a lot of options for scoped styles in React. I have leaned towards styled-components for a majority of projects to date.

There are a lot of things I love about this library. From the SCSS inspired syntax to the ability to create and inherit styles, this library is a solid solution for scoping styles to components and implementing it "feels" good to me.

One of my favorite features of styled-components is the ability to pass in props and leverage these props to manipulate styles. It is a lot like using the classnames package without having to declare individual classes for every prop-related style update. The following is an example of a button.

<Button>Click Me!</Button>

const Button = styled.button`
  background-color: gray;
`;

In this example the default Button color is gray. Traditionally, if we wanted to update the background color for a Primary variant of Button we would need to add a className to the Button in order to manipulate the style or pass the background-color override in as a style update on the Button in our jsx.

<Button className="primary">Click Me!</Button>

const Button = styled.button`
  background-color: gray;

  &.primary {
    background-color: blue;
  }
`;

As you can see, styled-components provides a way for us to add variant classes without the need for the classnames package, but there is a better way to handle this built into the styled API. We can manipulate variants based on props that are passed to our Button! Take a look at the following:

<Button variant="primary">Click Me!</Button>

const Button = styled.button`
  background-color: {$props => props.variant === "primary" ? "blue": "gray"};
`;

Now, with a little ternary action, we can actually toggle the color of our button based on the value passed into the variant prop. Cool, right? This is one of the features that makes styled-components feel so React-like.

Normally, this approach is fine, but when we start adding more props-based styles into the mix, our Button can get busy and the variants can be hard to grok when we come back to it for future iterations. Like such:

<Button
  variant="primary"
  shape="rounded"
  weight="bold"
  size="large"
>Click Me!</Button>

const Button = styled.button`
  background-color: {$props => props.variant === "primary" ? "blue": "gray"};
  color: {$props => props.variant === "primary" ? "white": "charcoal"};
  border-radius: {$props => props.shape === "rounded" ? "8px": "0"};
  font-weight: {$props => props.weight === "bold" ? "700": "400"};
  font-size: {$props => props.size === "large" ? "18px": "12px"};
  padding: {$props => props.size === "large" ? "1rem": "0.5rem"};
`;

As you can see, all the variations on our button quickly get lost in the stack of ternary operations inside of our styles block. Not only this, but without adding in a type-checking library it is hard to follow which props we are actually expecting in our styled.button. If we wanted to update only the font-weight of a bold button, we would have to sift through this mess of ternaries. If we wanted to add a 3rd option for font-weight it would get even messier.

Enter CSS Variables.

Fortunately, CSS variables are supported by styled components and can easily be inserted into our styles block to ensure our intentions are clear to the next developer that inherits our button code (or our future selves). Take a look at the styled.button when we apply CSS Variables to every prop option.

<Button
  variant="primary"
  shape="rounded"
  weight="bold"
  size="large"
>Click Me!</Button>

const Button = styled.button`
  --props-variant-default-background-color: gray;
  --props-variant-default-color: charcoal;
  --props-variant-primary-background-color: blue;
  --props-variant-primary-color: white;
  --props-variant-primary: blue;
  --props-shape-default: 0;
  --props-shape-rounded: 8px;
  --props-weight-default: 400;
  --props-weight-bold: 700;
  --props-size-default-size: 12px;
  --props-size-large-size: 18px;
  --props-size-default-padding: 0.5rem;
  --props-size-large-padding: 1rem;


  background-color: {$props =>
    props.variant === "primary" ?
    "var(--props-variant-primary-background-color)" :
    "var(--props-variant-default-background-color)"};
  color: {$props =>
    props.variant === "primary" ?
    "var(--props-variant-primary-color)" :
    "var(--props-variant-default-color)"};
  border-radius: {$props =>
    props.shape === "rounded" ?
    "var(--props-shape-rounded)" :
    "var(--props-shape-default)"};
  font-weight: {$props =>
    props.weight === "bold" ?
    "var(--props-weight-bold)" :
    "var(--props-weight-default)"};
  font-size: {$props =>
     props.size === "large" ?
     "var(--props-size-large-size)" :
     "var(--props-size-default-size)"};
  padding: {$props =>
     props.size === "large" ?
     "var(--props-size-large-padding)" :
     "var(--props-size-default-padding)"};
`;

Alright, I know, this approach is more verbose for sure. It will take you more lines of code than the original implementation. However, your future self will thank you, because there is no need for guessing or fishing through ternaries or switch statements. It is very obvious where I go to update the font size of a large variant to 20px. It is also clear what props we are expecting.

We can also use CSS Variables to toggle properties inside of media queries:

const Button = styled.button`
  --props-size-default: 12px;
  --props-size-large: 18px;

  @media screen and (min-width: 860px) {
    --props-size-default: 14px;
    --props-size-large: 20px;
  }

  font-size: {$props =>
     props.size === "large" ?
     "var(--props-size-large)" :
     "var(--props-size-default)"};
`;

That is all! Have fun adding CSS Variables to your Styled Components! Let me know any other ways you have incorporated CSS Variables into your React workflow.