Outdoor Cycling

Indoor Cycling

Pool Swim

Cycling


I was an early adopter of GitHub Copilot back in late 2021. I’ve experienced, firsthand, how the AI software industry has gone from being an advanced autocomplete to what it is today. We’re approaching a time where the role of each engineer will be to lead their own team - it’s just that the team is not human - they’re agents. I have no shame saying that, as a lead engineer for our team, I have not written code in more than 6 months.

I have fully adopted agentic coding and have been able to ship meaningful production changes at Vuori because of it. I’ve spent time researching tools, analyzing our codebase, coming up with and creating tickets, implementing new features, fixing security vulnerabilities, shipping internal tools, reviewing others’ work, and managing various third-party applications ALL without leaving the Claude CLI.

Out of the box, Claude Code is immediately impactful for anyone who uses it. And it only gets more powerful the more time you invest in learning and applying its deeper features. It doesn’t replace the skills engineers have developed; instead, it complements them and builds on our knowledge to make us more capable in our roles. It removes the burden of tedious tasks and improves the quality of life to free up time for more interesting work. It regularly invokes deeper and more precise thinking from the user, leading to better quality work and deeper understanding.

It takes a culture of curiosity and willingness to change to reach adoption at every level of the organization, but it’s not something we can solve top-down. We need the people with the boots on the ground to lean in and use these tools. All devs should have access, project managers should have access, engineering leaders should have access - everyone, no matter the role, should develop the skill of using these tools and should be expected to leverage them for their own specific use case because the tools are capable of doing so. I can confidently say that it will lift the individual and the organization as a whole to new heights.


From Copilot's autocomplete to agent teams, why adoption must be bottom-up to stick.

Leading With Agents


I’ve seen teams ship beautiful features on time, only to discover a few weeks later that the hidden costs are eating them alive - performance, bandwidth, security. The root cause is rarely exotic; it’s the missing details that AI didn’t catch because they weren't thought about in the first place.

The AI tools are better now, but somehow the standards aren’t. Now that the blast radius of a sloppy change is 10x what it used to be, the standard of quality must also 10x. A junior, misguided by StackOverflow in 2015, could push a bad regex and maybe break a few reports, but an agent-empowered junior in 2025 will let Copilot write an unbounded database query that costs the company six figures in egress fees before anyone notices.

The fine details used to be what separated senior engineers from the rest of the pack, but now that everyone has a senior engineer in their back pocket, it's the price of admission just to stay in the game.

Extreme attention to detail is no longer a differentiator. It’s the baseline. Anything less and you’re the most expensive kind of engineer there is: the one who ships fast and costs more later.

## The Fire Hose in Untrained Hands

AI coding tools are the most powerful fire hose we’ve ever been handed. Crank it open and you get 5,000 lines of beautifully formatted, type-safe, and 100% "confident" code...that may or may not completely brick your system.

I’m glad I spent the first several years of my career without that hose. I had to read every line, understand every branch, and feel the pain of my own mistakes in real time. It’s what taught me the craft.

Today’s early-career engineers often start with the hose already on full blast. A few figure out how to aim it and become really good, really fast, but most don’t. Companies have noticed this, and junior to mid-level roles are drying up because nobody wants to pay for the cleanup crew anymore.

You think you can rely on human code reviews to make sure nothing busted gets through? Yeah right. I know I'm not the only one who's rubber-stamped AI-generated refactors that looked flawless, but quietly tripled production bandwidth usage. The ownership is on the engineer wielding the hose.

Ego + sprint pressure + blind trust = career-limiting move.

## The Painting Is Never "Done" at 80%

Like a beautiful painting, lasting software takes shape in three acts:

1. Rough sketch — architecture, major shapes, get the skeleton standing.
2. Mid-tones — flesh out features, make it feel alive.
3. Final passes — the excruciating, time-consuming, career-defining details.

AI crushes Act 1 and is pretty decent at Act 2. However it's catastrophically bad at Act 3 unless you stand over its shoulder with a magnifying glass and tell it exactly what’s missing.

That last 20% of polish is where the money is made...and where the money is lost. It’s also the part most engineers now skip because "it meets ticket acceptance criteria" or "Claude didn’t think we needed it."

## Closing Thought

The bar shouldn't stay put so we can casually step over it. It's up to us to raise that bar and maintain the same level of craft that we know is possible.

Obsess over the details. Not because you must, but because you may.

...and because it's the only thing standing between you and becoming the cautionary tale in someone else’s post-mortem.


AI makes us fast. Only obsessive attention to detail keeps us employed.

Details Aren’t a Nice-to-Have; They’re the Bare Minimum


In a nutshell, Bookmarklets are JavaScript snippets that you run on any webpage just by clicking a bookmark. I find them to be quite useful so I'll break down why they're great, where they fall short, and how to work around React's built-in security to implement them effectively.

---

## So, What's a Bookmarklet?

A bookmarklet is a bookmark stuffed with JavaScript code instead of a normal URL. Clicking it runs the code immediately on the current page. This lets you easily add custom functionality without installing full browser extensions. But this power isn't without its issues—especially security-wise.

---

## Why Should You Care?

Bookmarklets make you feel like a true hacker, which that alone makes them worth using. Along with that, they are particularly useful for:

- Instantly tweaking pages or automating repetitive tasks
- Quickly testing scripts or adjusting styles
- Handy utilities that run anywhere without needing browser extensions

However, since bookmarklets run arbitrary JavaScript, there's a real security risk if they're mishandled. Plus, React doesn't let you directly set `javascript:` URLs in JSX, as a safety measure against potential XSS attacks.

---

## React Doesn’t Like `javascript:` URLs

React specifically blocks direct assignment of `javascript:` URLs to `href` attributes because of security reasons. Try adding this code to your component:

```html
<a href="javascript:">Bookmarklet</a>
```

And you'll see an error like this:

![Javascript Blocked Error](/img/articles/bookmarklets/javascript-blocked.webp)

The workaround? Set the `href` attribute using a React ref after the component has mounted. That way, React won't complain, and your bookmarklet link will work as expected.

---

## The Solution: React ref

Here's a quick example component to handle bookmarklets with React and TypeScript:

```tsx
import React, { useRef, useEffect, AnchorHTMLAttributes, JSX, PropsWithChildren } from 'react'

type BookmarkletLinkProps = AnchorHTMLAttributes<HTMLAnchorElement> & {
  code: string
}

export function BookmarkletLink({ code, children, ...props }: PropsWithChildren<BookmarkletLinkProps>): JSX.Element {
  const linkRef = useRef<HTMLAnchorElement>(null)

  useEffect(() => {
    if (linkRef.current) {
      // Set the javascript: URL after the component mounts
      linkRef.current.setAttribute('href', code)
    }
  }, [code])

  return (
    <a ref={linkRef} {...props}>
      {children}
    </a>
  )
}
```

### Using the Component

Here's how you'd actually use this in your React app. Say you have a bookmarklet that outlines every element on a page:

```tsx
import React from 'react'
import { BookmarkletLink } from './BookmarkletLink'

const highlightCode = `javascript:(function(){
  document.querySelectorAll('*').forEach(el => {
    el.style.outline = '2px solid red';
  });
})();`

export default function App() {
  return (
    <div>
      <p>Drag the link below to your bookmarks bar:</p>

      <BookmarkletLink code={highlightCode}>Highlight Page Elements</BookmarkletLink>
    </div>
  )
}
```

The JavaScript URL gets set after mounting, bypassing React's security measures.

---

## Pros and Cons

### Why They're Great

- Run them on any website instantly
- Trigged with a quick click
- Great for scripted plugins, custom UI, and debugging

### Downsides to Remember

- You're running arbitrary code
- Might break if a site's structure changes
- Directly embedding `javascript:` URLs isn’t allowed

---

## When Bookmarklets Make Sense

Bookmarklets really shine when you need quick hacks or customizations, especially handy for developers tweaking third-party sites or rapidly testing new scripts. However, if you need a stable, long-term solution, look into browser extensions or directly integrating the functionality into your app.

---

## Wrapping Up

Bookmarklets can seriously level up your productivity for quick tasks and debugging, but React’s safety checks make implementing them slightly tricky. Using refs to set `href` post-mount solves this neatly.

Hope this was helpful! If you’ve got questions or thoughts, hit me up on X [@javascramble](https://x.com/javascramble).


A quick and practical guide to creating bookmarklets in React

Bookmarklets in React


Next.js middleware is great for handling authentication, redirects, and personalization right at the edge. But there’s a cost hidden in that convenience: middleware gets invoked on _every_ matching request. Even requests that you might not expect—which can quickly balloon your invocation count (and your hosting bill) if you're not careful.

## Every Invocation Counts

Obviously, Next.js middleware runs for all the page routes specified in the matcher config. But did you know that each time Next.js prefetches JSON data for your pages ( `/_next/data/.../page.json` ), middleware also gets invoked if your matcher isn't set correctly?

I learned this the hard way—realizing that my middleware invocation counts skyrocketed after adding more `<Link>` components. Each `<Link>` prefetches JSON data behind the scenes, triggering middleware unnecessarily.

---

## The Culprit: JSON Prefetch Requests

Consider a typical middleware matcher configuration:

```js
export const config = {
  matcher: ['/account/:path*'],
}
```

At first glance, this seems harmless—it matches routes like `/account/login`. But it also matches `/_next/data/.../account/login.json`, a route Next.js automatically hits to prefetch data. Every prefetch means another middleware invocation—even if you don't need middleware logic to run on these JSON requests.

This leads to a ton of extra invocations, inflating costs quickly.

## The Fix: Exclude JSON Requests

The good news is the fix is pretty straightforward. Adjust your matcher to explicitly skip JSON requests:

```js
export const config = {
  matcher: ['/account/((?!.*\\.json).*)'],
}
```

Here, the regex `((?!.*\\.json).*)` explicitly filters out JSON prefetch requests. With this tweak, middleware only triggers on actual page loads, significantly cutting down unnecessary invocations.

---

## When Should JSON Requests Run Middleware?

In most cases, skipping middleware on JSON requests is ideal. But there are exceptions:

- If your JSON payload needs personalization or varies by user/session.
- When real-time authentication checks on data-fetching requests are required.

Typically, though, you won’t need middleware running on prefetch JSON calls.

---

## An Optimized Middleware Example

Here's a practical, optimized middleware setup:

```js
export const config = {
  matcher: ['/account/((?!.*\\.json).*)'],
};

export async function middleware(request: NextRequest) {
  // Skip any lingering preflight requests (optional)
  if (request.method === 'OPTIONS') return NextResponse.next();

  ...

  return NextResponse.next();
}
```

With this approach, middleware invocations become targeted, efficient, and less costly.

---

Middleware optimization might seem minor, but the cumulative impact is substantial. By carefully configuring your matchers, you build apps that not only perform better but are also more economical at scale.

Got ideas or questions about middleware optimization? Reach out to me on X [@javascramble](https://x.com/javascramble).


Avoid unnecessary Next.js middleware invocations and keep your hosting bills under control

Stop Overpaying for Next.js Middleware


**We all have a collection of rocks.** Some are pretty, well-shaped, hold fond memories, or come from nice places. Others are rough, jagged fragments, acquired through hardship or misfortune. They vary in size and weight, and each can either anchor us or propel us forward.

We carry these rocks with us everywhere we go. For better or worse, we bring them along because they're all we have. They’re the tangible pieces of our journey, capturing our experiences and shaping our perspectives. Often, we need to pause and look at our collection to remember who we are and where we've come from. Yet, we sometimes forget that we even have a collection, becoming lost and exhausted by the weight they possess.

Over the years, our collection inevitably grows heavier, constrained by the finite space within us. Eventually, we must decide which rocks to keep and which to let go. The lightest and most cherished are to remain with us, as they spark joy and remind us of the goodness in our lives. Others may have lost their luster but still hold meaning—so it's up to us to decide if they're worthy of a spot in our collection. The rest must be left behind, either abandoned where they lie or thrown far, far away.

The heavy rocks have forged our strength; the beautiful ones have brightened our days; the rough ones have honed our resilience; and the ones that have traveled far did so because we, too, have traveled far. In the end, we hope that when we are old, we can lay out our collection, dust it off, and smile—reminded of a life fully lived.


Collecting Rocks


I recently had to query an API for 2 million users and update some data on each of those users. Seems simple enough, but let's break down what's actually going on here. The problem was that I could only query from `/users` in increments of 250, and for each user, another API call to `/users/:user_id/update` needed to be made to update the user information.

### Naive Approach

The easy way to solve this is to query for the 250 users, loop through those users, and send a request to update each user before going to get the next set of 250 users. Only issue here is that this is very time consuming. Even with fast internet and a M1 Mac, I was capping out at around 120 requests per minute, and to get through 2 million users, it would take 277 hours or 11.5 days of constant running. Yikes.

## Crank it with Concurrency

Our computers are surely capable of handling more than one task at a time, so we can leverage that by running the requests concurrently in separate node processes. To help us with this, we're going to employ the use of [BullMQ](https://docs.bullmq.io/), a queueing system built on top of [Redis](https://redis.io/) that will allow us to focus on cranking through our API updates instead of spending hours building out a robust queueing system.

Let's see how that's done...

### Redis Setup

Using BullMQ means we need to have a local (or remote) Redis server running. We just need the server to be running on the same port as BullMQ's queue and worker, so [install Redis](https://redis.io/docs/getting-started/) and toss this into your command prompt:

```shell
$ redis-server --port 5050
```

---

### BullMQ Config

We carry over that port number and tell BullMQ that we want to use a local Redis server with a concurrency factor of 4 (or whatever the API that you'll be blasting can handle). The API I was using had a rate limiter, so the highest I could go to is 4, but I wouldn't use more than the number of cores that your CPU has. A higher number just means more jobs are allowed to be processed in parallel.

```TypeScript
const BULL_CONFIG = {
  connection: { port: 5050, host: 'localhost' },
  concurrency: 4,
}
```

---

### Create the Queue

To initialize our queue, we need an identifier that will be used as a key prefix in the Redis store and the config to connect to Redis. Just like that, the queue is now hooked up and ready to store jobs.

```TypeScript
const queue = new Queue('users-queue', BULL_CONFIG)
```

---

### Start Filling that Queue

We want to fetch the users immediately after starting this script, so we use a recursive IIFY to go through all the paginated pages of users and fetch all 2 million users. We simply loop through all 250 users returned from each request and add a job to the queue using `queue.add()`. We give the job a name based on the type of job that it is, pass it the data that we want the Worker to receive, and use whatever job [options](https://api.docs.bullmq.io/interfaces/v4.BaseJobOptions.html) fit your needs.

```TypeScript
;(async function fetchUsers(pageNum: number = 0) {
  const response = await fetch(`/users?page=${pageNum}`)
  const data = await response.json()
  const users = data.users as User[]

  for (const user of users) {
    // Add each user to the queue as a Job
    await queue.add('update-user', user, { removeOnComplete: true })
  }

  // Check if there are more pages
  if (data.nextPage) await fetchUsers(data.nextPage)
})()
```

---

### Start the Worker

As the jobs continue to be added to the queue, it's time to get working on those jobs. We instantiate a worker with the same identifier of the queue that we used before (`'users-queue'`), giving it a callback function to handle the job when it gets picked up, and passing the same config that we gave the queue so that it's pointed at the correct Redis store.

The callback function we pass the worker accepts a job, which holds the data that we passed it from `queue.add()` (our user), and makes the appropriate fetch request to update that user. With that in place, our worker will handle the job processing (4 at a time given our concurrency setting) and categorizing (with statuses of 'waiting', 'active', 'completed', and 'failed') based on how our fetch request performs.

```TypeScript
const worker = new Worker<User, void>(
  'users-queue',
  async (job: { data: User }) => await updateUser(job.data),
  BULL_CONFIG
)

async function updateUser(user: User) {
  const response = await fetch(`/users/${user.id}/update`)
  const data = await response.json()
  return data.success
}
```

---

### Listen to Worker Completion

We don't need it for our example, but often times there is a need to do something with the job data after the job has been completed, so the worker allows us to setup an event listener for the completed event like so:

```TypeScript
worker.on('completed', async (job: { data: User }) => {
  console.log(`Job ${job.data.id} Completed!`)
})
```

---

## Put it all together

Fully assembled, our script looks like this:

```TypeScript
import { Queue, Worker } from 'bullmq'

const BULL_CONFIG = {
  connection: { port: 5050, host: 'localhost' },
  concurrency: 4,
}

const QUEUE_NAME = 'users-queue'
const JOB_NAME = 'update-user'

type User = {
  id: string
  info: any
}

const queue = new Queue(QUEUE_NAME, BULL_CONFIG)

const worker = new Worker<User, void>(
  QUEUE_NAME,
  async (job: { data: User }) => await updateUser(job.data),
  BULL_CONFIG
)

// Worker callback to update users
async function updateUser(user: User) {
  const response = await fetch(`/users/${user.id}/update`)
  const data = await response.json()
  return data.success
}

// Fetch users and add them to the queue
;(async function fetchUsers(pageNum: number = 0) {
  const response = await fetch(`/users?page=${pageNum}`)
  const data = await response.json()
  const users = data.users as User[]

  for (const user of users) {
    await queue.add(JOB_NAME, user, { removeOnComplete: true })
  }

  if (data.nextPage) await fetchUsers(data.nextPage)
})()

// Listen for job completion
worker.on('completed', async (job: { data: User }) => {
  console.log(`Job ${job.data.id} Completed!`)
})
```

---

## Results

With this setup, the time to update all 2 million users was brought from 11 days down to several hours. Saving energy and time. I hope you learned a thing or two and if you found this article interesting, feel free to hit me up on [GitHub](https://github.com/ChristianAnagnostou) or [X](https://x.com/javascramble). Cheers!


Scaling async tasks with concurrency is scary fast

Queueing with BullMQ and Redis


Zooming and panning: to two common user interactions that allow users to manipulate and navigate content on a webpage.

Zooming involves changing the scale or magnification level of the content, making it appear larger or smaller. Zooming can be implemented using CSS properties like `transform: scale()` and some added JavaScript to modify the size and layout of the elements dynamically.

Panning involves moving the visible area of content within a fixed viewport. This allows users to explore content that exceeds the available space by dragging or swiping in any direction. Typically, panning is implemented by utilizing `transform: translate(x,y)` with JavaScript to capture user input and adjust the content's position within the container.

---

![Window Drawing](/img/articles/zooming-scaling/window-drawing.webp)

---

The image above shows a zoomed out and panned canvas. When initially opening the canvas, the whole screen would be covered with the blue diagonal lines. After zooming out and panning towards the top left, we end up with the layout in the image.

The image also shows the cursor position and the x and y values used to get its position. Those variables can be used to zoom into the location of the cursor. We'll implement that later.

Using the CSS property `transform` with its `scale` and `translate` values, zooming and panning can be combined into one CSS line with two dynamic variables.

```JavaScript
let scale = 1

const zoomPos = { x: 0, y: 0 }

const transform = `scale(${scale}) translate(${zoomPos.x}px, ${zoomPos.y}px)`
```

---

## Panning

To pan, all we need to do is change the `zoomPos` values based on how far the mouse moves as well as the direction in which it moved. Do this by listening for the `mousedown`, `mousemove` and `mouseup` events. Mouse down and mouse up only toggle a variable to let the mouse move event know that the mouse is pressed while moving - dragging, so the bulk of the work is done by mouse move.

To move the initial window, start by attempting to use a stored value, `prevMouseMove`, which at first doesn't exist, so default to the current mouse position. Subtract the first non-null value of those two from the current mouse position and the result is the distance that the mouse moved. Finally, add that to the current zoom position.

```javascript
let prevMouseMove = null

if (mouseDown) {
  zoomPos.x += clientX - (prevMouseMove?.clientX || clientX)
  zoomPos.y += clientY - (prevMouseMove?.clientY || clientY)
}

prevMouseMove = { clientX, clientY }
```

---

## Zooming

The intended user experience for zooming depends on the application, but I find it nice when you zoom in and the window hones in on the location of the cursor, so we'll implement that approach. To do that, both scale and transform need to be updated since the window must move in relation to the cursor while zooming in/out.

### Calculating Scale

The steps to calculate the scale are:

1. Set some config variables
2. Determine the zoom direction (in or out)
3. Adjust the scale based on zoom direction

#### Config Vars

The config variables allow us to control the behaivor of the zooming:

```javascript
const maxScale = 4 // Max zoom (400%)
const minScale = 0.1 // Min zoom (10%)
const zoomFactor = 0.05 // Zoom speed (higher is faster)
```

#### Zoom Direction

Typically, zooming is handled by the scroll of the mouse wheel, so we listen for the `wheel` event on the `window`. The window wheel event contains information about the direction of the wheel (or trackpad) and, depending on the browser, the information varies in output. The safest way I've found to capture wheel direction is by clamping the scroll between -1 and 1 so that the positive one is zooming in and the negative one is zooming out.

```javascript
const delta = e.wheelDelta || e.originalEvent.detail // Chrome || Firefox

const clampedDelta = Math.max(-1, Math.min(1, d))
```

#### Scale

To calculate the new scale, we use our current scale multiplied by the zoom factor to get the next _step_ of zoom. We then multiply that by the zoom direction (-/+). Finally, we add that to the current scale and clamp the result between the min and max scale config variables.

```JavaScript
const scale = scale + (delta * zoomFactor * scale)

const clampedScale = Math.max(minScale, Math.min(maxScale, scale))
```

---

### Calculating Transform

Now that the scale has been adjusted, we can use it to modify the values of zoom position x and y. We need to first get the distance between the cursor and the center of the window. Then that same distance needs to be removed from the previous zoom position and scaled down to a px value relative to the initial window.

If that was a lot, picture it like this...

Imagine being zoomed out really far with the initial window as a small square in the center of the screen. If you were to click at the top left of the screen it may be just a few hundred pixels away from the initial window, but if you were to zoom back in and try to click the same spot on the canvas, it would be thousands of pixels up and to the left. That's what screenX and screenY represent.

The next step would be to update the scale value described in the section above. With scale being updated, move the window towards the location of the cursor keeping the relative distance from the center of the screen constant.

```javascript
const zoomPointX = e.clientX - window.innerWidth / 2
const zoomPointY = e.clientY - window.innerHeight / 2

const screenX = (zoomPointX - zoomPos.x) / prevScale
const screenY = (zoomPointY - zoomPos.y) / prevScale

... // update scale value

zoomPos.x = -screenX * scale + zoomPointX
zoomPos.y = -screenY * scale + zoomPointY
```

Note: `prevScale` doesn't refer to a separate variable, it's just showing that they will be different values.

---

## All Together

Combining the zoom scale and transform into one event callback looks like the code below. There are several similar lines that could be extracted to auxiliary functions, but I'll leave that to you for the sake of keeping actions contained.

```typescript
let scale = 1
const zoomPos = { x: 0, y: 0 }

const maxScale = 4 // Max zoom (400%)
const minScale = 0.1 // Min zoom (10%)
const zoomFactor = 0.05 // Zoom speed (higher is faster)

let prevMouseMove = null

canvas.addEventListener('mousedown', ({ clientX, clientY }: MouseEvent) => {
  prevMouseMove = { clientX, clientY }
})

canvas.addEventListener('mouseup', () => {
  prevMouseMove = null
})

canvas.addEventListener('mousemove', ({ clientX, clientY }: MouseEvent) => {
  if (prevMouseMove) {
    // Pan canvas by distance from prevMouseMove
    zoomPos.x += clientX - (prevMouseMove?.clientX || clientX)
    zoomPos.y += clientY - (prevMouseMove?.clientY || clientY)
  }

  // Update to track next distance change
  prevMouseMove = { clientX, clientY }
})

window.addEventListener('wheel', (e: Event) => {
  const zoomPointX = e.clientX - window.innerWidth / 2
  const zoomPointY = e.clientY - window.innerHeight / 2

  const screenX = (zoomPointX - zoomPos.x) / scale
  const screenY = (zoomPointY - zoomPos.y) / scale

  // Determine if zooming in or out
  const d = e.wheelDelta || e.originalEvent.detail // Chrome || Firefox
  const delta = Math.max(-1, Math.min(1, d)) // Cap the delta to [-1,1] for cross browser consistency

  const updatedScale = scale + delta * zoomFactor * scale
  scale = Math.max(minScale, Math.min(maxScale, updatedScale))

  zoomPos.x = -screenX * delta + zoomPointX
  zoomPos.y = -screenY * delta + zoomPointY
})
```

## Wrap Up Notes

The important thing to remember about zooming is that there are two types of pixel _units_: canvas and screen. Converting between the two is often needed when building on a surface that scales. Knowing when to use each unit is key to understanding the relationship between the screen and the canvas.

Below I've added my implementations to convert from canvas to screen and vice versa. This comes from an open source project of mine called [Qwikdraw](https://www.qwikdraw.app/) where you can draw shapes and add images to a canvas and orient, rotate, and modify them.

```typescript
const screenToCanvas = $((screenX: number, screenY: number) => {
  return {
    canvasX: (screenX - zoomPos.x - (window.innerWidth / 2) * (1 - scale)) / scale,
    canvasY: (screenY - zoomPos.y - (window.innerHeight / 2) * (1 - scale)) / scale,
  }
})

const canvasToScreen = $((canvasX: number, canvasY: number) => {
  return {
    screenX: (canvasX - zoomPos.x) / scale,
    screenY: (canvasY - zoomPos.y) / scale,
  }
})
```

---

Hope this article was helpful to you! If it was, let me know on X [@javascramble](https://x.com/javascramble).


Turn your browser window into a 2D canvas that you can explore

Zooming & Panning


There comes a time in every frontend dev's career when they will need to render large amounts of data in list form. The simple approach is to loop through all items and create the HTML for each. That can be thousands of elements when you have a lot of data, so it's better to show only a subset of those items through a process called virtualization. Using a virtual list allows you to render the data without making your site feel laggy and resource intensive. The goal is to render only the visible portion of the list of items and dynamically swap items in and out of the DOM as the user scrolls. Doing so allows for a more efficient rendering process and better user experience.

---

### How to make one

To operate this implementation of a virtual list, there are a few limitations you should know. Each element in the list needs to be the same height and the height of the virtual list needs to be defined outside of the virtual list component (we'll go over a nifty trick for this at the end). With that in mind, here are the variables that need to be passed into the component:

### `numItems`

Number of elements that are in the list

### `itemHeight`

Height of the element in pixels

### `windowHeight`

Height of the wrapping element in pixels

### `renderItem({ index, style })`

Function that accepts the element index and style and returns a JSX element

### `overscan`

Number of elements above or below the screen that will pre-render (helps when scrolling really fast)

---

### Prop Types

With those parameters, we're able to construct our virtual list.
If we were to write them as TypeScript props for a React virtual list component, it would look something like this:

```tsx
type Props = {
  numItems: number
  itemHeight: number
  windowHeight: number
  renderItem: ({ index, style }: { index: number; style: React.CSSProperties }) => JSX.Element
  overscan?: number
}
```

---

### Internal State

The virtual list itself only needs to keep track of one variable: [scrollTop](https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop). This is the number of pixels that an element's content is scrolled vertically. The initial value is 0 and would look like this:

```ts
const [scrollTop, setScrollTop] = useState(0)
```

---

### Calculate Starting and Ending Elements

The next step is to calculate the starting and ending indexes for the elements that should render.
The starting index is found by taking the scroll top position and dividing it by the height of the elements to get the index of the element at the top of the scroll container. From there all you do is subtract the overscan variable and you have the starting index to render. To get the ending index you add the scroll top position to the height of the scroll container and divide that by the height of the elements. Add the overscan this time and boom, there's your end index.

```ts
const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan)

const endIndex = Math.min(numItems - 1, Math.floor((scrollTop + windowHeight) / itemHeight) + overscan)
```

---

### Create List of Elements for Render

With our newly created index variables, we now know which range of elements to render. To do that, we can use a simple for loop and call the `renderItem` function being passed into the virtual list component. We make each element positioned absolutely and calculate its top position by its index in the list. This should return a JSX element and we add that to the items array to prep them for rendering.

```tsx
const items: JSX.Element[] = []

for (let i = startIndex; i <= endIndex; i++) {
  items.push(
    renderItem({
      index: i,
      style: { position: 'absolute', top: `${i * itemHeight}px`, width: '100%' },
    })
  )
}
```

---

### Render the elements

The JSX markup for the virtual list is quite minimal. You need an outer scrolling element and an inner element whose height is calculated by the total number of list elements multiplied by the height of the elements. The array of elements being rendered can be added directly into the markup as it's just an array of JSX elements.

```ts
const innerHeight = numItems * itemHeight
```

```tsx
<div className="scroll" style={{ overflowY: 'scroll', width: '100%' }} onScroll={onScroll}>
  <div className="inner" style={{ position: 'relative', height: `${innerHeight}px` }}>
    {items}
  </div>
</div>
```

You might have noticed that there is an `onScroll` property on the outer scrolling element. This is to track the scrollTop of the outer element and update the scrollTop state.

```ts
const onScroll = ({ currentTarget }) => setScrollTop(currentTarget.scrollTop)
```

---

### Fully Assembled

When we put all those steps together, you get a reusable component that will help you render looooong lists of data. There are limitations with this simple setup but you can modify it to fit your needs. Here is the code to do so:

```tsx
import React, { useState } from 'react'

type Props = {
  numItems: number
  itemHeight: number
  windowHeight: number
  renderItem: ({ index, style }: { index: number; style: React.CSSProperties }) => JSX.Element
  overscan?: number
}

const VirtualList = (props: Props) => {
  const { numItems, itemHeight, renderItem, windowHeight, overscan = 3 } = props

  const [scrollTop, setScrollTop] = useState(0)

  const innerHeight = numItems * itemHeight
  const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan)
  const endIndex = Math.min(numItems - 1, Math.floor((scrollTop + windowHeight) / itemHeight) + overscan)

  const items: JSX.Element[] = []

  for (let i = startIndex; i <= endIndex; i++) {
    items.push(
      renderItem({
        index: i,
        style: { position: 'absolute', top: `${i * itemHeight}px`, width: '100%' },
      })
    )
  }

  const onScroll = ({ currentTarget }) => setScrollTop(currentTarget.scrollTop)

  return (
    <div className="scroll" style={{ overflowY: 'scroll', width: '100%' }} onScroll={onScroll}>
      <div className="inner" style={{ position: 'relative', height: `${innerHeight}px` }}>
        {items}
      </div>
    </div>
  )
}

export default VirtualList
```

---

### Using the Virtual List

Since the virtual list needs its height defined, you can wrap it in an element with a React ref and use the clientHeight of the ref to make the height responsive to whatever the height is of its wrapping element.

The element being rendered is found by referencing the index in the list of all data and the styles are added inline on the list element itself.

```tsx
<div ref={virtualListContainer}>
  <VirtualList
    numItems={allData.length}
    itemHeight={30}
    windowHeight={virtualListContainer.current?.clientHeight || 0}
    renderItem={({ index, style }) => (
      <div key={allData[index].id} style={style}>
        {allData[index].title}
      </div>
    )}
  />
</div>
```

---

Hope you enjoyed reading through this article. If you happen to need a virtual list for Qwik, [here's my virtual list implementation](https://github.com/christiananagnostou/jukebox/blob/master/src/components/Shared/VirtualList.tsx) - it includes a few other added features that make for a nice utility component.


Learn how to build a virtual list in in React

Virtual Lists are Beautiful


In 1868, a man by the name of [Christopher Sholes](https://en.wikipedia.org/wiki/Christopher_Latham_Sholes) was sitting at his desk with this sequence of letters and numbers in front of him:

```text
 3 5 7 9 N O P Q R S T U V W X Y Z
2 4 6 8 . A B C D E F G H I J K L M
```

It was the keyboard of the first ever typewriter.
The letters were staggered resembling a piano, had black keys and white keys, and was laid out in two long rows. There were no keys for 0 or 1 as the letters O and I were deemed sufficient.

Eventually, after years of experimenting with different layouts to make the keys jam less, Sholes ended up with this layout:

```text
 1 2 3 4 5 6 7 8 9 0 - =
Q W E R T Y U I O P [ ] \
 A S D F G H J K L ; '
  Z X C V B N M , . /
```

Being a newspaper publisher, Sholes would spend hours typing up new documents, so jamming the typewriter usually meant smudges or restarting altogether. His fix was simple: rearrange the keys, learn the new map, stop the jams.

I sometimes wonder what would have happened if he had tried vertical rows or clusters by hand position; our muscle memory and shortcuts might feel entirely different.

We can use the same mindset. Our keyboards no longer jam, but our work does, mostly when we leave the keys for menus, mice, and wandering cursors. Seeing the keyboard as a map you can master keeps the work smooth.

### A few to try this week

- `Cmd/Ctrl + P` in VS Code to jump to files; add `:line` to hop inside them.
- `Opt/Alt + ←/→` to move by words, `Cmd/Ctrl + ←/→` to line ends; add `Shift` to select.
- `Cmd/Win + ←/→` (or your tiling shortcut) to snap windows; `Cmd/Ctrl + Tab` to flip tabs.
- `Cmd/Ctrl + L` in the browser to focus the address bar; type, Enter, back to work.
- Remap caps lock to Ctrl/Esc if you use Vim or Terminal. It's a tiny change that feels like a new layout.

### Make it stick

Pick three shortcuts, keep them on a sticky note near your monitor, and use them until they're automatic. Next week, add three more. It's the same practice Sholes used: adjust the layout you rely on, then train your hands to follow the new pattern. Sholes would be proud.

Some shortcuts and references I use often:

- [Vim](https://gist.github.com/tuxfight3r/0dca25825d9f2608714b)
- [VSCode](https://code.visualstudio.com/docs/getstarted/keybindings)
- [Vim for VSCode](https://marketplace.visualstudio.com/items?itemName=vscodevim.vim)
- [MacOS](https://support.apple.com/en-us/HT201236)
- [Chrome](https://support.google.com/chrome/answer/157179?hl=en&co=GENIE.Platform%3DDesktop#zippy=)
- [Music](https://support.apple.com/guide/music/keyboard-shortcuts-mus1019/mac)
- [Rectangle](https://github.com/rxhanson/Rectangle)


Mastering the keyboard is an invaluable skill that saves the most valuable currency...time.

Wield the Keyboard


Adventures can only start when the first step is taken.

The mark of a good developer is the ablity to share their learnings with others. It's 2023 and to no one's surprise, sharing online is the broadest platform one can share with.

So here we are, starting a blog, presenting my thoughts, works, learnings, and opinions with any who dare to endulge.

Enjoy


Christian Anagnostou

Photos

Articles

Fitness