DEV Community: Rowan Merewood

Gemini CLI and Jules: my March 2026 stack

Rowan Merewood — Sun, 15 Mar 2026 17:28:43 +0000

Development workflow is a very personal thing. As the various AI and LLM coding tools evolve, I've been trying different things to see what fits with how I want to code. This is for my personal projects, so it's important to me that I'm actually enjoying myself - it's not necessarily about maximum efficiency. It's also about updating how I work. I'm allergic to rabid hype, so getting into tools has required resisting that eye-twitch while I read a breathless summary about how another Markdown file is going to change my life.

Also, I do find it a little bit intimidating when you see other people talking about how they've automated their entire workflow and have hordes of agents building a Mad Max MMORPG. So, I thought I'd share my more incremental progress in case it's encouraging for anyone else. I do oscillate between feeling that everything is changing so quickly that I've got no hope of getting started and then finding something that really does make my life easier and even a bit more delightful.

Full disclosure: these are mostly Google tools. I work there, I generally try to use our stuff. I even use the Linux VM inside ChromeOS as my primary development environment. Why? That's a great question.

However, I've found a current combination that hits the right notes for me. It takes care of tedious scaffolding, highlights edge cases I wouldn't have considered, and keeps the actual implementation legible. Here's the tl;dr of my stack:

automated tests and static analysis on pull requests
automated Firebase Hosting deploys on pull requests
Gemini CLI for active pair work
Jules for background suggestions

You can see all the code and configuration in the fractious GitHub repo.

The tl;dr of the tl;dr: make reviews easy. That means adding more of the infrastructure I'd expect on a mature team project versus personal hobby toys. Long-term, maybe I'll finally do Extreme Programming like it's the '90s again. Those ultra-wide jeans are back in again, so anything is possible.

Anyway, let's get into my (non-frosted) tips for my own environment.

Project: Fractious

If you follow me on any social media, you know I post a disproportionate number of screenshots from my Mandelbrot fractal explorer, Fractious. I need to write a proper blog post on the updates I've made, but the relevant bit here is that I'd "finished" the previous iteration but was frustrated by the limit to the zoom depth. Then Ingvar suggested looking at BigDecimal.js, which I promptly did not do, going straight to asking Gemini what I could do instead. From there we successfully migrated from an entirely WebGL shader-based implementation to doing the reference calculation in Wasm and rendering the output with WebGPU.

The sweet spot here was: I knew what I wanted, I knew what a good architecture looked like, but I didn't know the exact syntax or steps to get there.

Gemini CLI

I tend to have three terminal tabs open: one running the build/dev server, one for my own Git commands, and one for Gemini CLI. I then have a separate VS Code instance open where I'm either editing or checking diffs. This separation means I have my familiar coding setup for doing the exploratory stuff and then I switch over to Gemini when there's something I want it to do.

I've tried the VS Code integration, Antigravity, etc. and at least personally, and at the moment, it more often gets in my way than helps me. The AI jumping in all the time while I'm in the middle of typing tends to derail my train of thought rather than speed it up. This also means I tend towards longer periods in one mode or another. As in, I'm either doing things myself or I'm asking Gemini to work and then I'm reviewing. I don't really work in a mixed mode where the AI is collaborating alongside me.

The biggest part of that in Fractious was implementing the Rust-based Wasm module. I don't know Rust and I don't know the tooling ecosystem. However, with Gemini I could get something that worked bootstrapped pretty quickly. It's much easier for me to learn and expand on a working example versus starting from a blank canvas.

Static analysis

I also used Gemini to untangle the myriad of config files required for these tools. I maintain that YAML ain't a human-readable format (looking at you, GitHub Actions), but thankfully, it no longer has to be human-writable at least.

I integrated a few different tools here:

general linting with ESLint
complexity and other checks with the SonarJS plugin for ESLint
security checks with, unsurprisingly, eslint-plugin-security
dependency checks with Dependency cruiser

This pipeline catches dead code, unnecessarily nested if statements, and "cognitive complexity" (which I think is mostly cyclomatic complexity with a fuzzier name), along with a whole bunch more.

Again, this is all standard infrastructure for a work project accepting contributions. In this case, the contributor just happens to be a robot.

I also dropped in a basic unit test harness with vitest. Yes, I'm a bad developer—I should have written the tests first. Not very Extreme Programming of me. However, having the harness in place means I can incrementally drop in tests (or ask the agent to do it) one by one.

The crucial part is that these checks run on a GitHub Action against every pull request and push to main.

Preview builds

I'm using Firebase Hosting, which features a GitHub Actions integration to deploy to a preview channel on every PR. This is vital because it creates a workflow where I can review, test, and approve incoming changes directly from my phone.

This is nice because now it turns into an activity I can do wherever I am rather than needing to grab my laptop. The pull request comes in. The automatic checks and tests give me a base level of confidence in the contribution. I go play with the deployed app to make sure it works the way I expected. Then I peruse the diff to see if I agree with what's coming in. If I do, I just merge - if not then it waits until I'm at my laptop.

As a bonus, reviewing PRs on my phone has taken a meaningful bite out of my reflexive doomscrolling.

Jules

So, "where are these AI contributions coming from?" I hear my rare reader ask. Jules is a hosted agent that runs a bit more autonomously. It has a Suggestions feature and scheduled tasks that go through the codebase and look for issues, improvements, changes, etc. I go through these suggestions in the web interface and tell it to get started on the ones I'm interested in and then a bit later I get a pull request.

The provided scheduled agents are quite helpful, with templates for performance, security, and UI improvements. It's useful looking through the prompts provided to see what those aspects are. For example, the performance agent includes:

"identify and implement ONE small performance improvement"
"never sacrifice code readability for micro-optimizations"
"measure the impact, add benchmark comments"

So far this has resulted in pull requests that really are just changing one thing across 1-4 files. The performance ones often do come with a benchmark script showing the improvement. The UI improvement agent has been adding ARIA rules which do help with my unhealthy predilection for using emojis for labels and buttons.

There are still quirks to manage. I avoid triggering multiple suggestions that touch the same code simultaneously to dodge merge conflicts. Occasionally, an agent will persistently re-suggest a change I've already rejected, just formatted slightly differently. I've also watched the performance agent optimize a block of code, only for the security agent to swing by later and revert it to the old, more robust implementation.

Still, it's been pleasing getting a nice little list of improvements each morning. With the tests and preview deploys in place, there's very little effort or spin up time for me to get into looking at them. The scope of each change isn't overwhelming either - so I really can just pick up my phone and make a little progress.

Wrap it up

I don't know if this is the workflow I'll have next month. Things do change quite quickly and I'm also learning and adapting as I go. Right now, this pattern of having the agent as a local partner or remote contributor is working quite well for me. However, as I start resuscitating those Behavior-Driven Development (BDD) skills I can see myself getting more comfortable with a hands-off approach when I have enough confidence in the test suite. That said, I'm an inherent tinkerer. I like to know how the app is working under the hood and on personal projects, playing with the code is the entire point.

Modern noise

Rowan Merewood — Sun, 01 Jun 2025 12:21:02 +0000

This started as a simple noise machine with classic white, pink, and brown noise. However, at the time the first of April was coming up so I decided to add some additional noises that fit with the modern world. As with any worthwhile April Fool's joke, I ended up putting in far more effort than was really justified. However, I'm pretty happy with the end result and wanted to share a few of the build details.

⏯ Launch the Modern Noise generator!

The whole aesthetic is a shameless homage to the gorgeous Teenage Engineering K.O. II. Now, I've never even seen one in real life but I wasn't about to let that stop me having some kind of virtual approximation. Given its iconic look, the first step was assuming that other people had already recreated it... and they had.

Steal her look

Thomas McInnis created this realistic skeumorphic CSS calculator. I nabbed this as a base with the clean use of borders and box-shadows to get the button appearance.

Nicolas Jesenberger crafted this set of EP-133 K.O.II buttons where I like the actual use of a <button> element along with some subtle animations when the button is pressed. Bonus points here for using the actual Teenage Engineering font too!

I've combined elements from both for the noise machine. I also wasn't looking for subtle animations, so I've cranked those up to get a chunky, clunky button you can almost feel when you press the screen.

The volume slider is another story. I'll be honest, it probably has a whole bunch of issues in Safari and Firefox. Just look at all the footnotes for vertically-oriented range sliders on Can I use.... I might get around to fixing it if people complain.

LCD marquee

The <marquee> tag is a classic in its beautiful mess of presentation and content lumped together. However, I still wanted that effect on the LCD display. I also wanted the appearance of the unlit pixels behind the text. Both of these came together reasonably neatly with the ch unit.

I'm using the Doto font for the 5×9 mono grid font. Then I spent slightly longer than I should have creating a matching grid with SVG. Then I can just set that up as a character-sized background:

background-image: url("/img/lcd-text-background.svg");
  background-size: 1ch;
  background-origin: content-box;
  background-position: 0% 75%;
  background-repeat: repeat-x;

Then we animate the text from fully off the right side of the screen to fully off the left.

.lcd-text>span {
  animation: marquee 10s steps(20, end) infinite;
}

@keyframes marquee {
  0% {
    transform: translateX(10ch);
  }
  100% {
    transform: translateX(-10ch);
  }
}

The trick here is instead of a smooth animation we're setting it to go in 20 steps and the range of motion is 20 ch. So each each step is a full character.

It's not perfect, because it leaves an awkward gap where no text is on screen. I'm unsure if there's a CSS-only way of doing this or if I'd need to adjust the values based on the length of the content in the tag. I'll leave that as a TODO for now.

Bring the noise

Now on to the rabbit hole that is noise generation. Zach Denton wrote the informative How to Generate Noise with the Web Audio API which gave me the code for white, pink, and brown noise. White noise is simple, literally just random values in a buffer. Pink noise is white noise passed through a -3dB per octave low-pass filter. Now, the Web Audio API has BiquadFilterNode with a lowpass type - however this is -12dB per octave. Now, there's the even more low-level IIRFilterNode which states, "All even-ordered IIR filters can be created using BiquadFilterNode. However, if you need to create an odd-ordered IIR filter, you'll need to use IIRFilterNode." I naively assumed that creating a -3dB per octave filter would be as simple as passing in a different parameter.

After some time reading the IIR Filter slides from the Signal and Image Analysis module at the University of Illinois I realised that it was critical for me to identify the right poles and zeroes, but no matter how much I looked through those slides I have no idea what these terms really mean. It's possible that late-night coding doesn't always find me in the best frame of mind for learning new topics. Nonetheless, I feel relatively confident this is a Hard Problem. Hence the solution from Zach's blog:

for (var i = 0; i < bufferSize; i++) {
    var white = Math.random() * 2 - 1;
    b0 = 0.99886 * b0 + white * 0.0555179;
    b1 = 0.99332 * b1 + white * 0.0750759;
    b2 = 0.96900 * b2 + white * 0.1538520;
    b3 = 0.86650 * b3 + white * 0.3104856;
    b4 = 0.55000 * b4 + white * 0.5329522;
    b5 = -0.7616 * b5 - white * 0.0168980;
    output[i] = b0 + b1 + b2 + b3 + b4 + b5 + b6 + white * 0.5362;
    output[i] *= 0.11; // (roughly) compensate for gain
    b6 = white * 0.115926;
}

To understand what these magic constants are, I highly recommend reading DSP generation of Pink (1/f) Noise. This is one of those sadly decaying corners of the web where you find that many of the links are pointing to long dead servers. Specifically, this code was posted by Paul Kellet in October, 1999 and still stands, 26 years later, as the best approximate of a -3dB per octave filter. Copying and pasting code you don't fully understand is an honourable and long-standing tradition.

Real-world experience

Finally, we get to the actual joke part of the entire project, some 14 paragraphs through this post. Initially I was thinking I would make something genuinely relaxing, like intermittent bird sounds or wind chimes. However with the state of the world being what it is, it seems better to try and innoculate yourself against things with controlled exposure. The excellent freesound.org has a huge catalogue of conveniently tagged clips. I grabbed a selection and converted them all to fairly compressed AAC files as I'm aiming for lightweight here, not gold-plated audiophile quality - I want this to load as fast as possible. Then I just play random sounds at random intervals to create the effect. So, thank you and credit to the various users below.

Screams

A series of endless overlapping screams. Feel free to release your own tension and join in.

Traffic

Get the true experience of returning to the office by sitting in traffic for as long as it takes.

Construction

Yes, the sound of growth, a thriving economy, and all right outside your window all day!

TODO

No personal project is ever finished, so here is a selection of some of the updates I'd like to add:

Subtle SVG noise to create a textured effect to the background and buttons.
The LCD icons are definitely an MVP version, I want something that fits the aesthetic a bit better and has more interesting animation.
Stereo or spatial effects on the audio. The generated noise should be more immersive and I'd like the screaming to sound as if it's coming from every direction.
More use of the Media Session controls - probably adding a next track button that lets you change the noise type.
Smoother start, stop, and switch of noises. The fade in on start is reasonable, but ending is far too abrupt.

There's plenty more to do, so if you've got requests then ping me on your preferred social network in the footer to let me know!

Create a 🖨️ printable zine with CSS

Rowan Merewood — Wed, 08 Apr 2020 23:09:39 +0000

I loved the ingenuity of zine templates, that origami or map-like magic of a single piece of paper folding into an entire little book. That made me think, surely we should be able to do this on the web - right? A web page that you can read on a screen, but when you press print it turns into that magical little book. The answer is: of course we can! If you want the short version, then jump right in and read about how to make a CSS zine... in the form of a CSS zine!

Have a peek below ⤵️ or
on ➡️ zine-machine.glitch.me

We're going to need two key bits of functionality to make this happen:

🏗️ HTML structure

Let's see how we build this up. Step one is a nice, simple, semantic layout for our HTML:

<main class="zine">
  <header class="zine-page page-1"></header>
  <section class="zine-page page-2"></section>
  <section class="zine-page page-3"></section>
  <section class="zine-page page-4"></section>
  <section class="zine-page page-5"></section>
  <section class="zine-page page-6"></section>
  <section class="zine-page page-7"></section>
  <footer class="zine-page page-8"></footer>
</main>

You can style that for the screen however you want, the important bit is that we're going to wrap the styles that are just for screen display in a media query:

@media screen {
  body {
    max-width: 30rem;
    background: #ead1dc;
    margin: auto;
  }

  .zine {
    background: white;
    padding: 10px;
    border-left: 4px solid #741b47;
    border-bottom: 4px solid #741b47;
  }

  .zine-page {
    margin-top: 10px;
  }
}

Nothing too exciting, but just so we can break up the text a little let's see what that looks like with a little text thrown in there:

🖨️ Print CSS

Now the fun part, we can then use the matching @media print query to enclose our print styles… but what are we going to put in there? First, let's see what we're trying to make. Here's the layout of the pages we need:

As you can see, this doesn't flow in any kind of top-to-bottom order that would match the order of the content in our HTML. We don't want to add any weird markup to make this possible, so we're going to use CSS grid to essentially pick up and reposition each individual page where we need it.

First, let's drop in a little CSS to hint how we'd like the page set up. We can use the @page rule for this.

@media print {
  @page {
    size: landscape;
    margin: 0;
    bleed: 0;
  }
}

To be honest, it's going to be a bit hit or miss as to whether or not the combination of your browser, OS, and printer actually pays any attention to that… but it's nice to say we tried.

🔲 CSS Grid

Next up, let's create our grid. We've got our .zine container which holds each .zine-page.

.zine {
  width: 100vw;
  height: 100vh;
  display: grid;
  grid-template-areas:
    "page-5 page-4 page-3 page-2"
    "page-6 page-7 page-8 page-1";
}

I ❤️ grid-template-areas because you're essentially just dropping in a diagram that matches your layout. In this case, we've laid out some named areas mapping to each of our pages in a 4 × 2 grid.

We need to map those grid areas up to our individual page elements though, so let's pop in that mapping:

.page-1 {
  grid-area: page-1;

}

.page-2 {
  grid-area: page-2;

}
// you get the idea...

Now we're getting somewhere! Let's take a look at the print preview for the page and see what we get!

That's progress, but we need to flip a few of those pages upside down. That's easy enough with a CSS transform:

.page-5, .page-4, .page-3, .page-2 {
  transform: rotate(180deg);
}

That's our layout done! Well, almost... when you print it out you need to fold along the edges of the page. You can do this just by folding in half, but let's pop some guidelines in just to make it clear. Now, we could go in an but the relevant individual border definitions on the edges of each .zine-page but frankly that's a lot of work and it's doubly confusing to remember that border-top will actually be at the bottom of the rotated pages. So, we're just going to use the simple trick of settings a background colour for our grid, and put gaps between our white pages so that the grid shows through. Simple!

.zine {
  width: 100vw;
  height: 100vh;
  display: grid;
  grid-template-areas:
    "page-5 page-4 page-3 page-2"
    "page-6 page-7 page-8 page-1";

  gap: 1px;
  background: lightgrey;
}

I've made that gap a bit bigger for the screenshot, but there we go!

There's one slight tweak to the transform though:

.page-5, .page-4, .page-3, .page-2 {
  transform: rotate(180deg) translateX(-0.25px);
}

For some reason, the pages don't seem to rotate around their exact centre, which means that when the border is visible is doesn't exactly line up either. If like me, that ever so slight but niggling obvious misalignment keeps you lying awake at night then that little bump over from the translateX will fix it.

That's it! There are plenty of cool things to still do with different content for the screen versus print version. For example, you could make sure that any links in the document are added to the print output with:

@media print {
  a::after{
    content: " (" attr(href) ") ";
  }
}

You might also want to swap out images that would be ink-heavy in the print version for simpler line-art.

♻️ Make and share your own!

I'd love to see you make your own 'zine, like this hand-drawn one from Erika on electronics:

// Detect dark theme var iframe = document.getElementById('tweet-1140991227762040833-418'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1140991227762040833&theme=dark" }

I'm sure there are some usability tweaks to add in the code too! So, go out there and remix the project to show me what you create!

Prudent publishing to npm

Rowan Merewood — Wed, 21 Aug 2019 17:43:23 +0000

This post shares a few practices I find helpful for keeping my publishing of packages to npm a bit more isolated from my personal environment. I think there are good principles here, but they may be a bit specific to my project and platform. Please do comment with variants or tips for your own environment. Hey - maybe even do a whole post of your own!

💌 Sign up to npm with a separate email

This is good practice for most developer channels - whether it's publishing an Android app in the Play Store, your account for a particular API you rely on, or your npm account. There are a number of reasons for doing this:

⛔ Accounts get banned by mistake! You as a person on npm is different to the account that owns your packages. If one gets banned, it doesn't affect the other.
🤝 Other people may need access. While an organization is the right solution long-term, sometimes there are emergencies or one-offs and sharing access to the one specific account is definitely better than your personal one!
👔 This email may need to be public. You may want to provide support or perhaps you just get random enquiries. Using a separate address lets you manage that as it's own thing.

No real instructions on this one... source that email address wherever you want!

🎭 Publish using a separate local user

This has more explicit security benefits than using a separate email (which frankly is more about your personal happiness).

Most of the issues here come from other packages getting compromised and injecting malicious code. Two specific incidents here were with some of the ESLint packages including code that stole npm tokens and the event-stream package getting compromised to steal cryptocurrency. Creating an isolated user helps mitigate this by reducing the exposure. So, for example if there is an exploited package that's able to kick in during the deployment process - it won't have access to your personal user. Likewise, an exploited package in your development environment won't have access to your deployment process.

If you're being really conscientious, then you should really ensure all your npm operations run as a separate user but that does start to turn into a lot of overhead.

I'm a Linux user, so these instructions are all based on my Bash shell environment. Please do share if there are tweaks for your own platform!

🐣 Right, let's get our user created:

$ sudo adduser deploy-npm

You'll be prompted to create a password. Obviously use something solid, but we don't need to care what it is. We're going to use sudo when we access it.

🕵️ Now we need to configure the environment for the new deploy-npm user. We'll use sudo to log in to that account:

$ sudo -i -u deploy-npm

The user will need to have access to a version of Node and npm. I use nvm to manage this, so the first thing I'm doing is following their install instructions and getting the LTS version of Node. You can go about this however you want. For example, maybe you already have Node installed system-wide and it's therefore immediately available for the new user.

☑️ Verify your set-up just by checking the npm version:

$ npm -v

👋 Now it's time to log in to the account! Unsurprisingly, that done with:

$ npm login

🔐 If you haven't already enabled two-factor authentication on your account this is an ideal time to do it! This means even if your account is compromised or the tokens stolen the attacker still can't do anything without that second authentication mechanism.

$ npm profile enable-2fa auth-and-writes

💾 We also need a local copy of the repo. Our deploy user isn't going to commit anything and doesn't have SSH credentials set up anyway, so we're just going to use the HTTP version. This assumes your code is on GitHub, but any read-only checkout is what you're aiming for here.

$ git clone https://github.com/someUser/my-package.git

🔏 The assumption here is that you've already appropriately tagged the repo ready for a release. So, let's change into the directory and checkout the tag.

$ cd my-package
$ git checkout tags/0.0.1

🎁 That's all the set-up done, so now we publish! Assuming you did enable 2FA, you're going to get asked for your confirmation code here.

$ npm-publish

For my use, I've wrapped that up in a script that I can use to publish a given tag. This first one is running as the deploy-npm user and is effectively just the commands we used above. I've saved it as deploy-npm.sh in the user's home directory.

#! /bin/bash
cd &&
source .nvm/nvm.sh &&
cd my-package &&
git fetch &&
git checkout tags/$1 &&
npm publish

Finally, I have a script in my own account that does the appropriate sudo call to run as the deploy-npm user.

#! /bin/bash
sudo -H -s -u deploy-npm /home/deploy-npm/deploy-npm.sh $1

🤖 Now, after I've tagged up a release I just run:

$ deploy-npm.sh 0.0.2

If you're still looking to tighten things up, try this post from Liran with a selection of other useful tips.

npm security tips to keep you safe of malicious modules

Liran Tal ・ Aug 19 '19

#npm #node #security #javascript

Save a developer with npm --save-dev

Rowan Merewood — Tue, 20 Aug 2019 08:27:14 +0000

I was going to cleverly call this post "npm -g considered harmful", but unsurprisingly Matt Behrens got there back in 2016 with this excellent article. As a separate lesson, reading it made me think there was no point me writing this because Matt had already explained this so well- but you know what?

It's new Date().getFullYear(); and this pattern is still everywhere, so a little repetition ♻️ and amplification 📣 won't hurt.

⚠️ What's the problem?

I remember saying to a colleague recently, that one of my reasons for liking Linux was the convention of having all your dependencies centrally managed. Everything can be regularly updated in the background, no surprise 6GB downloads whenever I want to start an app (yeah - I'm looking at you, PlayStation), no need to remember where I downloaded the software... just one command.

Of course, I was lying to myself - talking up the life I wish I had, not the tedious reality I actually experience. After running apt-get it turns out I then need to run npm -g update. I should also check nvm --install --lts to ensure that's up to date. Oh, I should also do a flatpak update since that's where the cool kids are dropping apps now. Then of course, there's that project that decided to use some Python dependencies, so I better look up that oh-so-elegant one liner to pipe pip list through 50 commands until it hits xargs. Then, of course, just go through the stragglers that rolled their own update mechanisms because...

(╯°□°)╯︵ ┻━┻

Anyway ┬─┬ノ( º _ ºノ) it was early in the morning when I wrote this. I really do want to use and contribute to your opensource project, but don't make it more work than it needs to be. Luckily, we can fix this together and it's going to make your life as a maintainer easier too.

First, it's not just the overhead of updating packages that's an issue. A global dependency means there's (probably) one version on the system. If I have multiple packages that depend on different versions of that tool, I'm in trouble.

🆘 Save this developer

🚫 So, if you read or are tempted to write documentation that advises this:

npm -g install my-cool-tool

✔️ Instead, I want you to write:

npm --save-dev my-cool-tool

This will add my-cool-tool as a development dependency for the project. That means there will be an executable accessible as ./node_modules/.bin/my-cool-tool. Of course, that's an unwieldy path to type each time.

🚫 So, where you were going to just run this:

my-cool-tool

🚧 Instead we're going to make use of "scripts" section in our package.json because any command we put there will check our packages ./node_modules/.bin directory first.

{
  "scripts": {
    "my-cool-tool": "my-cool-tool"
  }
}

✔️ Now, you can run the following:

npm run my-cool-tool

🏄 That's it!

It's mostly just a translation, not a big shift - but I think they pay off is worth it. Now, if I want to use or contribute to your project then I just need to run npm install and know that I've automatically got my developer environment set up. Who knows, that developer coming back to the project on a new machine a year later... may even be you!

Form and function

Rowan Merewood — Fri, 19 Jul 2019 16:30:54 +0000

This is the second in a series of posts detailing how I built the 🥑 Rotavo PWA. Give it a whirl and see what you can draw!

In the previous instalment we built the touch-controlled <input-knob> component that let us create a rotating knob with a value attribute corresponding to its angle. However, fun as that might have been it's still missing some functionality to be practical for general use.

♻️ Freshen up
👂 Quite the event
🔒 Enforcing limits
🧛‍♂️ Count rotations
🎁 Bonus content

♻️ Freshen up

First though, let's freshen up the previous demo with a few cosmetic improvements. I said we were going to build something that resembled a volume control knob on a stereo. Now, we got the rotating behaviour in there but our knob was square... traditionally they're round. You were all kind enough not to mention that, but we should fix that before we move on.

We also want an indicator for which way is "up" on our knob. As we saw in the final demo last time, we can just add any content we need inside the element. So we'll drop in a little triangle indicator there:

<input-knob value="2.5"><div class="mark">▲</div></input-knob>

We then need to style that so it's central:

.mark {
  display: inline-block;
  width: 100%;
  text-align: center;
  font: bold 200% monospace;
  color: #356211;
}

The primary change on the control is using border-radius to round off those corners. We're also going to put the shadow on the outer input-knob element as that does not rotate. If we had the shadow on the inner ::part(container) it looks as if the shadow moves around the element instead, which is not the effect we're after.

input-knob {
  border-radius: 100%;
  box-shadow: 0 0.3rem 0.3rem rgba(0, 0, 0, 0.5);
}

input-knob::part(container) {
  box-sizing: border-box;
  background: #cadbbc;
  border: 1rem double #356211;
  border-bottom: 1rem solid #356211;
  border-radius: 100%;
  width: 8rem;
  height: 8rem;
}

Rounded corners! The original CSS holy grail - revel in it.

There is also a little improvement we can make to the styling of :host on our Shadow DOM template as well. Specifically, we want the cursor to change into the little 👆 pointer indicating to the user they can interact with it.

:host {
  display: inline-block;
  user-select: none;
  touch-action: none;
  cursor: pointer;
}

👂 Quite the event

Now we've added a little polish to our element, we've got something visually pleasing but it's hard to react to any changes when the user interacts with the element. In the same way that we listen for Pointer events inside the element, we want to emit our own events in order to respond to them in the wider application.

Much like the Pointer events, we want to track the beginning, middle, and end of the interaction. That means we will create three Event types:

knob-move-start: when the element is touched / clicked
knob-move-change: when the element is moved
knob-move-end: when the element is released

We're going to emit these events at the end of each handler inside of the element, because we want to be sure that we've done all the necessary work inside the element before anything attempts to process the event.

// class InputKnob
_rotationStart() {
  // ✂️ existing code hidden      
  const evt = new Event('knob-move-start', { bubbles: true });
  this.dispatchEvent(evt);
}

_rotationChange() {
  // ✂️ existing code hidden    
  const evt = new Event('knob-move-change', { bubbles: true });
  this.dispatchEvent(evt);
}

_rotationEnd() {
  // ✂️ existing code hidden
  const evt = new Event('knob-move-end', { bubbles: true });
  this.dispatchEvent(evt);
}

Note, we need to make sure we specify bubbles: true because our listener is going to be a parent element. You can try removing this and you'll see the event never "bubbles up" to the parent nodes.

With these events firing, we can listen for them just like any other:

document.addEventListener('knob-move-start', logEvent);

Take a peek at the demo below to see how we're using the logEvent() function to light up some <span> elements when the events fire.

⚖️ Have some sense of proportion

Currently the value of the element maps directly to its angle. If we had a volume control that went from, say, 0 to 11 then that's what we want the value to match. Otherwise we're forcing our developer to do the conversion from the angle to the value themselves, which is just rude. To address this, we'll add a scale attribute where our developer can specify the value for a full rotation.

First, let's add that new attribute to the element. We want the usual attribute-to-property mirroring, however a little note - our default value is 1 as scale will be a multiplier and multiplying by 0 will always give us... well, 0 again. Let's drop that in:

// class InputKnob
static get observedAttributes() {
  return ['value', 'scale'];
}

get scale() {
  return this.hasAttribute('scale') ? this.getAttribute('scale') :1;
}

set scale(scale) {
  this.setAttribute('scale', scale);
}

However now value and _angle are dependent on scale, so we have a bit of linking up to do. Whenever one of our attributes changes, we need to make sure we recalculate:

attributeChangedCallback(attrName, oldVal, newVal) {
  this._angle = (TWO_PI / this.scale) * (this.value % this.scale);
  this._drawState();
}

So, if our scale is 10 and our value is 5, then that should be half a rotation on the knob - or an _angle of π - or pointing straight down.

The matching part is now when the _angle changes, we also need to update the value.

// _rotationChange()
this.value = this._angle / (TWO_PI / this.scale);

So, to reverse what we had above if the angle comes out at π then we should expect a value of 5. That's... well, that's actually it for adding scale. So, you can verify that in the demo below. We've set the scale to 10, so ⬆️ = 0, ➡️ = 2.5, ⬇️ = 5, ⬅️ = 7.5. Give it a 🔃 below!

As a little bonus, take a peek at the CSS in this demo. The layout uses a CSS Grid layout with grid-template-areas where you basically draw a little text diagram of the layout you want. So, the arrangement of the items above is literally:

grid-template-areas: 
  ".  ⬆️ . "
  "⬅️ 🎛️ ➡️"
  ".  ⬇️ . ";

Would I recommend this in production? Who knows... I mean, I've seen far worse.

🔒 Enforcing limits

While there's a certain whimsical freedom in being able to spin the knob infinitely, every so often we have a need to set some limits. A volume control would make no sense if it allowed values below zero, and if you can go higher than 11 - well, who knows what the consequences might be.

Let's set up some attributes to hold the minimum and maximum limits for the element, appropriately named min and max. This is, hopefully unsurprisingly, the same as the scale attribute we added earlier.

// class InputKnob
static get observedAttributes() {
  return ['value', 'scale', 'min', 'max'];
}

get min() {
  return this.hasAttribute('min') ? this.getAttribute('min') : null;
}

set min(min) {
  this.setAttribute('min', parseFloat(min));
}

get max() {
  return this.hasAttribute('max') ? this.getAttribute('max') : null;
}

set max(max) {
  this.setAttribute('max', parseFloat(max));
}

The default value is null since we won't want to enforce the limit if it's not set. In other words, if the attribute is null:

That means instead of just calculating and setting the _angle and value we need to check if they're within the bounds first. The calculations stay the same, we're just renaming to _attemptedAngle and _attemptedValue. Then we check to see if the limit is set that our attempted value is on the right side of it before we transfer the value over.

// _rotationChange()
this._attemptedAngle =
  this._initialAngle
  - this._initialTouchAngle
  + Math.atan2(this._touchY - this._centerY, this._touchX - this._centerX);
this._attemptedAngle = (this._attemptedAngle + TWO_PI) % TWO_PI;
this._attemptedValue = this._attemptedAngle / (TWO_PI / this.scale);

if (
  (this.min === null || this._attemptedValue >= this.min) &&
  (this.max === null || this._attemptedValue <= this.max)
) {
  this._angle = this._attemptedAngle;
  this.value = this._attemptedValue;
}

With that logic in place, now we can add a knob that restricts its movement between two values:

<input-knob value="5" scale="10" min="2.5" max="7.5">

Give it a go in the demo. Spin all you like, but those upper values are all off limits! ⛔

🧛‍♂️ Count rotations

If you're the type of engineer whose natural inclination is to immediately break the lovingly crafted code in front of you, then you may wondered, "what happens if max is higher than the scale?" Luckily, nothing breaks per se but it does make that max value a bit meaningless as we can never reach it. Well... unless we can count the number of rotations. For example, one complete turn gets us to 10, another complete turn gets us to 20, and so on. Think of it like a winch or a crank pulling a bucket out of a well - as you turn the crank, the rope winds in or out until it reaches the top or bottom.

We're not going to expose _rotations as an attribute since it's a result of value and scale. If we did have it there, we would need to introduce some confusing precedence rules about what happens if you set things that conflict and... eugh, I'm not touching that. Anyway, let's get that derived _rotations value initialised when the element is connected.

attributeChangedCallback(attrName, oldVal, newVal) {
  this._angle = (TWO_PI / this.scale) * (this.value % this.scale);
  this._rotations = Math.floor(this.value / this.scale);
  this._drawState();
}

You can see the parallel to how the angle is set: _angle is the remainder (or modulus) of the value divided by the scale. The number of _rotations is the whole value (or the quotient) of the value divided by the scale. That's the pairing of a % b on the first lint and Math.floor(a / b) on the second.

To track when there's a change in rotation we are going to divide our element into four quadrants. A move between either of the top quadrants is going to count as a change in rotation.

Moving in or out of the lower quadrants is going to just be movement within the same rotation. This change means we need to track the previous angle so we have something to compare against when we calculate the new one.

The last bit to consider before we look at the code is that we now effectively have two modes of operation for our element. The first we've seen - spin the knob and once you go over the upper scale then you loop round to 0. However, now we're tracking rotations we've got a value that increases on every rotation. It's probably not a good idea to have a control that lets the user increase the value to infinity, so we should ensure that's bounded in some way. That means the check we're going to add is that we will only track _rotations if the min and max values are set. I know, I know - we're not currently validating those attributes at all... but, I've got to save some content for the next article!

Right, let's step through tracking that change in rotation:

// _rotationChange()
// Grab the previous angle for comparison
this._previousAttemptedAngle = this._attemptedAngle;
this._attemptedAngle = // ✂️ calculate attempted angle

// Track rotations if max and min are set
if (this.max !== null && this.min !== null) {
  // +1 rotation if:
  // new angle is in the top-right quadrant, e.g. < ½π
  // old angle is in the top-left quadrant, e.g. > 1½π
  if (this._attemptedAngle < 1.57 && this._previousAttemptedAngle > 4.71) {
    this._attemptedRotations++;
  }
  // -1 rotation if:
  // old angle is in the top-right quadrant, e.g. < ½π
  // new angle is in the top-left quadrant, e.g. > 1½π
  else if (this._previousAttemptedAngle < 1.57 && this._attemptedAngle > 4.71) {
    this._attemptedRotations--;
  }
}

// New value now includes the rotations
this._attemptedValue =
    (this._attemptedAngle / (TWO_PI / this.scale))
  + (this.scale * this._attemptedRotations);

// Update everything if the value is within bounds
if (
  (this.min === null || this._attemptedValue >= this.min) &&
  (this.max === null || this._attemptedValue <= this.max)
) {
  this._angle = this._attemptedAngle;
  this._rotations = this._attemptedRotations;
  this.value = this._attemptedValue;
}

Demo time! Let's bring it full circle (aaay! 🥁) with our first demo where we had an <input type="range"> controlling the <input-knob>. Flip it back and reverse it, so we've got an <input-knob> controlling an <input type="range">.

We can set the tags up like so:

<input-knob value="50" scale="10" min="0" max="100">...</input-knob>
<input type="range" class="progress" min="0" max="100">

Then using the same listener for knob-move-change we update those values:

// logEvent()
const curValue = Number.parseFloat(knob.value).toFixed(3);
showValue.textContent = curValue;
range.value = curValue;

Now 10 rotations of the element should take you all the way from 0 to 💯. Ideal place to wrap things up for this entry, I think.

Next time we are going to ensure our component is accessible, because while the touch input is fun - it's not an option for everyone.

🎁 Bonus content

Oh ho, I couldn't leave you without a little treat at the end now, could I? So, continuing the somewhat dubious tradition of borrowing my colleagues' faces (thank you / apologies to Jake Archibald) please feel free to discover what happens when you wind up this... "Jake in a box".

You spin me right r und

Rowan Merewood — Mon, 08 Jul 2019 09:52:54 +0000

This is the first in a series of posts detailing how I built the 🥑 Rotavo PWA. Give it a whirl and see what you can draw!

None of the cool kids are into skeuomorphism any more, but that doesn’t mean there’s no place for an analogue to physical controls in the software world. Let's see how we can recreate the (hopefully) intuitive experience adjusting the volume on your stereo 📻 by building our own rotating, touch-sensitive knob web component.

🎛️ Sliders, tapes, and dials
⚛️ A basic Custom Element
👻 Enter the Shadow DOM
🚧 Browser support
🤝 Handle touch
👆 Pointer Events and default behaviour
📐 Touching trigonometry
🔄 A touching demo
🚧 Oh wait… browser support
🖌️ Painting and performance
🏆 Bonus content

🎛️ Sliders, tapes, and dials

We're going to use input type="range" as the basis of the API we want our component to present. The snippet below will create a little slider that will go from from 0 up to 100 with a starting value of 42.

<input type="range" name="volume" min="0" max="100" value="42" />

A solid foundation, but is it the best solution? If like me, you enjoy the light reading that is the proceedings of the Symposium on Human Interface 2009, Held as Part of HCI International 2009, then nestling in part 2 around page 773, you'll find this valuable nugget:

Pilots find it harder to read tape displays than analog dials

We're going to need a little pilot lingo to make sense of the UX knowledge that's being dropped here.

A "tape" display shows information in a linear fashion, named because it was literally a tape that spools up and down behind the glass. This might be used to show something like altitude or air speed. An alternative is the dial indicator that displays that same linear information in a rounded layout, often used on a car dashboard for speed and fuel level. The hypothesis here is that a human can quicker interpret a rough value from the dial as opposed to the tape because the entire range is visible.

I'll be honest, this isn't overly relevant to building our component but I wanted your first impression to be that I was taking an evidence-based approach to my work. Plus, the more I think about it I'm not sure the benefit of seeing the whole scale in one go on a dial actually applies to a knob we can rotate multiple times… The truth is, I built this for fun and it's a happy accident that something of value came out of it. We shall park the Engineering vs. Art debate for now though and move on to creating this component.

⚛️ A basic Custom Element

I'm going to zip through the basics fairly quickly, so if you're looking for a proper introduction you should head over to "Custom Elements v1: Reusable Web Components".

We're going to start simple: an element with a single value attribute. A Custom Element needs a "-" in the name to distinguish it from built-in elements, so let's go with <input-knob> to provide that link back to <input type="range">:

<input-knob value="1"></input-knob>

For convenience, we're going to map the attribute on the HTML element to the JavaScript class as well so that we can do things like this:

const knob = document.querySelector('input-knob');
knob.value = 2;

That means we need to extend the HTMLElement class, wire up the attributes, and then connect it to our page:

class InputKnob extends HTMLElement {
  constructor() {
    // Nothing to do in here at the moment, but we do need to call the parent
    // constructor
    super();
  }

  // Watch for changes on the 'value' attribute
  static get observedAttributes() {
    return ['value'];
  }

  // Map the JavaScript property to the HTML attribute
  get value() {
    return this.hasAttribute('value') ? this.getAttribute('value') : 0;
  }

  set value(value) {
    this.setAttribute('value', value);
  }

  // Respond to any changes to the observed attributes
  attributeChangedCallback(attrName, oldVal, newVal) {
    // nothing yet
  }
}

// Map the class to an element name and make it available to the page!
window.customElements.define('input-knob', InputKnob);

Now, if you load that up in the browser you will see… nothing. Nothing on the page and nothing in the console. Nothing is displaying, but also - nothing is explicitly broken. We've successfully attached a new element in the page, but all we've created is an empty element. So, it's working in the same way that adding an empty <span> to a page "works". Conveniently though, our new <input-knob> element can be styled just like anything else on the page - let's make things a bit more obvious.

input-knob {
  display: block;
  background: #cadbbc;
  border: 1rem dashed #356211;
  box-shadow: 0.3rem 0.3rem 0.3rem rgba(0, 0, 0, 0.5);
  width: 8rem;
  height: 8rem;
}

Et voilà, a visible square!

👻 Enter the Shadow DOM

With the element display, we should do something with the value attribute. Specifically, we want to rotate the element based on the attribute's value. The core of this is going to be a CSS variable that we use in a transform, like this:

{
  --angle: 0rad;
  transform: rotate(var(--angle));
}

However, we don't want to just set this style directly on the <input-knob> element as it's exposing an implementation detail to the user of our component. If a developer wants to add <input-knob> to their page and apply a rotation, it's going to clash. To address this, we're going to make use of the Shadow DOM to create some markup that's essentially private to our component where we can add our own structure and style needed to enable the component's behaviour.

We're going to start with this HTML:

<style>
  #container {
    --angle: 0rad;
    transform: rotate(var(--angle));
  }
</style>
<div id="container" part="container">
  <slot></slot>
</div>

Let's break down what's happening here:

The --angle CSS variable will be updated to control the rotation of the element
The id="container" in the <div> is defining the wrapper element we're going to rotate
The part="container" in the <div> instructs that we want to make the element available for styling externally
The <slot> element defines where <input-knob>content in the tag</input-knob> should be rendered

The reason we want to expose the <div> for styling via part="container" is because our now our "<input-knob>" element is not going to rotate. So, that can still be styled - but that will remain fixed when the value changes. Instead we need to make use of the ::part() selector in our style sheet. In this case, it's a simple addition.

input-knob::part(container) {
  display: block;
  background: #cadbbc;
  border: 1rem dashed #356211;
  box-shadow: 0.3rem 0.3rem 0.3rem rgba(0, 0, 0, 0.5);
  width: 8rem;
  height: 8rem;
}

Back to our element, now we know what structure we want it's time to drop that in a template our element can use. We'll define that just outside the InputKnob class:

const template = document.createElement('template');
template.innerHTML = `
  <style>
    #container {
      --angle: 0rad;
      transform: rotate(var(--angle));
    }
  </style>
  <div id="container" part="container">
    <slot></slot>
  </div>`;

Next we want to add a shadow root to our element and clone that template into it:

class InputKnob extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.appendChild(template.content.cloneNode(true));
    this._container = this.shadowRoot.getElementById('container');
  } // ✂️ rest of the class omitted
}

We're grabbing a reference to our #container so that we can update that --angle variable.

// class InputKnob
_drawState() {
  this._container.style.setProperty('--angle', `${this.value}rad`);
}

We want to update that value when the component is first added to the page and whenever the value is changed.

// class InputKnob
connectedCallback() {
  this._drawState();
}

attributeChangedCallback(attrName, oldVal, newVal) {
  this._drawState();
}

With that, we've now got a component that rotates based on the value attribute. We can verify that by opening up the browser console to try setting those values and watching the square rotate.

Ok, ok - you're underwhelmed, I should give you something interactive. Let's bring it full circle and add a slider to control the rotation. It's as simple as:

<input-knob value="2.5"></input-knob>
<input type="range" name="angle" min="0" max="6.28" step="0.1" value="1" />
<script>
  const knob = document.querySelector('input-knob');
  const slider = document.querySelector('input[type=range]');
  // Just take the value from the slider and set it straight on the knob
  slider.addEventListener('input', () => { knob.value = slider.value; });
</script>

Try it for yourself here below. The slider should take the square from 0 to just under 2π (6.28) radians or a full rotation.

🚧 Browser support

That was a little too clean though, eh? Hardly what modern web development is all about. I may have neglected to mention that there's a bit more going on in the above example to get it display in different browsers. In fact, if you check MDN's section on browser support for ::part() - hmm, well I should probably drop a pull request in for that. Basically, it's Chrome and other browsers have made positive noises but we're not there yet.

First issue is addressing browsers that don't support Custom Elements or Shadow DOM as much as we need. Luckily, we can use the webcomponents.js polyfill which will detect what support is needed. Drop that script in before importing / defining the element. I'm grabbing it from unpkg.com, but you can also just download the bundle or use npm as per the instructions.

<script src="https://unpkg.com/@webcomponents/webcomponentsjs"></script>

Don't get lulled into a false sense of security - it gets dirty now. I couldn't find a good way of detecting support for ::part(), so bear with me. Remember we added the part="container" attribute to our element? We're going to test if that attribute is accessible via JavaScript. If it isn't, we need to create some alternate structure to style. In this case, a <span> to wrap any content in the element and a .fallback class.

// connectedCallback()
if (!this._container.part) {
  // create a <span>
  const wrapper = document.createElement('span');
  // move this element's child nodes into it
  wrapper.append(...this.childNodes);
  // add the classes
  wrapper.classList.add('fallback');
  this.classList.add('fallback');
  // and add the wrapper into this element
  this.append(wrapper);
}

Now we duplicate the styling for the fallback elements:

input-knob.fallback {
  display: block;
}

input-knob.fallback>span.fallback {
  display: block;
  background: #cadbbc;
  border: 1rem dashed #356211;
  box-shadow: 0.3rem 0.3rem 0.3rem rgba(0, 0, 0, 0.5);
  width: 8rem;
  height: 8rem;
}

Ideally, instead of duplicating the whole block we could add the selector to our existing rule - however, that causes at least one of the other browsers to ignore the whole thing. So, copy/paste it is. Gross. Anyway, now we have an element that works just about everywhere and we shall never speak of this again. Let's move onto something more fun.

🤝 Handle touch

Using the slider proves we can control the rotation, but things get a little more complicated if we want to be able to tap and drag the element around. We're going to need to do three things:

Use Pointer Events
Suppress some default browser behaviour
Desperately try and remember some trigonometry from school

👆 Pointer Events and default behaviour

Let's start with Pointer Events (frankly, it's a lovely API) and throw in a dash of dealing with defaults as neither of these are going to cause us much pain - unlike that last item on the list.

class InputKnob extends HTMLElement {
  // ✂️ existing code has been removed
  constructor() {
    // Capture the pointer so that the user can still rotate the element even
    // if they leave the bounding area of it.
    this.setPointerCapture(e.pointerId);
    // Re-bind this for listeners so that this == instance of this class
    this._onPointerdown = this._onPointerdown.bind(this);
    this._onPointermove = this._onPointermove.bind(this);
    this._onPointerup = this._onPointerup.bind(this);
  }

  connectedCallback() {
    // Listen for pointerdown events when the element is connected to the page
    this.addEventListener('pointerdown', this._onPointerdown);
  }

  disconnectedCallback() {
    // And stop listening if the element is removed
    this.removeEventListener('pointerdown', this._onPointerdown);
  }

  _onPointerdown(e) {
    e.preventDefault();
    // A long press can bring up the context menu, we want to disable that when
    // the user is controlling the element
    window.oncontextmenu = () => { return false; };
    // Only add listeners for the other events once interaction has started
    this.addEventListener('pointermove', this._onPointermove);
    this.addEventListener('pointerup', this._onPointerup);
    this.addEventListener('pointercancel', this._onPointerup);
  }

  _onPointermove(e) {
    // On all of these we're preventing the default behaviour as we assume our
    // web developer won't do something like put a <button> inside the element.
    e.preventDefault();
  }

  _onPointerup(e) {
    e.preventDefault();
    // Re-enable the context menu
    window.oncontextmenu = null;
    // Release the pointer we captured earlier
    this.releasePointerCapture(e.pointerId);
    // Remove all our listeners
    this.removeEventListener('pointermove', this._onPointermove);
    this.removeEventListener('pointerup', this._onPointerup);
    this.removeEventListener('pointercancel', this._onPointerup);
  }
}

We also want to update the CSS in our template to ensure some sensible interactions. We're going to make use of the :host pseudo-class to select the outer <input-knob> tag.

host {
  display: inline-block;
  user-select: none;
  -webkit-user-select: none;
  touch-action: none;
}
#container {
  --angle: 0rad;
  transform: rotate(var(--angle));
}

There are three things happening in the above styles:

First, if you examine the <input-knob> element from the previous example in DevTools, you'll see it has an auto width and height and isn't taking up space in the document. We need the element to have a size if our user is going to have anything to touch!
Secondly, the user-select lines are preventing the user from selecting any text inside the control. Much like preventing the context menu from popping up, this stops odd text selection effects appearing when the user has their finger held down.
Thirdly, the touch-action tells the browser not to handle any of the usual gestures on this element - like panning, zooming, etc. as we're going to implement our own behaviour here.

📐 Touching trigonometry

Now the listeners are wired up, our element will receive pointer events that we can respond to. Let's dive into the math!

As a gentle intro, we're creating a convenient constant outside our class for later use:

const TWO_PI = 2 * Math.PI;

Next, we need to initialise some values when the user first touches the element. The easy ones to get are the coordinates of the pointer event, the centre of the element, and the starting angle.

// _onPointerdown(e)
this._touchX = e.clientX;
this._touchY = e.clientY;
this._centerX =
  this.offsetLeft - this.scrollLeft + this.clientLeft + this.offsetWidth / 2;
this._centerY =
  this.offsetTop - this.scrollTop + this.clientTop + this.offsetHeight / 2;
this._initialAngle = this._angle;

Next we need the starting angle of the touch away from a zero rotation. We can visualise this as drawing a right-angle triangle with one corner at the centre of the object and the hypotenuse going out to the user's pointer. We can get this angle from the 2 argument arctangent function, AKA Math.atan2(). By taking the pointer event coordinates and subtracting the centre coordinates for the element, we are basically normalising them as if the centre of the element was 0, 0.

// _onPointerdown(e)
this._initialTouchAngle = Math.atan2(
  this._touchY - this._centerY,
  this._touchX - this._centerX
);

Now when the user moves the pointer, we want to track that movement so we can rotate the element accordingly.

And how to we work out what's happening here? The answer is, of course, even more triangles. First, we can do exactly the same atan2() calculation we did before but with the new pointer location. If we subtract the starting angle from the current angle, that gives us the amount we've rotated in that touch. For the final angle of the element we take it's current rotation, i.e. the value and then add the amount we've rotated.

In the code, it looks like this:

// _onPointermove(e)
this._touchX = e.clientX;
this._touchY = e.clientY;
this._angle =
  // initial rotation of the element
  this._initialAngle
  // subtract the starting touch angle
  - this._initialTouchAngle
  // add the current touch angle
  + Math.atan2(this._touchY - this._centerY, this._touchX - this._centerX);
// Normalise value back into a 2π range
this._angle = (this._angle + TWO_PI) % TWO_PI;
// Done, update the value!
this.value = this._angle;

🔄 A touching demo

Oh my goodness, take a breather. If you're still with me, you… you've earned this. You can reach out with your mouse or finger and just spin that square around all you like.

🚧 Oh wait… browser support

Sorry, I know, I know. Pointer Events is getting there in terms of support, but it's not everywhere. We are going to need to swap in Mouse and Touch Events when Pointer isn't supported.

First step is to separate the Pointer-specific logic from the business of actually responding to the event. To be honest, that's good software engineering practice anyway and is probably how it should have been written in the first place. I'm not showing the _rotation*() methods as they literally are exactly the code that was there before.

_onPointerdown(e) {
  e.preventDefault();
  this._touchX = e.clientX;
  this._touchY = e.clientY;
  // ✂️ Chop out existing code, extract into new method
  this._rotationStart();
  this.setPointerCapture(e.pointerId);
  this.addEventListener('pointermove', this._onPointermove);
  this.addEventListener('pointerup', this._onPointerup);
  this.addEventListener('pointercancel', this._onPointerup);
}

_onPointermove(e) {
  e.preventDefault();
  this._touchX = e.clientX;
  this._touchY = e.clientY;
  // ✂️ Cut and paste again
  this._rotationChange();
}

_onPointerup(e) {
  e.preventDefault();
  // ✂️ One last time!
  this._rotationEnd();
  this.releasePointerCapture(e.pointerId);
  this.removeEventListener('pointermove', this._onPointermove);
  this.removeEventListener('pointerup', this._onPointerup);
  this.removeEventListener('pointercancel', this._onPointerup);
}

We also need to hook up the new listeners if we can't use Pointer Events:

// connectedCallback()
if ('PointerEvent' in window) {
  this.addEventListener('pointerdown', this._onPointerdown);
} else {
  this.addEventListener('touchstart', this._onTouchstart);
  this.addEventListener('mousedown', this._onMousedown);
}

And clean up when we're done:

// disconnectedCallback
if ('PointerEvent' in window) {
  this.removeEventListener('pointerdown', this._onPointerdown);
} else {
  this.removeEventListener('touchstart', this._onTouchstart);
  this.removeEventListener('mousedown', this._onMousedown);
}

The Mouse Events are easy to add in, since the surface we're using is identical to the Pointer equivalent:

_onMousedown(e) {
  this._touchX = e.clientX;
  this._touchY = e.clientY;
  this._rotationStart();
  document.addEventListener('mousemove', this._onMousemove);
  document.addEventListener('mouseup', this._onMouseup);
}

_onMousemove(e) {
  e.preventDefault();
  this._touchX = e.clientX;
  this._touchY = e.clientY;
  this._rotationChange();
}

_onMouseup(e) {
  e.preventDefault();
  document.removeEventListener('mousemove', this._onMousemove);
  document.removeEventListener('mouseup', this._onMouseup);
  this._rotationEnd();
}

Touch Events are slightly more involved as there's scope for multiple touches. However, we're just assuming the first touch is the one we care about and… well, it hasn't caused a problem yet.

_onTouchstart(e) {
  e.preventDefault();
  this._touchX = e.changedTouches[0].clientX;
  this._touchY = e.changedTouches[0].clientY;
  this._rotationStart();
  this.addEventListener('touchmove', this._onTouchmove);
  this.addEventListener('touchend', this._onTouchend);
  this.addEventListener('touchcancel', this._onTouchend);
}

_onTouchmove(e) {
  e.preventDefault();
  this._touchX = e.targetTouches[0].clientX;
  this._touchY = e.targetTouches[0].clientY;
  this._rotationChange();
}

_onTouchend(e) {
  e.preventDefault();
  this.removeEventListener('touchmove', this._onTouchmove);
  this.removeEventListener('touchend', this._onTouchend);
  this.removeEventListener('touchcancel', this._onTouchend);
  this._rotationEnd();
}

Whoo! That wasn't too bad - now our code has a better separation of concerns and cross-browser support!

🖌️ Painting and performance

We're not quite done here though. Even though the element is functioning, we should take a peek at how well the element is performing. For this, you will want to open up the previous Glitch demo in a new window so you can fire up Chrome's DevTools. We want to enable "Paint flashing" - you can find it under the 3 dot menu → More tools → Rendering → Paint flashing, or if you don't enjoy three levels of menus then bring up the command palette with Ctrl / Cmd + Shift + P and type "paint flashing". When you try rotating the element you will see a constant green rectangle drawn over it.

This is bad. It means the browser is having to paint on every single interaction and that's not always a cheap operation. If you are on a laptop or high-end phone, you probably won't notice anything but this will hit your framerate on low-end or busy devices. Luckily, the fix is super simple to add. We want to provide an indication to the browser that we intend to change the element in some way. Conveniently, the will-change property allows us to do exactly that. We specify this on the styling for our internal #container.

#container {
  --angle: 0rad;
  transform: rotate(var(--angle));
  will-change: transform;
}

Now the browser knows we intend to change the transform property and it can optimise for that result. Compare this updated Glitch demo with this one line added. You should see a brief initial flash, but after that - no paint events at all. Success!

🏆 Bonus content

So far, we haven't put any content within our element - we've just styled the element itself. If you look at the Rotavo app you'll see that the little 🥑 controls are just SVGs inside the tag. Turns out you can put any content you want inside that tag and render it. So, to finish things off for this article (with a huge thank you to the ever patient Paul Kinlan for lending me his face) please feel free to get to know… Paul Spinlan.

Next time we will explore adding custom events, min/max values, and counting rotations to the element so we can build an app around it!