Transducers, functors & monads

Plain words first

This lesson uses a simple rule: do not learn the word first. Watch the working JavaScript, then name the pattern. The ideas sound academic, but they answer everyday questions: can we avoid extra arrays, keep null checks tidy, return validation errors without throwing, and model a stream of events?

You will see the same old tools from map, filter & reduce, pure functions, optional chaining, promise chaining, and events. Composition & pipelines is being built in this same module, so we will point to that upcoming idea without depending on its route yet.

Start with familiar code. Each native map returns a new array. Each native filter returns a new array. The counters show how many callbacks ran; the logged doubled and large values make the intermediate arrays visible.

1const numbers = [1, 2, 3, 4, 5];2 3let mapCalls = 0;4let filterCalls = 0;5let labelCalls = 0;6 7const doubled = numbers.map((number) => {8  mapCalls += 1;9  return number * 2;10});11 12const large = doubled.filter((number) => {13  filterCalls += 1;14  return number > 5;15});16 17const labels = large.map((number) => {18  labelCalls += 1;19  return "#" + number;20});21 22console.log(labels.join(", "));23console.log("intermediate arrays:", doubled.join(" "), "|", large.join(" "));24console.log("callback calls:", mapCalls + filterCalls + labelCalls);

That style is readable and usually the right first choice. When a pipeline is huge or repeated in a hot path, you can fuse the steps. A transducer is just a function that takes a reducer and returns a new reducer. Here mapping(fn) and filtering(test) are reducer transformers.

1const numbers = [1, 2, 3, 4, 5];Run2 3const mapping = (project) => (reducer) => (list, value) =>4  reducer(list, project(value));5const filtering = (keep) => (reducer) => (list, value) =>6  keep(value) ? reducer(list, value) : list;7const compose = (...fns) => (value) =>8  fns.reduceRight((next, fn) => fn(next), value);9 10const xform = compose(11  mapping((number) => number * 2),12  filtering((number) => number > 5),13  mapping((number) => "#" + number),14);15let visits = 0;16const append = (list, value) => {17  list.push(value);18  return list;19};20const reducer = xform(append);21const result = numbers.reduce((list, value) => {22  visits += 1;23  return reducer(list, value);24}, []);25console.log(result.join(", "));26console.log("reduce visits:", visits);

Fusion is not a moral victory over arrays; it is a trade-off. Use it when the saved work is worth the new vocabulary. Modern JavaScript also has iterator helpers arriving as a built-in lazy alternative, with shapes like Iterator.from(values).map(...).filter(...). Check your target browsers before relying on them in production.

You already know one functor: Array. [1, 2, 3].map(fn) changes each value but keeps the Array shape. A tiny Box makes the same idea small enough to inspect. The two laws are not mystical; they protect refactors.

1const Box = (value) => ({2  map(fn) {3    return Box(fn(value));4  },5  valueOf() {6    return value;7  },8  toString() {9    return `Box(${value})`;10  },11});12 13const sameBox = (left, right) => Object.is(left.valueOf(), right.valueOf());14const id = (value) => value;15const compose = (after, before) => (value) => after(before(value));16const double = (number) => number * 2;17const increment = (number) => number + 1;18 19console.log([1, 2, 3].map(id).join(","));20console.log(sameBox(Box(7).map(id), Box(7)));21console.log(sameBox(22  Box(7).map(compose(double, increment)),23  Box(7).map(increment).map(double),24));

1. Identity law: mapping (value) => value should not change the container. The Array and Box checks both keep the same value.
2. Composition law: mapping a composed function once should match mapping the first function and then the second function. The last true proves the two Box paths agree.

A Maybe has two cases: Just(value) and Nothing. The code below treats null and undefined as Nothing. Its map method runs only while a real value is present.

1const Maybe = {2  fromNullable(value) {3    return value == null ? Nothing() : Just(value);4  },5};6function Just(value) {7  return {8    map(fn) { return Maybe.fromNullable(fn(value)); },9    chain(fn) { return fn(value); },10    withDefault() { return value; },11    toString() { return `Just(${value})`; },12  };13}14function Nothing() {15  return {16    map() { return Nothing(); },17    chain() { return Nothing(); },18    withDefault(fallback) { return fallback; },19    toString() { return "Nothing"; },20  };21}22const users = {Run23  ada: { profile: { email: "ada@example.com" } },24  lin: {},25};26const key = "lin";27const label = Maybe.fromNullable(users[key])28  .map((user) => user.profile)29  .map((profile) => profile.email)30  .withDefault("No email");31console.log(label);

Be honest about plain JavaScript. For one property path, optional chaining is simpler:

1const user = {};2console.log(user.profile?.email ?? "No email");

Maybe becomes more interesting when you want one shared map/chain shape across many small functions. Either, often called Result, is similar but stores a useful error message instead of only “nothing.”

1const Ok = (value) => ({2  map(fn) { return Ok(fn(value)); },3  chain(fn) { return fn(value); },4  match(arms) { return arms.ok(value); },5});6const Err = (message) => ({7  map() { return Err(message); },8  chain() { return Err(message); },9  match(arms) { return arms.err(message); },10});11 12function validateSignup(form) {13  if (!form.email.includes("@")) return Err("Email needs @");14  if (form.password.length < 8) return Err("Password too short");15  return Ok({ email: form.email.toLowerCase() });16}17 18const good = validateSignup({ email: "ADA@EXAMPLE.COM", password: "correct horse" });19const bad = validateSignup({ email: "ada", password: "short" });20 21console.log(good.map((data) => data.email).match({22  ok: (email) => "ok: " + email,23  err: (message) => "error: " + message,24}));25console.log(bad.map((data) => data.email).match({26  ok: (email) => "ok: " + email,27  err: (message) => "error: " + message,28}));

Exceptions are still right for truly exceptional failures. Result is handy when validation failure is expected UI data: show the message, keep the page alive, and avoid wrapping every normal branch in try/catch.

A monad is not “a scary functional thing.” In this lesson, it means: a container has a method for callbacks that already return the same kind of container. Without it, you get nested containers. With it, the next step receives the plain value when the container is in the success case.

• Maybe.chain(fn) runs fn(value) for Just and skips it for Nothing.
• Result.chain(fn) runs the next validation for Ok and keeps the first Err.
• Array.prototype.flatMap maps each item to an array and flattens one level.
• Promise.prototype.then acts like chain for async steps that return promises.

1const thenable = {2  then(resolve) {3    resolve("flattened by Promise");4  },5};6 7Promise.resolve(thenable).then((value) => {8  console.log(value);9});

That Promise example is also the honest caveat. Promises auto-flatten any object with a callable then method, called a thenable. That practical behavior is useful on the web, but it means Promise does not behave like a perfectly lawful mathematical monad in every edge case.

A Promise answers once. An Observable can call next many times, then complete, and a subscriber can unsubscribe. The implementation below is intentionally tiny, but it has the moving parts you need to read RxJS-style code: subscribe, next, complete, unsubscribe, map, and filter.

1class TinyObservable {2  constructor(start) {3    this.start = start;4  }5  subscribe(observer) {6    let closed = false;7    let cleanup = () => {};8    const safe = {9      next(value) {10        if (!closed) observer.next?.(value);11      },12      complete() {13        if (!closed) {14          closed = true;15          observer.complete?.();16          cleanup();17        }18      },19    };20    cleanup = this.start(safe) || (() => {});21    if (closed) cleanup();22    return {23      unsubscribe() {24        if (!closed) {25          closed = true;26          cleanup();27        }28      },29    };30  }31  map(project) {32    return new TinyObservable((observer) => {33      const subscription = this.subscribe({34        next: (value) => observer.next(project(value)),35        complete: () => observer.complete(),36      });37      return () => subscription.unsubscribe();38    });39  }40  filter(keep) {41    return new TinyObservable((observer) => {42      const subscription = this.subscribe({43        next: (value) => {44          if (keep(value)) observer.next(value);45        },46        complete: () => observer.complete(),47      });48      return () => subscription.unsubscribe();49    });50  }51}52TinyObservable.of = (...values) => new TinyObservable((observer) => {53  values.forEach((value) => observer.next(value));54  observer.complete();55});56 57const numbers = TinyObservable.of(1, 2, 3, 4);58numbers59  .map((number) => number * 2)60  .filter((number) => number > 4)61  .subscribe({62    next(value) { console.log(value); },63    complete() { console.log("done"); },64  });

1const numbers = TinyObservable.of(1, 2, 3, 4, 5);2 3numbers4  .map((number) => number * 2)5  .filter((number) => number >= 6)6  .subscribe({7    next(value) { console.log(value); },8    complete() { console.log("done"); },9  });

Simple DOM events are still often clearest with addEventListener and custom events. Observables help when you want a stream pipeline: map, filter, merge, debounce, retry, and unsubscribe in one vocabulary. RxJS is the mature library many teams use for that.

1const button = document.querySelector("button");2 3if (button && typeof button.when === "function") {4  const subscription = button5    .when("click")6    .map((event) => event.type)7    .subscribe({ next: (type) => console.log(type) });8 9  subscription.unsubscribe();10} else {11  console.log("EventTarget.when is not available in this browser.");12}

Advanced functional vocabulary is useful only when it makes code easier to change. Use the simplest thing that keeps the behavior honest. Optional chaining, Result validation, Promise chaining, EventTarget, RxJS, and transducers can all be the right answer in different parts of a frontend.

Composition & pipelines, being built alongside this lesson, is where these small pieces become larger flows. The important habit is the same: keep each step pure when you can, and isolate effects at the boundary.

Common misconceptions

• “A monad is a special class.” In JavaScript it is usually a convention: a value with chain, flatMap, or then-like behavior.
• “Maybe is always better than ?..” For one property path, optional chaining and ?? are clearer. Maybe helps when many functions share one null-safe shape.
• “Either means no exceptions ever.” Use Result for expected business failures. Throw for bugs, broken invariants, and unexpected infrastructure failures.
• “Transducers make code faster automatically.” They remove intermediate arrays, but the extra function calls and readability cost still need measurement.
• “Observables replace promises.” Promises are the built-in tool for one async value. Observables are for many values, laziness, and cancellation.
• “Functor laws are academic trivia.” The laws explain why refactoring box.map(f).map(g) into box.map((x) => g(f(x))) should be safe.

Key takeaways

• Transducers fuse reducer-based transformations so one input value flows through all steps in one pass.
• A functor is a container with a lawful map; Array and Box make the laws visible.
• Maybe handles missing values, while Either or Result carries expected error messages.
• A monad-like container has chain, flatMap, or then for callbacks that return containers.
• Observables model many lazy, cancellable values; promises model one eventual value.

Up next: the Regular expressions module begins with Patterns & flags.