DEV Community: Wesley Handy

New Tools, New Friends: Reflecting on JAMStackConf_SF 2019

Wesley Handy — Mon, 21 Oct 2019 00:00:00 +0000

This past week, I had the joy of attending the JAMStackConf in San Francisco with 550 other excited and curious developers. For those not familiar, yet, with the JAMStack, it stands for J avascript A PIs M arkup.

It's an approach to developing applications that result in highly performant static sites that consume APIs for dynamic content.

Lest you be dissuaded by the term static, this refers to what the browser receives not to how interactive a web application can be. In fact, Static Site Generators (SSG), like Gatsby, could be considered replacements for framework boilerplates like create-react-app. Not to start an argument there, there are plenty of resources online to familiarize yourself with the JAMStack, if you are so inclined.

For now, I want to offer a few reflections on my experience at the conference and the state of the JAMStack that I gathered from participating.

Watch JAMStackConf Videos

The Future of the JAMStack is Dependent on Solutions That Are Being Developed and Those That Are Launching

Some of the biggest hurdles for developers interested in developing on the JAMStack involve OAuth, Live Edits, Live Preview, CMS Solutions that are non-developer friendly and trusted, and handling builds of Large Sites, handling builds with a large volume of content production 24 hours of the day. Several of these questions received answers this week:

Sean Grove of OneGraph demoed an amazing graphql product that seamlessly integrates OAuth with several popular services.
Scott Gallant of Forestry.io announced the launch of TinaCMS with its widget for live-editing React-based sites.
Ohad Eder-Pressman of Stackbit revealed their awesome tool for quickly combining Themes, SSG, and CMS for quick builds or just testing out new tools.

These are just a few of the tools we heard about and were able to talk about later with vendors.

There is a Growing History of High Volume Campaigns for Major Firms Being Run On the JAMStack

Besides showcases like those on Gatsby's site, it's great to hear from major corporations and major agencies finding the JAMStack to be a solution for many of the problems they have faced with quick turnarounds, organizing development workflows and teams, and providing high-quality performance at scale.

Justin Watts from Loblaw Digital shared with us how they were able to redirect a corporate culture towards greater efficiency while producing major sites used by millions of Canadians.

Two of the more broadly well-known viral social movements of the past two years— The Kaepernick Nike Campaign and The Chicken Sandwich Wars of 2019 —had behind them JAMStack solutions that were able to handle hundreds of thousands of users at a time.

At the Restaurant Brands International booth I heard it said (in so many words):

The chicken may have run out, but the website surely didn't

Netlify Function, Serverless Functions, etc., are a necessary tool to master to take full advantage of the JAMStack.

I was fortunate to be able to attend the Serverless Workshop led by David Wells. Check out his stuff wherever you can find it (like here on Github).

The key to creating dynamic JAMStack applications is mastering the middle-letter of the JAM—APIs. I feel very empowered by what I learned from David. His workshop was deep where needed and broad where needed. I left with a million use-cases buzzing around my brain.

Is there a traffic JAM ahead? While it seems there is a growing number of devs who love the JAMStack, I talked to very few who had the opportunity to work on it day-to-day in their current position or who thought it's unlikely they ever could at their current job.

If this paragraph is all you read, this is the most important takeaway I had from the conference. I am confident in the direction of the JAMStack, the progression of the development and release of dev tooling, the quality and ease of use of the development, build and deployment process, but, but, but, and perhaps this is always the case with new tech (legacy code), I along with many other developers have little chance to use the stack without changing jobs, going freelance, or building stuff on the side.

Could this create a ceiling for the JAMStack?

I, for one, intend on using it in all my side-work. But, honestly, I have a wife and three kids. I can't be coding 10-12 hours a day. I need my coding passions to line up with my employment or fughetaboudit!

That is some sweet tasting JAM

I said the previous paragraph was the most important, it is, for the sakes of my thoughts on the stack, but this is my favorite. I really enjoyed getting to know other developers at this conference.

Stephen Bau is a full-stack developer and UX design mentor in the Vancouver, BC, area. He is super friendly and it was a joy meeting him.
Ozzy Lopez is a self-taught developer with Snap-On Diagnostics. He is a very knowledgeable developer and was a great person to spend time chatting over how to use the tools we were learning about.
Monica Norris is a Front End Developer in the Chicago area. She really impressed me as a person. She continually connected with new people and then connected them with each other. I met at least four people just because of her. She would be an asset to any team and I think would be a great team leader. Honestly, is there a ceiling for her? No ceiling at all.
Derek Fields is a developer from Baltimore who knows his stuff, he's a great listener, but when he speaks, you need to listen. You can tell he has put a lot of thought in what he says.
Amit Rathi we all heard from the podium. He is a Freelance Developer who is very knowledgable about Wordpress. I want to mention him because he took time out of his lunch to chat with me about some Wordpress issues I was encountering at work with the wp-json REST api.

Finally, I want to share a story with you about Sean Grove from OneGraph.

Servant Leadership Exemplified

When I sat next to Sean over lunch, I had no idea who he was at the time. We were all wowed by his presentation not one hour later. Over lunch, he was very cordial, friendly, and engaging with everyone around the table. He didn't talk about himself, but asked us questions about who we were and what we did. So humble. That day we were served Cornish hens (with plastic forks....) and behold, my fork busted in half. Before I could do anything, without a word, Sean went and grabbed me new silverware. Then he chatted with me a bit as lunch was ending.

Why do I share this with you?

We not only need great technology to change the world, we need great people. Here is a founder of a new startup, being humble and through that showing great strength. I think we need more people like Sean and should ourselves try to emulate that type of servant leadership. Match it with some serious public speaking chops and you have someone people will follow.

This is also a proxy for what coding is all about.

Anthropologists have long recognized that technology is simply an extension of humankind. The JAMStack, or whatever stack, company, job, or whatever, tech is always about people. What we produce is intended to help others in some way, shape, form, or fashion.

I've been encouraged this past week to remember people when I code. People I love, people I work with, people I meet, and really all people. We never know how far some piece of code we craft will go, nor how many others it will touch.

That's humbling and yet exciting to think about, isn't it?

Cleaning Up Wordpress: Lessons Learned in Website Security

Wesley Handy — Fri, 20 Sep 2019 00:00:00 +0000

You've been working on a project for months, you've handed the keys over to the client, and then you get that dreaded email...

... on page [x] some users have been experiencing weird advertisments and popups. I think the site has been hacked! I don't know what to do. Please help! ...

I faced this situation recently. I volunteered to finish up a project for a nonprofit organization (not the one where I work 9 -5). They were one year into a new site build when the developer they originally hired ghosted them.

I'm a JavaScript guy, so I wasn't all that familiar with the entirety of the Wordpress ecosystem, but I figured I knew enough, I had been building my own plugin for work to inject a React application via a shortcode, thinking, "How hard can it be? It's not even real development..." (don't get offended, just expressing what I was thinking at the time).

I was very aware of security issues in a Node.js environment, but I had always relied on other services to take care of hosting security. I had heard of .htaccess files, but I'd never put my own LAMP stack application into production from scratch. I hadn't even given it any thought since I have been focusing more and on tech like React, Gatsby, React Native, and even a little Angular.

As easy (in terms of difficulty) it was to handle all the front-end requests of getting the site finished to the client's expectation, I took for granted my own ignorance of the rest of what was involved. I want to share what I have learned over the past two weeks so that (1) I won't forget next time, and (2) so you can avoid many of the mistakes I made.

I am going to try and provide links to all the sources that have helped my in my recent journeys and to briefly talk through some of the more important parts. Let's call this:

Wordpress Security 101

1. Always Hire a Developer You Either Know or Can Verifiably Trust

It is very tempting to hire the cheapest developer you can find. But sometimes you get what you pay for.

I like that there are sites where developers can be rated, or public reviews left, like Upwork or LinkedIn (want to suggest others?). These help provide accountability for the developer and some sense of security for the client. In this particular case, the original developer took a low fee for a quite complex site and cut a bunch of corners.
Links:

https://www.upwork.com/

2. Never download and use unlocked or nulled themes - pay the regular fee from a reputable theme marketplace. Otherwise, you may install Malware!!!

I didn't even question the use of the theme on the client's site. Knowing the client, I assumed they would have purchased the theme themselves but it turns out they left it to the developer, who perhaps out of ignorance or a willingness to cut corners downloaded a theme online that was corrupted with the wp_vcd malware.

I only discovered how long the malware had been there by comparing the current site with versions of the codebase that existed while the site was offline or in maintenance mode.

This particular Malware was found within functions.php, and it created three files within wp-includes: wp-feed.php, wp-vcd.php, wp-tmp.php. It wrapped pages with malvertising scripts and also added a script that logged user's IP addresses who had permissions to edit the site and systematically ignored those users, so they would never detect the malicious behavior when browsing the site themselves, whether logged in or not, whether browsing privately or not.

After logging into the remote server as an administrator-level user, I found the odd looking files at first within the wp-includes folder. I removed them, thinking I had solved the problem. The Malware was creating redirects to sites with the oclaserver domain and logging IP addresses to wp-feed.php. I used the following command-line script to find these files.

grep -Ril "oclaserver"

grep searches files for lines matching a given pattern.
R makes the search recursive, looking through all files and directories within the current director
i ignores case
l suppresses the output to only list the filename

Initially, I though this solved the problem, but the next time I checked, the files where back. I deleted the files, then checked again, immediately, the files were once again there, full of the same content. This means either my wpdb was corrupted, or some other file that gets called repeatedly by Wordpress was corrupted, or possibly both.

What did I do next?

Before scouring through my DB in phpMyAdmin, I first identified and deleted all unused themes and plugins. The files kept appearing. So I started searching for terms within the files.

What found me the culprit was that within wp-temp the code was setting a password variable. My only thought is that this was a hash of the admin password (so I made a note to change the admin password after cleaning up). I ran the same grep command but searched instead for that password value.

Lo and behold, the functions.php of the parent theme lit up. There, I found a bunch of hacky code that was wrapping all the pages with the malicious script and systematically ignoring the IPs where an admin user had been logged in.

After deleting the code, I deleted the malicious files from within wp-includes and the files didn't return. I wasn't yet certain the Malware was completely gone because I noticed that the code in wp-temp was creating a cookie on the client.

Before changing the admin password, I reset the SALT Keys within the wp-config.php file using https://api.wordpress.org/secret-key/1.1/salt/.

Then, I cleared the cache and cookies from my browser, and logged into the wp-admin of the site from an incognito window. Only then did I reset the admin password.

Finally, I created a new admin user for myself and encouraged the client to add 2FA for their login via the Google Authenticator Plugin.

Links:

3. On your server, add a new user and remove root login to make it harder for someone to hack your server.

Since the client already had their site installed and running on Ubuntu 18.04 a Digital Ocean droplet, the previous developer had ssh access to the droplet. I really didn't want them to be able to log back in, whether or not they had nefarious intent. I noticed there was only one root user on the system, so I created a new user for myself:

sudo adduser myuniqueusername

I then added my new user to the sudo user group:

sudo usermod -aG sudo myuniqueusername

And then I added administrative privileges to myuniqueusername:

sudo visudo

Within /etc/sudoers:

myuniqueusername ALL=(ALL:ALL) ALL

Finally, within /etc/ssh/sshd_config:

PermitRootLogin no

Then from command-line, restart ssh:

sudo service ssh restart

From there, do whatever is necessary to create ssh keys for your new account, set those up, logout, and then ssh back in as you.

4. Harden file permissions on the server to prevent unwarranted changes. From within the root directory of your Wordpress installation (perhaps /var/www/html/) do the following:

Find what groups your user and your server belongs to and make sure that your user has ownership of all your Wordpress files.

sudo groups
sudo usermod -aG groupname myuniqueusername
sudo find . -exec chown myuniqueusername:groupname {} +

Change files to only be writable by owner (you), and only readable by others, Change directories to be only be created, modified, or deleted by you or Wordpress, and prevent anyone other than you or wordpress from reading or writing to wp-config.

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

Links:

5. Add hardening to your httpd.conf Apache configuration by disabling Server banners, hardening your .htaccess file, by disabling directory listing, disabling HTTP Trace, preventing MIME sniffing, preventing clickjacking, preventing some forms of cross-site scripting, and securing your cookies within wp-config.php.

Within /etc/apache2/httpd.conf or /etc/apache2/apache2.conf:

ServerSignature Off
ServerTokens Prod

Then from command-line:

sudo service apache2 restart

Within .htaccess, insert between # BEGIN Wordpress and # END Wordpress:

Options -Indexes
RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F]
Header set X-Content-Type-Options nosniff
Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection "1; mode=block"

Within wp-config.php, add to the end:

@ini_set('session.cookie_httponly', true);
@ini_set('session.cookie_secure', true);
@ini_set('session.use_only_cookies', true);

There is some discussion over whether or not the above method is best, you could and perhaps should also add cookie hardening to your apache server configuration, see links below.

Links:

6. Add Security Plugins like Sucuri Sanner and Limit Login Attempts.

Links:

Final Thoughts

The list above is by no means exhaustive, and it's just based on things I've been learning the past couple of weeks. I am very open to correction, addition, or subtraction, from the above by anyone with more experience. While I don't plan on focusing primarily on Wordpress, I'm learning more and more LA of the LAMP stack through this experience, and at the end of the day, with my interest in Gatsby, I probably will be involved more and more with the ecosystem.

That being said, there is nothing wrong with learning more about website security.

Even if static sites are the future, keeping our CMS and web-servers safe should not become lost or remain assumed knowledge.

Improving Touch Events upon an Infinite Scrolling Component

Wesley Handy — Mon, 10 Jun 2019 00:00:00 +0000

In my recent blog post on Using React Hooks to set up Infinite Scroll, I created a working version of infinite scroll that works in both desktop and touch screen environments. However, I came across a problem I did not anticipate when I put it into production, some of the links on my page stopped working. I tried debugging my CSS, to no avail, only to realize the solution involved updating my touchend event handlers with a very simple fix.

Solution: Debugging CSS ??

The structure of my components nests some links within block level elements. To acheive infinite-scrolling, I map over a list of businesses as follows:

<li key={govId} index={idx + 1}>
  <h2>
    <Link 
      to={ `/businesses/${businessName}` } state={{ 
        prevPath: typeof window !== `undefined` ? window.location.pathname : ''
      }}
    >
      {businessName}
    </Link>
  </h2>
  <p>
    <a href={`tel:${businessPhone}`}>{businessPhone}</a>
  </p>
</li>

From past experience, I immediately thought the solution would be to either adjust the z-index of the nested link or to set pointer-events on the parent elements. I tried both:

    li, li>h2, p { 
        pointer-events: auto;
        z-index: 1;
    }
    li>h2>a, p>a {
        z-index: 3;
    }

Neither solution solved the problem nor were a problem to begin with, at least in my implementation.

Solution: Debugging `touchend` Event Handler !!

First, here is the initial state of my code for this component. I define handleScroll to add more items to the infinite scroll. Then, handleTouchEnd calls the scroll event handler to avoid double loading. Take particular note of e.preventDefault (perhaps this shouldn’t be called at all? We shall find out soon enough):

  const handleScroll = () => {
    if ( !hasMore ) return;
    if ( window && 
       ( window.innerHeight + 
         document.documentElement.scrollTop >=
         document.documentElement.offsetHeight ) 
    ) {
      loadMore() // function to add more items to the infinite scroll until no items left
    }
  }

  const handleTouchEnd = (e) => {
      e.preventDefault(); handleScroll();
  }

  useEffect(() => {
    window && window.addEventListener('touchend', handleTouchEnd)
    window && window.addEventListener('scroll', handleScroll)
    window && window.addEventListener('resize', handleScroll)
    return () => {
      window && window.removeEventListener('touchend', handleTouchEnd)
      window && window.removeEventListener('scroll', handleScroll)
      window && window.removeEventListener('resize', handleScroll)
    };
  }, [businesses, hasMore])

After realizing that updated my css would not resolve my issue, I wondered what in the world is causing my problem. In this particular component, I use two React hooks to manage state and handle events - useState and useEffect. I wondered,

Okay, so this is a Gatsby project, and I'm importing the Link component from the gatsby library. Could these hooks be interfering with the functionality of the Link?

This wasn’t the problem. I could see in the console that Link rendered a simple a tag, and other Link components were working on the page, such as those rendered by the Navigation component. The only links not working were within my infinite scrolling list component. Moreover, the links worked perfectly in a desktop environment. So I again wondered,

Why in the world does this work on desktop and not on mobile? No errors are being thrown. The href attribute is valid and working if I paste it in the browser. How again does the touchend event work?

This led me to investigating the order in which events are fired by touch screens.

`click` comes after `touchend`

According to MDN, the W3C standard calls for a typical order of events fired by touch screens, as follows:

touchstart
Zero or more touchmove events, depending on movement of the finger(s)
touchend
mousemove
mousedown
mouseup
click

Remember I asked you to take particular note that I was calling e.preventDefault() on the touchend event? Turns out that is the culprit. By cancelling the dispatching of further events on touchend, the click event for the link component was never being fired. As MDN tells us:

If the touchstart, touchmove or touchend event is canceled during an interaction, no mouse or click events will be fired.

The solution then must include not calling e.preventDefault, particularly when a link is the target of touchend.

So, the only change necessary involves adding a condition within my handleTouchEnd function, to check for a tags, or Element.tagName == "A", and only call e.preventDefault() if the target is not such a tag:

const handleTouchEnd = (e) => {
  if (e.target.tagName !== "A") {
    e.preventDefault(); 
    handleScroll();
  } else {
    console.log("this makes me a click event, most likely")
  }
}

Photo by Amy Humphries on Unsplash

Adding Infinite Scroll For Both Desktop and Mobile in Your Gatsby Project with React Hooks

Wesley Handy — Mon, 20 May 2019 00:00:00 +0000

I recently created my second production Gatsby application that gives a simple presentation of a local government open data dataset. I say production, though, much of the application is a proof-of-concept for a bigger application I have in the works (perhaps a startup in the mix? Not sure yet...). My app includes over 2400 nodes, so I needed a way to present the data in user-friendly ways. Each record in my collection included a set of categories, so I could easily create a categories page and split the data that way. However, I also want to eventually add search and also allow for a user to browse through the entire dataset. This is where I looked into pagination and infinite-scroll. You can read about adding pagination on the Gatsby blog—it’s pretty straight-forward. Below is how I set up infinite-scroll that works in both development and production environments, as well as both in the browser and on touch screens. I was able to accomplish this using React Hooks within a functional component rather than a class-based component.

Inifinite Scroll & React Hooks

As much as this post is about integrating this within Gatsby, this is properly a react question. Gatsby is simply a platform for sourcing data. This could easily be implemented via fetch-ing of data from an API during client-side component. Adjust this method to what you need in your case.

Setting Up `gatsby-node.js`

Within gatsby-node.js you will define an export named createPages that queries graphql for nodes from your data source and returns that list of nodes. Before returning, you can call the createPage API as many times a you need to generate your site. I intend, among many other things, to create a single page that generates and infinite scroll through my list of businesses. I will call createPage, passing to it the path of the page, the template for the page, and data that will be provided to the client via the Context api:

exports.createPages = ({ actions, graphql }) => {
  const { createPage } = actions
  return graphql(`
    {
      #some query specific to your source data
      specificNameOfYourQuery {
        edges {
          node {
            #specific fields
          }
        }
      }
    }
  `).then(result => {
    if (result.errors) {
      return Promise.reject(result.errors)
    }
    const { data: [specificNameOfYourQuery]: edges } } } = result;
    const infiniteScrollTemplate = path.resolve(`src/templates/infinite-scroll-template.js`)
    createPage({ 
      path: "/businesses", 
      component: infiniteScrollTemplate, 
      context: { 
        edges,
      },
    }) return edges;
  })

Creating the Template that Will Include Infinite Scroll

From the root of your project, go into your src directory, create a templates folder if it doesn’t already exist, then create your template page. I entitled mine infinite-scroll-template.js.

cd src
mkdir templates
cd templates
touch infinite-scroll-template.js

React Hooks - `useEffect` and `useState`

Once you have opened your template file within your IDE, you will need to import React as well as the useEffect and useState hooks. For Gatsby projects, you will also import your Layout component so that your page will match the rest of your site. The createPage API passes to your component pageContext as props where you can access the list of edges you pass to your template from gatsby-node.

import React, { useState, useEffect } from 'react'
import Layout from '../components/Layout'

function InfiniteScroll({ pageContext: { edges } }) {
    return null
}

function InfiniteScrollTemplate(props) {
  return (
    <Layout {...props}>
      <InfiniteScroll {...props}/>
    </Layout>
  )
}

export default InfiniteScrollTemplate

We will focus on adding the core logic for infinite scroll to the InfiniteScroll functional component. We do not need to declare a React class because of the two aforementioned hooks—:useState and useEffect

Creating and Setting Internal State with `useState`

React hooks allow us to write functional components that can “hook into” other React features. useState allows us to add state that is preserved between renders of a functional component. Unlike state within a React class, useState replaces the previous state rather than merging with previous state. Calling useState takes only one argument, whatever you conceive of as the initial state. The useState hook can be called multiple times, so rather than having a single state object, you can have multiple state-like variables. This is because the call to useState returns an array of two properties - the value of the current state and a function to call to update the value of that state.

const [currentState, setState] = useState(/* some initial value or function that returns a value */)

For infinite scroll to work in this example, we need two state variables—a boolean indicating if there are more records to load and an array of the records already loaded. Seed the currentList with the first 10 records. Don’t worry if there is the possibility that the initial set is less than 10, Array.slice will return all records up to the length of the array if you provide an ending value greater than the last index of the array.

Note: if we had a situation where you loaded data asynchronously from an API, we would also need someway to determine if data was in loading state

const [hasMore, setMore] = useState(edges.length > 10)
const [currentList, addToList] = useState([...edges.slice(0, 10)])
const [isLoading, setLoading] = useState(false) // if loading from an API asynchronously

Creating Event Handlers to Read and Set State

Reading and setting state will occur within an event listener on the scroll position of the page. If you use an external api and that api is still loading content, we will return immediately, and we will also exit if we know there are no more edges to load. Otherwise, we will check to see if the scroll position of the document plus the innerHeight of the window equals the offsetHeight of the document, and if so, we can load more edges. Basically, this checks to see if the page is scrolled all the way to the bottom.

const handleScroll = () => {
  if ( !hasMore || isLoading ) return;
  if ( window.innerHeight + document.documentElement.scrollTop === document.documentElement.offsetHeight ){
    loadEdges(true)
  }
}

The loadEdges function will do the following, in order:

if using an asynchronously api call, will set the loading flag to true
determine if any more edges remaining
slice a new chunk of edges and append to the current list
if using an asynchronously api call, will return the loading flag to false

Since I’m loading from the Context API, I will ignore steps 1 & 2 above.

const loadEdges = () => {
  const currentLength = currentList.length
  const more = currentLength < edges.length
  const nextEdges = more ? edges.slice(currentLength, currentLength + 20) : []
  setMore(more)
  addToList([...currentList, ...nextEdges])
}

How would isLoading be used?

Here is one overly simplistic example:

const loadEdges = async () => {
  setLoading(true);
  try {
      const newEdges = await fetch('https://path/to/some/api')
      const more = newEdges.length > 0
      setMore(more)
      addBusinesses([...currentList, ...nextEdges])
  } catch(err) {
      console.error({fetchNewEdgesError: err})
  }
  setLoading(false)
}

Checking The Scroll Position on Each Render with `useEffect`

The final step to initializing infinite scroll is the useEffect hook. The hook useEffect takes two arguments: a function, and an array. The first argument is the function that will be called every time after the component is rendered. This function is allowed to return another function which will be remembered and gets called as a cleanup function (I’m not sure I fully understand cleanups yet, but I think Dan Abramov does). The second argument is an array of dependencies that would prevent an effect from being called if the values of those dependencies are unchanged between renders. Infinite scroll will a function with a cleanup callback as well as the array full of dependencies to work.

useEffect(
  () => {
    /* function that gets called every time */
    return () => {
      /* cleanup function to be called */
    }
  }, [/* dependencies */])

useEffect is a great place to initialize event listeners on the window or document, as well as to remove those listeners during cleanup, such as listening for scroll events.

  window.addEventListener('scroll', handleScroll)

And thus, the cleanup function:

  window.removeEventListener('scroll', handleScroll)

This gives us an almost complete useEffect function call, we will simply add our state variables to the dependencies array so that effect is only set or cleaned up when the variables change:

useEffect(
  () => {
    window.addEventListener('scroll', handleScroll)
    return () => {
      window.removeEventListener('scroll', handleScroll)
    }
  }, [hasMore, isLoading, currentList])

With state, event handlers, effects initialized, we are free to return the jsx for the scrolling list. The following maps over the currentList array. It also adds labels displaying the current state of the list:

return (
  <> {/* shorthand for React.Fragment */}
    <ul>
      {
        currentList.map(({node: { fields }}, idx) => {
          return (
            <li key={`fields-${idx}`} index={idx + 1}>
              { 
                /* you will know the specifics here from how you load your data */
                fields 
              }
            </li>
          )
        })
      }
    </ul>
    {
      !hasMore &&
        <div>All Businesses Loaded!</div>
    }
    {
      hasMore &&
        <div>Scroll Down to Load More...</div>
    }
    {
      /* if using this flag, otherwise omit */
      isLoading && 
        <div>Loading...</div>
    }
  </>
)

Putting It All Together

Now we have a complete picture of the infinite scroll functional component. See below, but don’t leave yet, we still have to account for gatsby build and mobile events.

import React, { useState, useEffect } from 'react'
import Layout from '../components/Layout'

function InfiniteScroll({ pageContext: { edges } }) {
  const [hasMore, setMore] = useState(edges.length > 10)
  const [currentList, addToList] = useState([...edges.slice(0, 10)])

  const loadEdges = () => {
    const currentLength = currentList.length
    const more = currentLength < edges.length
    const nextEdges = more ? edges.slice(currentLength, currentLength + 20) : []
    setMore(more)
    addToList([...currentList, ...nextEdges])
  }

  const handleScroll = () => {
    if ( !hasMore ) return;
    if ( window.innerHeight + document.documentElement.scrollTop === document.documentElement.offsetHeight ){
      loadEdges()
    }
  }

  useEffect(() => {
    window.addEventListener('scroll', handleScroll)
    return () => {
      window.removeEventListener('scroll', handleScroll)
    }
  }, [hasMore, currentList])

  return (
    <> {/* shorthand for React.Fragment */}
      <ul>
        {
          currentList.map(({node: { fields }}, idx) => {
            return (
              <li key={`fields-${idx}`} index={idx + 1}>
                { 
                  /* you will know the specifics here from how you load your data */
                  fields 
                }
              </li>
           )
          })
        }
      </ul>
      {
        !hasMore &&
          <div>All Businesses Loaded!</div>
      }
      {
        hasMore &&
          <div>Scroll Down to Load More...</div>
      }
      {
    </>
  )
}

function InfiniteScrollTemplate(props) {
  return (
    <Layout {...props}>
      <InfiniteScroll {...props}/>
    </Layout>
  )
}

export default InfiniteScrollTemplate

This functional component will work just fine during development on a desktop browser. But you will lose the scroll effect during the build and on touch screens. It will fail during build because client globals like window and document are undefined during the build. It will fail on mobile because scroll is a mouse event. We need to add some conditions for our event listeners to handle both conditions.

Optimizing for Production and Touch Screens

In addition to adding an event listener on scroll, we also need event listeners for touchend and resize (to handle situations where someone resizes their browser), plus we need to add preventDefault to touch events to prevent duplicate events being fired in certain situations where devices have both a mouse and a touch screen. First, create a new event handler for handling touchend. This new handler will simply prevent the default actions on touchend and call the handler for the scroll event (which simply checks to see if we should load more documents). Second, update the useEffect function to add the additional event handlers.

const handleTouchEnd = (e) => { e.preventDefault(); handleScroll();}
useEffect(() => {
  window.addEventListener('scroll', handleScroll)
  window.addEventListener('resize', handleScroll)
  window.addEventListener('touchend', handleTouchEnd)
  return () => {
    window.removeEventListener('scroll', handleScroll)
    window.removeEventListener('resize', handleScroll)
    window.removeEventListener('touchend', handleTouchEnd)
  }
}, [hasMore, currentList])

Finally, we need to add a few simple boolean checks (window &&) to every instance of window or document so that the build process succeeds and so that infinite scroll still operates in the client. Plus, we need to change the scroll position check to be >= instead of the strict equality ===.

const handleScroll = () => {
  if ( !hasMore || isLoading ) return;
  if ( window && ( ( window.innerHeight + document.documentElement.scrollTop ) >= document.documentElement.offsetHeight ) ){ loadEdges()
  }
}
useEffect(() => {
  window && window.addEventListener('scroll', handleScroll)
  window && window.addEventListener('resize', handleScroll)
  window && window.addEventListener('touchend', handleTouchEnd)
  return () => {
    window && window.removeEventListener('scroll', handleScroll)
    window && window.removeEventListener('resize', handleScroll)
    window && window.removeEventListener('touchend', handleTouchEnd) }
}, [hasMore, currentList])

There you have it! You have a component that will implement infinite scroll in the browser, on touch screens, and in production within a Gatsby or React application.

Check out the following page in your browser and on mobile to see this code in action.

You can also see my specific implementation of the source code on github.

Putting SEO First with Gatsby

Wesley Handy — Sat, 20 Apr 2019 00:00:00 +0000

I was drawn to Gatsby out of my love for React, and my desire to serve fast, perfomant, responsive applications. I started learning React just as the library started embracing ES6 classes, and just as create-react-app was taking off. It was a challenge at first to learn the simplicity of proxying to get the front end to run concurrently with a node / express API. And yet, to get from that point to server-side rendering took a little more research and effort. It has been fun learning with and from the larger coding community. I could continue to enumerate the other technical issues I have encountered and solved, and yet some others I still have to learn, but note something important so far regarding my journey—it has been a techinical-first-journey, focused on knowledge and skill of the various langauges and libraries, necessary yes, but perhaps not primary. The last thing on mind has been SEO , accessbility , and security.

Setting An SEO-First Mindset

I’ll leave accessibility and then security future posts, but what has impressed me thus far in my dive into the Gatbsy ecosystem has been the ease to configure search engine optimization. In fact, you can create an architecture for your site or app that is SEO driven long before developing your UI. I want to walk you through the things I have learned so far in optimizing a Gatsby site for SEO right from the start.

Before We Begin

You need to have some familiarity with Gatsby. To learn how to install the gatbsy-cli and create a new Gatsby project from one of the many Gatsby Starters, please consider completing the Gatsby tutorial.

Otherwise, pick a starter from the SEO category, and open the SEO component or just use the gatsby-starter-default by running from the command line:

gatsby new seo-blog https://github.com/gatsbyjs/gatsby-starter-default

The SEO component is dependent upon react-helmet, if your starter does not come with SEO initialized be sure to add it. We also want to add some other features like sitemap, google analytics, and RSS feed, for syndication. Finally, we need to create robots.txt to manage how search engines crawl the site. I’ve split up the commands below for spacing purposes, but they can all run as one yarn add command:

yarn add react-helmet gatsby-plugin-react-helmet 
yarn add gatsby-plugin-feed gatsby-plugin-google-analytics gatsby-plugin-sitemap
yarn add gatsby-plugin-robots-txt

With your starter and these plugins installed, we are ready to set up our site for SEO Performance.

Setting up `gatsby-config.js`

Within the root of your new Gatsby project sits the file Gatsby uses to configure siteMetaData and plugins and several other important features.

This file, gatsby-config.js is going to do the heavy lifting of importing all your vital SEO related content into GraphQL or create necessary files directly (like robots.txt).

Site Metadata

Metadata is as it sounds, data that extends across or throughout the entirity of your site. It can be used anywhere, but will come most in handy when configuring your SEO component as well as Google Structured Data.

Initialize your metadata as an Object literal with key/value pairs that can be converted into <meta> tags, or can be passed to sitemaps or footers, wherever you might need global site data:

<meta name="title" content="My Super Awesome Site"/>
<meta name="description" content="My Super Awesome Site will blow your mind with radical content, extravagant colors, and hip designs."/>

Here is where you need to plan what might use across your site:

title
description
keywords
site verification
social links
other

With siteMetadata set up, your can now query this data to be used within your plugin initialization, even within the same gatsby-config.js file. I’ve organized my siteMetadata so that I can make the following query:

query: `
  site {
    siteMetadata {
      title
      description
      author
      siteUrl
      siteVerification {
        google
        bing
      }
      social {
        twitter
      }
      socialLinks {
        twitter
        linkedin
        facebook
        stackOverflow
        github
        instagram
        pinterest
        youtube
        email
        phone
        fax
        address
      }
      keywords
      organization {
        name
        url
      }
    }
  }
`

This query returns an object matching this query structure:

site: {
  siteMetadata: {
    title: String,
    description: String,
    author: String,
    siteUrl: String,
    siteVerification: {
      google: String,
      bing: String
    },
    social: {
      twitter: String
    },
    socialLinks: {
      twitter: String,
      linkedin: String,
      facebook: String,
      stackOverflow: String,
      github: String,
      instagram: String,
      pinterest: String,
      youtube: String,
      email: String,
      phone: String,
      fax: String,
      address: String
    },
    keywords: [String],
    organization: {
      name: String,
      url: String
    }
  }
}

Plugin Setup

We are going to focus on four plugins, each for the sitemap, RSS feed, robots.txt file, and Google Analytics (for tracking the SEO success of your site). We’ll initialize the plugins immediately following siteMetaData.

module.exports = {
    siteMetadata: {
      / **SEE ABOVE** /
    },
    plugins: [/ **An ARRAY** /], }

gatsby-plugin-sitemap

The sitemap plugin can be used simply or with options. Generally, you want to include anything and everything with high quality content, and exclude duplicate content, thin content, or pages behind authentication. Gatsby provides a detailed walkthrough for setting up your sitemap.
```
plugins: [
{
resolve: `gatsby-plugin-sitemap`,
options: {
  exclude: [`/admin`, `/tags/links`] 
}
},
]
```

gatsby-plugin-feed

An RSS feed helps with syndication of content on your site, like if you had a blog and wanted to cross-post to another better established blog, and it helps communicate changes to your site to search engines. This plugin allows you to create any number of different feeds utlizing the power of GraphQL to query your data. Some of what is below is dependent on how you structure your pages and posts in gatsby-node.js. The feed will walk through each of your pages in markdown generate an XML RSS Feed. Gatsby provides a detailed walkthrough for adding an RSS feed.

Note particularly the use of queries below to complete the feed.

{
resolve: `gatsby-plugin-feed`,
options: {
// graphQL query to get siteMetadata 
query: ` 
  { 
    site { 
      siteMetadata { 
        title 
        description 
        siteUrl 
        site_url: siteUrl, 
        author 
      }
    }
  } 
`, 
feeds: [
  // an array of feeds, I just have one below
  {
    serialize: ({ query: { site, allMarkdownRemark } }) => {
      const { siteMetadata : { siteUrl } } = site;
      return allMarkdownRemark.edges.map(edge => {
        const { 
          node: { 
            frontmatter: {
              title, 
              date, 
              path, 
              author: { name, email }, 
              featured: { publicURL }, 
              featuredAlt
            },
            excerpt, 
            html
          } 
        } = edge;
        return Object.assign({}, edge.node.frontmatter, {
          language: `en-us`,
          title,
          description: excerpt,
          date,
          url: siteUrl + path,
          guid: siteUrl + path,
          author: `${email} ( ${name} )`,
          image: {
            url: siteUrl + publicURL,
            title: featuredAlt,
            link: siteUrl + path,
          },
          custom_elements: [{ "content:encoded": html }],
        })
      })
    },
    // query to get blog post data 
    query: ` 
      { 
        allMarkdownRemark(  
          sort: { order: DESC, fields: [frontmatter___date] }, 
        ) { 
          edges { 
            node { 
              excerpt 
              html 
              frontmatter { 
                path 
                date 
                title 
                featured { publicURL } 
                featuredAlt 
                author { 
                  name 
                  email 
                } 
              } 
            } 
          } 
        } 
      } 
    `, 
    output: "/rss.xml",
    title: `My Awesome Site | RSS Feed`,
  },
],
},
},

gatsby-plugin-robots-txt

With robots.txt files, you can instruct crawlers to ignore your site and/or individual paths, based on certain conditions. See the plugin description for more detailed use cases.
```
{
resolve: 'gatsby-plugin-robots-txt',
options: {
policy: [{ userAgent: '*', allow: '/' }] 
}
},
```
gatsby-plugin-google-analytics

Google analytics will help you track how users find and interact with your site, so you can manage and update your site over time for better SEO results. Verify your site with Google and store your analytics key here:
```
{
resolve: `gatsby-plugin-google-analytics`,
options: {
trackingId: ``, 
},
},
```

Optimizing the SEO Component

The secret sauce behind the SEO Component is the well-known react-hemlet package. Every page and every template imports the SEO Component and thus you can pass specific information to adjust the metadata for each public facing page.

Use your imagination—what can you pass to this component to create the perfect SEO enabled page? Is the page a landing page, a blog post, a media gallery, a video, a professional profile, a product? There are 614 types of schemas listed on https://schema.org. You can pass specific schema related information to the SEO component.

If any of these values you pass to the component, a StaticQuery would fill in what’s missing with siteMetaData. From this data, react-helmet creates all the <meta> tags, including open graph and twitter card tags, and pass relevant data to another component that returns Google Structured Data.

Rather than including a long code-snippet, refer back to the Before We Begin section, or refer to the gatsby-plugin-react-helment page for installation. But please note, the structure of my SEO Component follows that outlined by this excellent post by Dustin Schau.

As I have tinkered with the SEO Component, here are the features I added:

Additional Fields Passed to Component to: distinguish between types of pages, such as blog posts, to handle authors of content other than main site author, and to handle changes in date modified for pages and posts. More could be added in the future.

function SEO({
  description,
  lang,
  meta,
  keywords,
  image,
  title,
  pathname,
  isBlogPost,
  author,
  datePublished = false,
  dateModified = false
}) {

Setting og:type conditionally

{
  property: `og:type`,
  content: isBlogPost ? `article` : `website`,
},

Always setting an alt property on the image object

// ALWAYS ADD IMAGE:ALT 
{ property: "og:image:alt", content: image.alt }, 
{ property: "twitter:image:alt", content: image.alt },

Handling Secure Images

.concat(
  // handle Secure Image 
  metaImage && metaImage.indexOf("https") > -1 
    ? [
        { property: "twitter:image:secure_url", content: metaImage, }, 
        { property: "og:image:secure_url", content: metaImage },
    ] 
    : [] 
)

Adding a Component to handle Google Structured Data using schema.org categories. I came across an example of such a component from reading through various documentation and articles, I can’t recall where I saw the link first, but I borrowed and adapted from Jason Lengstorf. I made two small adaptations to his excellent work.

Configuring the SchemaOrg Component

You will import and call the SchemaOrg Component from within the SEO Component and place it just after the closing tag of the Helmet Component and pass the following properties:

function SEO(.....) {
  ...
  return (
    <> {/* Fragment Shorthand */}
      <Helmet 
        {/* All the Meta Tag Configuration */}
      />
      <SchemaOrg 
        isBlogPost={isBlogPost} 
        url={metaUrl} 
        title={title} 
        image={metaImage} 
        description={metaDescription} 
        datePublished={datePublished} 
        dateModified={dateModified} 
        canonicalUrl={siteUrl} 
        author={isBlogPost ? author : siteMetadata.author} 
        organization={organization} 
        defaultTitle={title} 
      />   
    </>
  )
}

I won’t copy and paste the entire SchemaOrg Component here. Grab it from the link above, and give Jason Lengstorf some credit in your code. Below are the few additions I made:

I added author email to the Schema. This will come from siteMetadata for most pages and from post frontmatter from blog posts. This will support multiple authors for your site and each page can reflect that uniquely if you so choose.

author: {
  "@type": "Person",
  name: author.name,
  email: author.email, 
},

I updated the organization logo from a simple URI to an ImageObject type. While the String URI is acceptable to the Organization type, Google has specific expectations and was throwing an error until I changed it to an ImageObject.

publisher: {
  "@type": "Organization",
  url: organization.url,
  logo: { 
    "@type": "ImageObject", 
    url: organization.logo.url, 
    width: organization.logo.width, 
    height: organization.logo.height
  }, 
  name: organization.name,
},

Add dataModified to reflect changes to the page after initial publication for the BlogPosting type.

datePublished,
dateModified,

When you have more complexity within you site, you can pass flags to this Component to return differing types of schema as needed. But no matter what you do, do not put your site into production without first passing through the script generated by the component to the Google Structured Data Testing Tool.

Concluding Thoughts

When I configured my site according to the plan I outlined above, not only do I get image rich, descriptive Social Sharing cards, I get perfect SEO scores when running a Lighthouse Audit on my site:

You also see that I scored 100% for Accessibility on my site. This is so easy to score with Gatsby as well, and I’ll talk about what I learned on this topic in the future.

Originally Posted on my blog at https://www.wesleylhandy.net/blog/seo-accessibility-first-gatsby.html

DEV Community: Wesley Handy

New Tools, New Friends: Reflecting on JAMStackConf_SF 2019

The Future of the JAMStack is Dependent on Solutions That Are Being Developed and Those That Are Launching

There is a Growing History of High Volume Campaigns for Major Firms Being Run On the JAMStack

Netlify Function, Serverless Functions, etc., are a necessary tool to master to take full advantage of the JAMStack.

Is there a traffic JAM ahead? While it seems there is a growing number of devs who love the JAMStack, I talked to very few who had the opportunity to work on it day-to-day in their current position or who thought it's unlikely they ever could at their current job.

That is some sweet tasting JAM

Servant Leadership Exemplified

Cleaning Up Wordpress: Lessons Learned in Website Security

Wordpress Security 101

Final Thoughts

Improving Touch Events upon an Infinite Scrolling Component

Solution: Debugging CSS ??

Solution: Debugging touchend Event Handler !!

click comes after touchend

Adding Infinite Scroll For Both Desktop and Mobile in Your Gatsby Project with React Hooks

Inifinite Scroll & React Hooks

Setting Up gatsby-node.js

Creating the Template that Will Include Infinite Scroll

React Hooks - useEffect and useState

Creating and Setting Internal State with useState

Creating Event Handlers to Read and Set State

Checking The Scroll Position on Each Render with useEffect

Putting It All Together

Optimizing for Production and Touch Screens

Putting SEO First with Gatsby

Setting An SEO-First Mindset

Before We Begin

Setting up gatsby-config.js

Site Metadata

Plugin Setup

Optimizing the SEO Component

Configuring the SchemaOrg Component

Concluding Thoughts

Solution: Debugging `touchend` Event Handler !!

`click` comes after `touchend`

Setting Up `gatsby-node.js`

React Hooks - `useEffect` and `useState`

Creating and Setting Internal State with `useState`

Checking The Scroll Position on Each Render with `useEffect`

Setting up `gatsby-config.js`