stopcock | Blog

How pipe() fuses your loops

Mon, 06 Apr 2026 00:00:00 GMT

You’ve probably written something like this:

const result = users
  .filter(u => u.active)
  .map(u => u.name)
  .slice(0, 10)

Three passes over the array. Two intermediate arrays that get thrown away immediately. If users has 100K entries, you’re doing 100K + 50K + 50K iterations to get 10 names.

stopcock’s pipe does this instead:

import { pipe, A } from '@stopcock/fp'

const result = pipe(
  users,
  A.filter(u => u.active),
  A.map(u => u.name),
  A.take(10),
)

One loop. No intermediate arrays. It stops after finding 10 matches.

What actually happens

Every array function in stopcock carries a hidden _op tag. When you call A.filter(fn), the returned function has _op: 2 (the opcode for filter). A.map(fn) has _op: 1. A.take(10) has _op: 3.

When pipe receives its arguments, it checks each function for this tag:

const _hasOp = (fn: any): boolean =>
  typeof fn._op === 'number' && fn._op > 0

If consecutive functions are tagged, pipe doesn’t call them one by one. It hands the whole sequence to the fusion engine, which compiles them into a single loop.

The JIT compiler

The fusion engine generates a specialized for loop at runtime using new Function(). For the filter/map/take example above, it produces something like:

// Simplified version of what the JIT emits
function fused(src, fns) {
  var f0 = fns[0] // filter predicate
  var f1 = fns[1] // map transform
  var c2 = 0      // take counter
  var r = []
  for (var i = 0; i < src.length; i++) {
    var v = src[i]
    if (!f0(v)) continue      // filter
    v = f1(v)                 // map
    r.push(v); if (++c2 >= 10) break  // take(10)
  }
  return r
}

One loop. Filter skips with continue. Take breaks with break. The generated code is cached by opcode pattern, so the same chain shape only compiles once.

Callback inlining

It goes further. If your callback is a simple arrow function like x => x * 2, the engine parses the function’s toString() output, validates it’s safe (no side effects, no closed-over variables), and inlines the expression directly into the generated loop body.

Instead of v = f1(v), the generated code becomes v = v * 2. No function call overhead at all.

The safety checks are strict. The engine rejects anything with new, delete, throw, await, import, or eval. It rejects any identifier that isn’t the parameter name or a known global like Math or Array. If the callback can’t be inlined, it falls back to a normal function call. Nothing breaks, you just don’t get the extra speed.

What fuses and what doesn’t

Operations that can run item-by-item fuse together: filter, map, flatMap, take, drop, takeWhile, dropWhile.

Terminal operations like reduce, find, every, some, and count also fuse. They become the final step of the loop instead of a separate pass.

Operations that need the full array don’t fuse: sort, reverse, groupBy, uniq. These force the preceding fused segment to materialize its result first. Then a new segment can start after them.

pipe(
  data,
  A.filter(x => x > 3),       // ─┐ fused segment 1
  A.map(x => x * 2),          // ─┘ materializes here
  A.sortBy((a, b) => a - b),  // runs on materialized array
  A.take(3),                  // segment 2 (take on sorted result)
)

There’s one exception. sort followed immediately by take(k) gets a special optimization: quickselect. Instead of sorting the whole array and slicing, it partitions to find just the top k elements and only sorts those. O(n + k log k) instead of O(n log n).

When it doesn’t matter

For small arrays (under ~100 items), fusion doesn’t buy you much. The overhead of native method calls is negligible at that scale, and V8 is very good at optimizing simple chains.

Fusion pays off when:

Your arrays are large (1K+ items)
You have early-exit operations like take or find
You’re chaining 3+ operations
You’re in a hot path that runs frequently

The filter/map/take pattern on 100K items runs at ~4M ops/s with fusion vs ~700 ops/s with native chaining. That’s not a typo. Most of the gain comes from take(10) breaking out of the loop after 10 results instead of processing all 100K items first.

The fallback

If new Function() isn’t available (CSP restrictions, some edge runtimes), the engine falls back to an interpreted loop that does the same thing without code generation. Same fusion, same early exits, just without the inlining optimizations.

And if none of your functions have opcodes (plain functions, not stopcock’s array ops), pipe just calls them left to right like you’d expect. Zero overhead in that path.

Zustand without the spread

Mon, 06 Apr 2026 00:00:00 GMT

Zustand is probably the best state management library for React. Tiny API, no boilerplate, works how you’d expect. But it has the same problem as every immutable state solution: nested updates are ugly.

Here’s a store for a basic e-commerce app:

type State = {
  user: {
    name: string
    address: {
      street: string
      city: string
      postcode: string
    }
  }
  cart: {
    items: CartItem[]
    discount: number | null
  }
  ui: {
    sidebarOpen: boolean
    theme: 'light' | 'dark'
  }
}

Now update the user’s city:

setCity: (city) => set(state => ({
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city,
    },
  },
}))

Three levels of spread for one field. And it gets worse. Every new action that touches nested state repeats the same pattern. You end up with a store file that’s 80% spread operators.

Lenses fix this

A lens is a pair of functions: one to read a value from a structure, one to write it back immutably. You define it once and reuse it everywhere.

import { path, set, over, view } from '@stopcock/fp'

const city = path<State, 'user', 'address', 'city'>('user', 'address', 'city')

That city lens knows how to reach into state.user.address.city and how to produce a new state with that value changed. All the spreading happens inside the lens. You never write it again.

setCity: (c) => set(state => lensSet(city, c, state)),

One line. Any depth.

Setting up the store

Here’s a full Zustand store using optics. The pattern is simple: define your lenses outside the store, use them inside your actions.

import { create } from 'zustand'
import {
  prop, path, composeLens, view as lensView,
  set as lensSet, over as lensOver,
  each, filtered, modify,
} from '@stopcock/fp'

// Lenses. define once, use everywhere
const user = prop<State, 'user'>('user')
const city = path<State, 'user', 'address', 'city'>('user', 'address', 'city')
const cartItems = path<State, 'cart', 'items'>('cart', 'items')
const discount = path<State, 'cart', 'discount'>('cart', 'discount')
const theme = path<State, 'ui', 'theme'>('ui', 'theme')
const sidebar = path<State, 'ui', 'sidebarOpen'>('ui', 'sidebarOpen')

const useStore = create<State & Actions>((set, get) => ({
  user: {
    name: 'Alice',
    address: { street: '123 Main St', city: 'Portland', postcode: '97201' },
  },
  cart: { items: [], discount: null },
  ui: { sidebarOpen: false, theme: 'light' },

  // Simple field updates. one line each
  setCity: (c) => set(s => lensSet(s, city, c)),
  toggleSidebar: () => set(s => lensOver(s, sidebar, open => !open)),
  setTheme: (t) => set(s => lensSet(s, theme, t)),
  applyDiscount: (d) => set(s => lensSet(s, discount, d)),
}))

Compare that to the spread version. Each action is one line instead of a nested object literal. And when your state shape changes, you update the lens definition, not every action that touches that path.

Real use cases

Cart operations

Cart state is where spread hell really kicks in. You’re updating items inside an array inside an object. With traversals, you can target items by condition.

import { each, filtered, modify } from '@stopcock/fp'

// Bump quantity for a specific item
const increaseQuantity = (id: string) => set(s => {
  const items = lensView(s, cartItems)
  return lensSet(s, cartItems,
    items.map(item =>
      item.id === id ? { ...item, quantity: item.quantity + 1 } : item
    )
  )
})

// Mark all out-of-stock items
const outOfStock = filtered<CartItem>(item => item.stock === 0)

const markOutOfStock = () => set(s => {
  const items = lensView(s, cartItems)
  return lensSet(s, cartItems,
    modify(items, outOfStock, item => ({ ...item, disabled: true }))
  )
})

The filtered traversal finds all matching items and applies the update. You’re not writing .map with a ternary every time.

Form state

Multi-step forms tend to have deeply nested state. Each section has its own fields and validation. Without lenses, updating a single field means spreading through every layer.

type FormState = {
  steps: {
    personal: { name: string; email: string }
    shipping: { address: Address; sameAsBilling: boolean }
    payment: { method: 'card' | 'paypal'; cardNumber: string | null }
  }
  currentStep: number
  errors: Record<string, string[]>
}

const shippingAddress = path<FormState, 'steps', 'shipping', 'address'>(
  'steps', 'shipping', 'address'
)
const paymentMethod = path<FormState, 'steps', 'payment', 'method'>(
  'steps', 'payment', 'method'
)
const currentStep = prop<FormState, 'currentStep'>('currentStep')

// Each action reads clearly
const setShippingAddress = (addr: Address) =>
  set(s => lensSet(s, shippingAddress, addr))

const nextStep = () =>
  set(s => lensOver(s, currentStep, step => step + 1))

const selectPaypal = () =>
  set(s => lensSet(s, paymentMethod, 'paypal'))

Dashboard filters

Dashboards accumulate state. Filters, selected rows, sort order, pagination, collapsed panels. Each one is a nested path that you’re constantly reading and writing.

type DashboardState = {
  filters: {
    dateRange: { start: Date; end: Date }
    status: ('active' | 'archived' | 'draft')[]
    search: string
  }
  table: {
    sortBy: string
    sortOrder: 'asc' | 'desc'
    page: number
    selected: Set<string>
  }
}

const dateRange = path<DashboardState, 'filters', 'dateRange'>('filters', 'dateRange')
const statusFilter = path<DashboardState, 'filters', 'status'>('filters', 'status')
const search = path<DashboardState, 'filters', 'search'>('filters', 'search')
const sortBy = path<DashboardState, 'table', 'sortBy'>('table', 'sortBy')
const sortOrder = path<DashboardState, 'table', 'sortOrder'>('table', 'sortOrder')
const page = path<DashboardState, 'table', 'page'>('table', 'page')
const selected = path<DashboardState, 'table', 'selected'>('table', 'selected')

// Toggle sort direction
const toggleSort = (column: string) => set(s => {
  const current = lensView(s, sortBy)
  if (current === column) {
    return lensOver(s, sortOrder, o => o === 'asc' ? 'desc' : 'asc')
  }
  return lensSet(lensSet(s, sortBy, column), sortOrder, 'asc')
})

// Clear all filters at once
const clearFilters = () => set(s =>
  lensSet(
    lensSet(
      lensSet(s, search, ''),
      statusFilter, [],
    ),
    dateRange, { start: defaultStart, end: defaultEnd },
  )
)

Chaining lensSet calls reads top to bottom. Each one returns a new state that feeds into the next. No intermediate variables, no spreading.

When you don’t need this

If your state is flat, you don’t need lenses. Zustand already handles { count: 0, increment: () => set(s => ({ count: s.count + 1 })) } perfectly. Don’t add abstraction where there’s no problem.

Lenses pay off when:

State is 3+ levels deep
Multiple actions touch the same nested paths
You’re tired of reading and reviewing spread sandwiches
You want to test state updates independently of the store

That last point matters more than it seems. A lens is just a value. You can unit test it without Zustand, pass it around, compose it with other lenses. Try doing that with a spread expression.

Beyond lenses

Everything in this post comes from @stopcock/fp. Lenses cover the common case of reaching into nested objects, but the same package also has prisms (for values that might not exist, like Option or Result), traversals (for updating multiple values at once), and cross-optic composition. If you’re just doing simple nested updates in Zustand, lenses and path are enough. Reach for traversals when you need filtered batch updates, or prisms when you’re chaining through optional state.