One of my main mantras is using “Creative Coding” to level up your skills. It’s one of the main reasons I have gotten to where I am. But when so much of the web is very “set in its way”, it takes a little more for us to think “outside the box” and have fun!

See the Pen “Think” Outside The Box Toggle w/ CSS @property ✨ by Jhey.

It’s a muscle that you can train for sure. To have your ideas become more than ideas. To not get deterred by practicality.

Today, we’re going to do all those things. Let’s have some fun and think outside the box with a native HTML element. What if our sliders (<input type="range"/>) actually slid?

Today’s weapon of choice? GreenSock.

GreenSock has some of the best plugins and utilities that are perfect for our task. The idea for our whimsical slider is to respect physics — those being inertia and momentum. GreenSock has some awesome plugins for this. I’m thinking of the “Draggable” and “Inertia” plugins to start with.

For today, let’s make this a React component too. Let’s start by creating a component that renders the input for us:

import React from 'https://cdn.skypack.dev/react'
import ReactDOM from 'https://cdn.skypack.dev/react-dom'

const ROOT_NODE = document.querySelector('#app')

const SlideySlider = ({ min = 0, max = 100, step = 1, value = 0}) => {
  return (
    <input type="range" min={min} max={max} step={step} value={value} />
  )
}

const App = () => <SlideySlider value={gsap.utils.random(0, 100)}/>

ReactDOM.render(<App/>, ROOT_NODE)

See the Pen 1. Rendering our Slider Component by Jhey.

We have a component that accepts props for the standard “range” attributes. But we can’t update the value. We aren’t updating that value anywhere. Keeping the input uncontrolled for this demo makes sense. We could keep the value in the state of the parent component. And any changes we make, we can send back up to the parent. Let’s change it so that the value we pass gets used as the defaultValue:

const SlideySlider = ({ min = 0, max = 100, step = 1, value = 0}) => {
  return (
    <input type="range" min={min} max={max} step={step} defaultValue={value} />
  )
}

See the Pen 1.b. Changing to Uncontrolled by Jhey.

Now we can change the input value, but its value isn’t getting tracked anywhere. We’ll come back to syncing the value up later on.

Now let’s bring in Draggable to get things progressing. Any setup code, etc. we run inside an effect with React.useEffect. Now you might think to make our Draggable, we reach straight for this:

const SlideySlider = ({
  min = 0,
  max = 100,
  step = 1,
  value = 0
}) => {

  React.useEffect(() => {
    Draggable.create('input', {
      type: 'x',
    })
  }, []);

  return (
    <input
      type="range"
      min={min}
      max={max}
      step={step}
      defaultValue={value}
    />
  );
};

But that would make the input itself Draggable. Which makes for an interesting user experience!

See the Pen 2. Adding Draggable 😮 by Jhey.

Instead, we could use a little trick I picked up when making this demo for a Tuggable Light Bulb:

See the Pen Tuggable Light Bulb! 💡(GSAP Draggable && MorphSVG) by Jhey.

The idea is that we can create a proxy element for our Draggable. That gets “fake dragged” when we interact with our input because of the trigger property. The trigger property tells us to initiate dragging when interacting with our input. Note how we are also limiting the drag to the x-axis with the type property:

const SlideySlider = ({
  min = 0,
  max = 100,
  step = 1,
  value = 0
}) => {
  const proxy = React.useRef(document.createElement('div'))
  const inputRef = React.useRef(null)

  React.useEffect(() => {
    Draggable.create(proxy.current, {
      trigger: inputRef.current,
      type: 'x',
    })
  }, []);

  return (
    <input
      ref={inputRef}
      type="range"
      min={min}
      max={max}
      step={step}
      defaultValue={value}
    />
  );
};

See the Pen 3. Attaching Draggable via Proxy by Jhey.

Now we have Draggable in place, it’s time to make use of the Inertia plugin. This will allow us to track the velocity of our dragging. With that velocity, we can animate the value of our input based on the momentum of our sliding:

React.useEffect(() => {
  const PROXY_PROPS = gsap.getProperty(proxy.current)
  const TRACKER = InertiaPlugin.track(proxy.current, 'x')[0]

  const slide = () => {
    gsap.to(inputRef.current, {
      inertia: {
        value: TRACKER.get('x'),
      },
    })
  }

  Draggable.create(proxy.current, {
    trigger: inputRef.current,
    type: 'x',
    onPress: () => {
      gsap.killTweensOf(inputRef.current)
    },
    onDragEnd: slide,
  })
}, []);

With this solution we need to ensure we kill any tweens on the input onPress. That way we don’t interrupt or block the user from interacting with the input:

onPress: () => {
  gsap.killTweensOf(inputRef.current)
},

Once we’ve made those updates, we have the foundations of our SlideySlider!

See the Pen 4. A Basic Slide ✨ by Jhey.

It’s very slidey! A little too slidey. But we can revisit the friction, as we go. At this stage, we’ve also added a label for the input, and we are “controlling” the input value in the parent component:

const App = () => {
  const [value, setValue] = React.useState(gsap.utils.random(0, 100, 1))  
  return (
    <>
      <label htmlFor="slidey">{value}</label>
      <SlideySlider value={value} id="slidey" />
    </>
  )
}

We aren’t done there. If you throw a ball against a wall, does it hit the wall and stop? No! So, why should the thumb for our input?

The trick is to check the input value on an update, as we animate. We know the min and max values for our input. If the value hits one of them, we know that we are going to bounce in the opposite direction:

const checkForBounce = () => {
  let vx = TRACKER.get('x')
  const current = parseInt(inputRef.current.value, 10)

  if (Math.abs(vx) !== 0 && (current === max || current === min)) {
    vx *= FRICTION
    slide(vx)
  }
}

const slide = vx => {
  let value = vx !== undefined ? vx : TRACKER.get('x')
  gsap.to(inputRef.current, {
    overwrite: true,
    inertia: {
      value,
      resistance: 200,
    },
    onUpdate: checkForBounce,
  })
}

But that doesn’t work! It starts to work.

See the Pen 5. Handling the "Bounce" by Jhey.

Though after one bounce, it gives up. This confused me at first, because of this demo from the GSAP docs. Throw that ball around.

See the Pen 5. Handling the "Bounce" by Jhey.

See the Pen Draggable Bounce by Blake Bowen.

What about wrapping the input with a div? And then using another element as a proxy handle? If we try using a “fake” proxy handle, it “can” work. It’s also an easy way to increase the thumb size. But now we’re trying to sync the input value to the thumb which isn’t ideal. It kinda puts the control in the opposite direction.

See the Pen 6. Using Proxy Drag Handle by Jhey.

Notice how the “Handle” doesn’t stay centered on the input thumb. Also, if you were to click the track and start dragging, we wouldn’t get our slide. This is because we would have to tell our handle to start dragging with “startDrag)”. But it would work! 🙌

So, why didn’t it work without the proxy handle then? Well, it’s a case of things being a little too quick for our scenario.

“The main problem was that inertia tracking by its very nature is time-dependent, meaning it sorta keeps track of a certain amount of history so that it can do the calculations. You were creating a scenario where you inverted the velocity via a tween, but it took a little time for that to actually get reflected in the tracked velocity (as it should). So, let’s say it’s moving super fast in one direction, so maybe 3000px/s and then you suddenly start moving it in the opposite direction at half the speed, but it’s taking data points once every tick and must average them out — if it hits the other limit quickly enough, it’ll still have some historical data from when it was going 3000px/s that offsets things. So in your case, that’d result in it still being a positive velocity and you were multiplying it by a negative, thus heading in the same direction as before.”

— Jack @ GreenSock

Jack did suggest another way to implement things by using another GSAP utility wrapYoyo). This does give us the effect we are after. It also reduces the code significantly. But it lacks a couple of features that I’d like for other ideas I had for our slider.

See the Pen Jack’s Solution ✨ by Jhey.

Those being how to detect when we hit a side? And also we don’t want any velocity when we click the track away from the thumb. If you click the track further away from the thumb in that demo, you’ll get distance-based velocity.

So, what do we do? Well, the timing couldn’t have been better. With the latest version of GSAP (3.10 at the time of writing), a new plugin is now available. The “Observer” plugin allows developers to tap into interaction events. And the callback system means you can grab things like the velocity on a certain axis. This is perfect for what we are trying to do.

I was fortunate to get early access to this plugin. But I hadn’t considered this use case until Jack mentioned it. I did make a spinny globe with React and ThreeJS — let me know if you want an article about how to do that! 🙌

See the Pen Spinning Globe 🌎 w/ GSAP ScrollTrigger.Observe by Jhey.

Let’s start again with our SlideySlider component.

See the Pen 7. Starting Over by Jhey.

const SlideySlider = ({
  id,
  min = 0,
  max = 100,
  step = 1,
  value = 0,
}) => {

  const inputRef = React.useRef(null)

  React.useEffect(() => {

  }, []);

  return (
    <input
      id={id}
      ref={inputRef}
      type="range"
      min={min}
      max={max}
      step={step}
      defaultValue={value}
    />
  );
};

This time we aren’t going to use Draggable and track the invisible proxy. Instead, we will track the value of the input with the InertiaPlugin. And then we can use the new Observer plugin to catch the “drag”.

Let’s start with that tracking within an effect:

React.useEffect(() => {
  InertiaPlugin.track(inputRef.current, "value");
}, []);

Here we are tracking the value on the input. And this means we can tween the value of the input with a value of auto where the plugin will calculate it for us. See the docs for more) on this.

Here comes the important bit — setting up the Observer:

React.useEffect(() => {
  InertiaPlugin.track(inputRef.current, "value");

  Observer.create({
    target: inputRef.current,
    type: "touch,pointer",
    dragMinimum: 3,
    onPress: () => tweenRef.current && tweenRef.current.kill(),
    onDragEnd: () => {
      tweenRef.current = gsap.to(inputRef.current, {
        inertia: {
          resistance: 200,
          value: "auto"
        }
      });
    }
  });
}, []);

We are telling the Observer to watch any touch or pointer events on the input. If we drag at least 3 pixels, this gets considered a drag. We keep a reference to the sliding tween so that we can destroy it whenever we interact with the input. This means we can click the track anywhere, and there will be no inertia or velocity to deal with. Once we’ve finished dragging, we can tween the value of the input based on the velocity at which we dragged. This is great!

See the Pen 8. Basic Observer Integration 🙌 by Jhey.

All we need now is that bounce! How can we animate the bounce instead of it stopping dead? And also, how do we detect when there is a bounce?

This is where that wrapYoyo utility we mentioned earlier comes into play. Given two parameters (or an Array of values)), we create a wrapping function that can calculate a value for us. In our case, this is the min and max for our input element:

const WRAP = gsap.utils.wrapYoyo(min, max)

How do we use this? Well, we can make use of the “Modifiers” plugin. This allows us to intercept values that GSAP is going to use and run our own custom logic before returning a value. Let’s get the bounce working first. Using a modifier, we can wrap the auto defined value for our input:

const WRAP = gsap.utils.wrapYoyo(min, max)
Observer.create({
  target: inputRef.current,
  type: "touch,pointer",
  dragMinimum: 3,
  onPress: () => tweenRef.current && tweenRef.current.kill(),
  onDragEnd: () => {
    tweenRef.current = gsap.to(inputRef.current, {
      inertia: {
        resistance: 200,
        value: "auto"
      },
      modifiers: {
        value: v => WRAP(v)
      }
    });
  }
});

It’s as easy as that! Boom!

See the Pen 9. Animating the Bounce! by Jhey.

Now to detect a collision. There’s a nifty little way to do this. At the end of each drag, we can detect the number of bounces by dividing the inertia value by the max value. Then if the number changes, we know we’ve had a bounce! We can also tap into the Inertia tracking to get the current value and work out which side is being bounced.

Update our track to instantiate a variable. Note how we are setting, as the first value of the Array returned:

const TRACKER = InertiaPlugin.track(inputRef.current, "value")[0];

Then update our onDragEnd as follows:

onDragEnd: () => {
  let lastCycle = 0;
  tweenRef.current = gsap.to(inputRef.current, {
    inertia: {
      resistance: 200,
      value: "auto"
    },
    modifiers: {
      value: (v) => {
        const cycle = Math.floor(v / max);
        if (cycle !== lastCycle) {
          // Bounce!!!
          console.info(BOUNCE ${TRACKER.get('value') < 0 ? 'LEFT' : 'RIGHT'});
        }
        // Update the cycle count
        lastCycle = cycle;
        return WRAP(v);
      }
    }
  });
}

Now we can start doing some more fun things with it!

How about if we bumped the sides a little based on the velocity? Well, as we can detect which side is getting knocked, we can also tween the input itself. Let’s update our modifiers code:

modifiers: {
  value: (v) => {
    const cycle = Math.floor(v / max);

    if (cycle !== lastCycle) {
      // Bounce!!!
      const vx = TRACKER.get("value");
      const xPercent = gsap.utils.clamp(
        -bump,
        bump,
        gsap.utils.mapRange(-600, 600, -bump, bump, vx)
      );
      gsap.to(inputRef.current, {
        xPercent,
        yoyo: true,
        repeat: 1
      });
    }
    // Update the cycle count
    lastCycle = cycle;
    return WRAP(v);
  }
}

The idea is that if we bounce, we can calculate an xPercent to animate our input by. To do that, we can use another GSAP utility — mapRange. Given some velocity, map an input range to an output range. And we can clamp the value with gsap.utils.clamp. For our xPercent value, we are clamping a bump value (set to 10 in the component props). Then we are mapping the input range -600 to 600 against -10 to 10. We pass the current velocity (vx) into that and clamp the result. The number 600 could also be configured via the component props if we wish:

const xPercent = gsap.utils.clamp(
  -bump,
  bump,
  gsap.utils.mapRange(-600, 600, -bump, bump, vx)
);

Translating alone won’t look great. There are some extra things we can do to make this “feel” better. We could make the duration of that animation be dependent on the velocity too. Again, these numbers could be configured via props:

const duration = gsap.utils.clamp(
  0.05,
  0.2,
  gsap.utils.mapRange(0, 600, 0.2, 0.05, Math.abs(vx))
);

And how about if we play a knocking noise at the start of the animation? We could set the volume based on the velocity:

const volume = gsap.utils.clamp(
  0.1,
  1,
  gsap.utils.mapRange(0, 600, 0, 1, Math.abs(vx))
)

These values are then used to animate the input element. Notice how we use yoyo with repeat: 1 to return the input to its original position. We also reset the audio and play it on each onStart:

gsap.to(inputRef.current, {
  onStart: () => {
    KNOCK.pause()
    KNOCK.currentTime = 0
    KNOCK.volume = volume
    KNOCK.play()
  },
  xPercent,
  duration,
  yoyo: true,
  repeat: 1
});

Awesome!

See the Pen 11. Add Some Whimsy! ✨ by Jhey.

Now we’ve got a little whimsy in, let’s get practical. We need the value to be in sync with whatever React state we have in place. It’d be neat to keep a label value in sync too. We can do that!

Let’s start by updating the parent component:

const App = () => {
  const labelRef = React.useRef(null)
  const [value, setValue] = React.useState(gsap.utils.random(0, 100, 1));

  return (
    <>
      <label htmlFor="slidey" ref={labelRef}>{value}</label>
      <SlideySlider
        id="slidey"
        value={value}
        labelRef={labelRef}
        onChange={setValue}
      />
      <span>{`State value: ${value}`}</span>
    </>
  );
};

We’re controlling the input value in this App component. We are also going to pass a labelRef and an onChange prop to our SlideySlider. The first prop gives our slider access to the label element. The second provides a way for our SlideySlider to communicate value changes. We also have a span in place to show you when the state is getting updated.

The key is using an onChange handler like we usually would. But we also need to invoke that onChange handler at the end of our sliding tween.

Here’s the updated render using the onChange prop:

return (
  <input
    id={id}
    ref={inputRef}
    onChange={e => onChange(e.target.value)}
    type="range"
    min={min}
    max={max}
    step={step}
    defaultValue={value}
  />
);

And we can add an onComplete inside our onDragEnd tween:

onDragEnd: () => {
  let lastCycle = 0;
  tweenRef.current = gsap.to(inputRef.current, {
    inertia: {
      resistance: 200,
      value: "auto"
    },
    onComplete: () => {
      if (onChange) onChange(inputRef.current.value)
    },
    /* Rest of tween */
  }
  /* Rest of onDragEnd */
}

The last piece is to set the visual value of the label as we animate. Inside our value modifier we can use gsap.set if we have a labelRef to use:

if (labelRef.current) gsap.set(labelRef.current, { innerText: Math.floor(WRAP(v)) })

And now we are keeping everything in sync!

See the Pen 12. Syncing Values by Jhey.

And that’s it! What if our sliders actually slid? Well, I guess we have an idea now! What else could we do with this? What other input controls could have “interesting” behavior?

See the Pen What if Sliders actually slid? ✨ (GSAP Observer) by Jhey.

We can do so much with the code, and the web platform is always evolving. The only limit is our imagination, not the tech stack we bring it to life with. But collaboration is the key. Hop in some forums, ask some questions, have fun! And most importantly, stay awesome! ʕ •ᴥ•ʔ

Further Reading And Resources

• The Whimsical Web
  A curated list of sites with an extra bit of fun.
• “In Defense Of A Fussy Website,” Sarah Drasner, CSS-Tricks
• “Playfulness In Code: Supercharge Your Learning By Having Fun,” Jhey Tompkins, Smashing Magazine

I’ve been working with React since ~v0.12 was released. (2014! Wow, where did the time go?) It’s changed a lot. I recall certain “Aha” moments along the way. One thing that’s remained is the mindset for using it. We think about things in a different way as opposed to working with the DOM direct.

For me, my learning style is to get something up and running as fast as I can. Then I explore deeper areas of the docs and everything included whenever necessary. Learn by doing, having fun, and pushing things!

Aim

The aim here is to show you enough React to cover some of those "Aha" moments. Leaving you curious enough to dig into things yourself and create your own apps. I recommend checking out the docs for anything you want to dig into. I won’t be duplicating them.

Please note that you can find all examples in CodePen, but you can also jump to my Github repo for a fully working game.

First App

You can bootstrap a React app in various ways. Below is an example:

import React from 'https://cdn.skypack.dev/react'
import { render } from 'https://cdn.skypack.dev/react-dom'

const App = () => <h1>{`Time: ${Date.now()}`}</h1>

render(<App/>, document.getElementById('app')

Starting Point

We’ve learned how to make a component and we can roughly gauge what we need.

import React, { Fragment } from 'https://cdn.skypack.dev/react'
import { render } from 'https://cdn.skypack.dev/react-dom'

const Moles = ({ children }) => <div>{children}</div>
const Mole = () => <button>Mole</button>
const Timer = () => <div>Time: 00:00</div>
const Score = () => <div>Score: 0</div>

const Game = () => (
  <Fragment>
    <h1>Whac-A-Mole</h1>
    <button>Start/Stop</button>
    <Score/>
    <Timer/>
    <Moles>
      <Mole/>
      <Mole/>
      <Mole/>
      <Mole/>
      <Mole/>
    </Moles>
  </Fragment>
)

render(<Game/>, document.getElementById('app'))

Starting/Stopping

Before we do anything, we need to be able to start and stop the game. Starting the game will trigger elements like the timer and moles to come to life. This is where we can introduce conditional rendering.

const Game = () => {
  const [playing, setPlaying] = useState(false)
  return (
    <Fragment>
      {!playing && <h1>Whac-A-Mole</h1>}
      <button onClick={() => setPlaying(!playing)}>
        {playing ? 'Stop' : 'Start'}
      </button>
      {playing && (
        <Fragment>
          <Score />
          <Timer />
          <Moles>
            <Mole />
            <Mole />
            <Mole />
            <Mole />
            <Mole />
          </Moles>
        </Fragment>
      )}
    </Fragment>
  )
}

We have a state variable of playing and we use that to render elements that we need. In JSX, we can use a condition with && to render something if the condition is true. Here we say to render the board and its content if we are playing. This also affects the button text where we can use a ternary.

Open the demo at this link and set the extension to highlight renders. Next, you’ll see that the timer renders as time changes, but when we whack a mole, all components re-render.

Loops in JSX

You might be thinking that the way we’re rendering our Moles is inefficient. And you’d be right to think that! There’s an opportunity for us here to render these in a loop.

With JSX, we tend to use Array.map 99% of the time to render a collection of things. For example:

const USERS = [
  { id: 1, name: 'Sally' },
  { id: 2, name: 'Jack' },
]
const App = () => (
  <ul>
    {USERS.map(({ id, name }) => <li key={id}>{name}</li>)}
  </ul>
)

The alternative would be to generate the content in a for loop and then render the return from a function.

return (
  <ul>{getLoopContent(DATA)}</ul>
)

What’s that key attribute for? That helps React determine what changes need to render. If you can use a unique identifier, then do so! As a last resort, use the index of the item in a collection. (Read the docs on lists for more.)

For our example, we don’t have any data to work with. If you need to generate a collection of things, then here’s a trick you can use:

new Array(NUMBER_OF_THINGS).fill().map()

This could work for you in some scenarios.

return (
  <Fragment>
    <h1>Whac-A-Mole</h1>
    <button onClick={() => setPlaying(!playing)}>{playing ? 'Stop' : 'Start'}</button>
    {playing &&
      <Board>
        <Score value={score} />
        <Timer time={TIME_LIMIT} onEnd={() => console.info('Ended')}/>
        {new Array(5).fill().map((_, id) => 
          <Mole key={id} onWhack={onWhack} />
        )}
      </Board>
    }
  </Fragment>
)

Or, if you want a persistent collection, you could use something like uuid:

import { v4 as uuid } from 'https://cdn.skypack.dev/uuid'
const MOLE_COLLECTION = new Array(5).fill().map(() => uuid())

// In our JSX
{MOLE_COLLECTION.map((id) => 
  
)}

Ending Game

We can only end our game with the Start button. When we do end it, the score remains when we start again. The onEnd for our Timer also does nothing yet.

We’re going to bring in a third-party solution to make our moles bob up and down. This is an example of how to bring in third-party solutions that work with the DOM. In most cases, we use refs to grab DOM elements, and then we use our solution within an effect.

We’re going to use GreenSock(GSAP) to make our moles bob. We won’t dig into the GSAP APIs today, but if you have any questions about what they’re doing, please ask me!

Here’s an updated Mole with GSAP:

import gsap from 'https://cdn.skypack.dev/gsap'

const Mole = ({ onWhack }) => {
  const buttonRef = useRef(null)
  useEffect(() => {
    gsap.set(buttonRef.current, { yPercent: 100 })
    gsap.to(buttonRef.current, {
      yPercent: 0,
      yoyo: true,
      repeat: -1,
    })
  }, [])
  return (
    <div className="mole-hole">
      <button
        className="mole"
        ref={buttonRef}
        onClick={() => onWhack(MOLE_SCORE)}>
        Mole
      </button>
    </div>
  )
}

We’ve added a wrapper to the button which allows us to show/hide the Mole, and we’ve also given our button a ref. Using an effect, we can create a tween (GSAP animation) that moves the button up and down.

You’ll also notice that we’re using className which is the attribute equal to class in JSX to apply class names. Why don’t we use the className with GSAP? Because if we have many elements with that className, our effect will try to use them all. This is why useRef is a great choice to stick with.

See the Pen 8. Moving Moles by @jh3y.

Awesome, now we have bobbing Moles, and our game is complete from a functional sense. They all move exactly the same which isn’t ideal. They should operate at different speeds. The points scored should also reduce the longer it takes for a Mole to get whacked.

Our Mole’s internal logic can deal with how scoring and speeds get updated. Passing the initial speed, delay, and points in as props will make for a more flexible component.

<Mole key={index} onWhack={onWhack} points={MOLE_SCORE} delay={0} speed={2} />

Now, for a breakdown of our Mole logic.

Let’s start with how our points will reduce over time. This could be a good candidate for a ref. We have something that doesn’t affect render whose value could get lost in a closure. We create our animation in an effect and it’s never recreated. On each repeat of our animation, we want to decrease the points value by a multiplier. The points value can have a minimum value defined by a pointsMin prop.

const bobRef = useRef(null)
const pointsRef = useRef(points)

useEffect(() => {
  bobRef.current = gsap.to(buttonRef.current, {
    yPercent: -100,
    duration: speed,
    yoyo: true,
    repeat: -1,
    delay: delay,
    repeatDelay: delay,
    onRepeat: () => {
      pointsRef.current = Math.floor(
        Math.max(pointsRef.current * POINTS_MULTIPLIER, pointsMin)
      )
    },
  })
  return () => {
    bobRef.current.kill()
  }
}, [delay, pointsMin, speed])

We’re also creating a ref to keep a reference for our GSAP animation. We will use this when the Mole gets whacked. Note how we also return a function that kills the animation on unmount. If we don’t kill the animation on unmount, the repeat code will keep firing.

See the Pen 9. Score Reduction by @jh3y.

What will happen when a mole gets whacked? We need a new state for that.

const [whacked, setWhacked] = useState(false)

And instead of using the onWhack prop in the onClick of our button, we can create a new function whack. This will set whacked to true and call onWhack with the current pointsRef value.

const whack = () => {
 setWhacked(true)
 onWhack(pointsRef.current)
}

return (
 <div className="mole-hole">
    <button className="mole" ref={buttonRef} onClick={whack}>
      Mole
    </button>
  </div>
)

The last thing to do is respond to the whacked state in an effect with useEffect. Using the dependency array, we can make sure we only run the effect when whacked changes. If whacked is true, we reset the points, pause the animation, and animate the Mole underground. Once underground, we wait for a random delay before restarting the animation. The animation will start speedier using timescale and we set whacked back to false.

useEffect(() => {
  if (whacked) {
    pointsRef.current = points
    bobRef.current.pause()
    gsap.to(buttonRef.current, {
      yPercent: 100,
      duration: 0.1,
      onComplete: () => {
        gsap.delayedCall(gsap.utils.random(1, 3), () => {
          setWhacked(false)
          bobRef.current
            .restart()
            .timeScale(bobRef.current.timeScale() * TIME_MULTIPLIER)
        })
      },
    })
  }
}, [whacked])

That gives us:

See the Pen 10. React to Whacks by @jh3y.

The last thing to do is pass props to our Mole instances that will make them behave differently. But, how we generate these props could cause an issue.

<div className="moles">
  {new Array(MOLES).fill().map((_, id) => (
    <Mole
      key={id}
      onWhack={onWhack}
      speed={gsap.utils.random(0.5, 1)}
      delay={gsap.utils.random(0.5, 4)}
      points={MOLE_SCORE}
    />
  ))}
</div>

This would cause an issue because the props would change on every render as we generate the moles. A better solution could be to generate a new Mole array each time we start the game and iterate over that. This way, we can keep the game random without causing issues.

const generateMoles = () => new Array(MOLES).fill().map(() => ({
  speed: gsap.utils.random(0.5, 1),
  delay: gsap.utils.random(0.5, 4),
  points: MOLE_SCORE
}))
// Create state for moles
const [moles, setMoles] = useState(generateMoles())
// Update moles on game start
const startGame = () => {
  setScore(0)
  setMoles(generateMoles())
  setPlaying(true)
  setFinished(false)
}
// Destructure mole objects as props
<div className="moles">
  {moles.map(({speed, delay, points}, id) => (
    <Mole
      key={id}
      onWhack={onWhack}
      speed={speed}
      delay={delay}
      points={points}
    />
  ))}
</div>

And here’s the result! I’ve gone ahead and added some styling along with a few varieties of moles for our buttons.

See the Pen 11. Functioning Whac-a-Mole by @jh3y.

We now have a fully working “Whac-a-Mole” game built in React. It took us less than 200 lines of code. At this stage, you can take it away and make it your own. Style it how you like, add new features, and so on. Or you can stick around and we can put together some extras!

Tracking The Highest Score

We have a working "Whac-A-Mole", but how can we keep track of our highest achieved score? We could use an effect to write our score to localStorage every time the game ends. But, what if persisting things was a common need. We could create a custom hook called usePersistentState. This could be a wrapper around useState that reads/writes to localStorage.

  const usePersistentState = (key, initialValue) => {
  const [state, setState] = useState(
    window.localStorage.getItem(key)
      ? JSON.parse(window.localStorage.getItem(key))
      : initialValue
  )
  useEffect(() => {
    window.localStorage.setItem(key, state)
  }, [key, state])
  return [state, setState]
}

And then we can use that in our game:

const [highScore, setHighScore] = usePersistentState('whac-high-score', 0)

We use it exactly the same as useState. And we can hook into onWhack to set a new high score during the game when appropriate:

const endGame = points => {
  if (score > highScore) setHighScore(score) // play fanfare!
}

How might we be able to tell if our game result is a new high score? Another piece of state? Most likely.

See the Pen 12. Tracking High Score by @jh3y.

Whimsical Touches

At this stage, we’ve covered everything we need to. Even how to make your own custom hook. Feel free to go off and make this your own.

Sticking around? Let’s create another custom hook for adding audio to our game:

const useAudio = (src, volume = 1) => {
  const [audio, setAudio] = useState(null)
  useEffect(() => {
    const AUDIO = new Audio(src)
    AUDIO.volume = volume
    setAudio(AUDIO)
  }, [src])
  return {
    play: () => audio.play(),
    pause: () => audio.pause(),
    stop: () => {
      audio.pause()
      audio.currentTime = 0
    },
  }
}

This is a rudimentary hook implementation for playing audio. We provide an audio src and then we get back the API to play it. We can add noise when we “whac” a mole. Then the decision will be, is this part of Mole? Is it something we pass to Mole? Is it something we invoke in onWhack ?

These are the types of decisions that come up in component-driven development. We need to keep portability in mind. Also, what would happen if we wanted to mute the audio? How could we globally do that? It might make more sense as a first approach to control the audio within the Game component:

// Inside Game
const { play: playAudio } = useAudio('/audio/some-audio.mp3')
const onWhack = () => {
  playAudio()
  setScore(score + points)
}

It’s all about design and decisions. If we bring in lots of audio, renaming the play variable could get tedious. Returning an Array from our hook-like useState would allow us to name the variable whatever we want. But, it also might be hard to remember which index of the Array accounts for which API method.

See the Pen 13. Squeaky Moles by @jh3y.

That’s It!

More than enough to get you started on your React journey, and we got to make something interesting. We sure did cover a lot:

• Creating an app,
• JSX,
• Components and props,
• Creating timers,
• Using refs,
• Creating custom hooks.

We made a game! And now you can use your new skills to add new features or make it your own.

Where did I take it? At the time of writing, it’s at this stage so far:

See the Pen Whac-a-Mole w/ React && GSAP by @jh3y.

Where To Go Next!

I hope building “Whac-a-Mole” has motivated you to start your React journey. Where next? Well, here are some links to resources to check out if you’re looking to dig in more — some of which are ones I found useful along the way.

• React Documentation
• “Making setInterval Declarative With React Hooks,” Dan Abramov
• “How To Fetch Data With React Hooks,” Robin Wieruch
• “When To useMemo And useCallback,” Kent C Dodds
• Read more React articles right here on Smashing Magazine