FRP Fundamentals | Sean Dinwiddie's Webmastery

Updated October 4, 2026· Development

Functional reactive programming (FRP) is built from a few core ideas, and mastering it starts with getting those solid. Here is a path in seventeen steps, from FRP’s two ideas to its advanced topics.

The core ideas

Understand events and behaviors: Start with FRP’s two ideas: events, things that happen at a moment, and behaviors, values that change over time. In Redux Toolkit, the events are dispatched actions and the behaviors are selectors over the state.
Learn reducers and selectors: A reducer folds each event into the next state, and a selector derives a value from state. Practice both as pure functions with plain inputs and outputs.
Event handling: React to each event by dispatching an action named for what happened. Practice on user interactions, data changes and events from outside the app.
Immutability: FRP usually treats data as unchangeable. Get comfortable with immutable data structures: they keep your functions pure and your side effects few.
Declarative programming: Say what a value is rather than how to keep it current: a total derived by a selector, never a running total updated in a handler.
Listeners: Study listener middleware, which reacts to later actions over time, and learn when to cancel work that has gone stale.

Practice

Use cases: Build small, real features with FRP for practical experience. A cart, a menu that marks what sold out, or a booking calendar makes a good first one.
Composition: Build larger functions from small ones with pipe and compose, and larger selectors from smaller ones. The lecture Functional Composition covers both directions.
Testing: Test a reducer through a sequence of actions and a selector through its output. Neither needs a browser.
Error handling: Treat an expected failure, such as a declined card, as data, never as an exception: the API refuses with its reason in One feature, scope to launch, the view reads that reason in The view stays minimal, and a response of the wrong shape becomes a Left in Endpoints at the boundary.
Connect the view: A React view reads shared state through useAppSelector and server data through RTK Query hooks, dispatches events, and keeps only local drafts in its own state.
Performance and optimization: A selector recomputes only when its inputs change, and a view that selects the narrowest value it needs re-renders only when that value does; measure a slow screen before changing its code.

Keep going

Read the sources: The Redux Toolkit documentation and the Redux Style Guide set the current patterns, and Elliott and Hudak’s Functional Reactive Animation (1997) sets out behaviors and events.
Ask where the patterns live: Members bring questions to one another in the team’s own community, and anyone can turn to the Redux documentation, whose guides teach the patterns this course builds on; general FRP forums mostly cover stream libraries, which model only events.
Projects and collaboration: Build a feature with someone else and read each other’s reducers and selectors. A second reader spots a stored value that should have been derived.
Advanced topics: Then go deeper, into effects over time with listener middleware, normalized entity collections, and FRP’s origin in continuous-time behaviors.
Continuous learning: The lessons are revised as the team’s practice improves; come back to them, and to Sean’s lectures, as your practice grows.

The rule behind the examples. The steps above come back to three pure pieces and one boundary. An event is a plain value that names what happened; the state is every event so far, folded through a pure function; a behavior is a value derived from that state; and every effect, from a network request to a timer, waits at the edge. Practice the three with no library at all:

// Events, a fold and a derived value, with no library.
type ItemAdded = { type: 'itemAdded'; productId: string; priceCents: number }
type Line = { productId: string; priceCents: number; quantity: number }

const next = (lines: Line[], event: ItemAdded): Line[] =>
  lines.some((line) => line.productId === event.productId)
    ? lines.map((line) => (line.productId === event.productId ? { ...line, quantity: line.quantity + 1 } : line))
    : [...lines, { productId: event.productId, priceCents: event.priceCents, quantity: 1 }]

const totalCents = (lines: Line[]) => lines.reduce((sum, line) => sum + line.priceCents * line.quantity, 0)

const events: ItemAdded[] = [
  { type: 'itemAdded', productId: 'widget-a', priceCents: 2500 },
  { type: 'itemAdded', productId: 'widget-b', priceCents: 1200 },
  { type: 'itemAdded', productId: 'widget-a', priceCents: 2500 },
]

totalCents(events.reduce(next, [])) // 6200

Redux Toolkit then adds what the fold leaves out:

Immer, for the update syntax;
createSelector, to remember derived values;
the store, to tell each view when to read again;
RTK Query and listener middleware, for the effects.

Learned in that order, each reads as a convenience rather than magic, and a reducer that misbehaves can be run by hand on a list of events. The lecture What Is a Function? starts from the same place.

Every step above lands somewhere in one picture:

Three pure pieces and one boundary. An event names what happened, the state folds every event so far, and a value is derived from the state, all inside the pure core (the violet frame). Every effect waits outside it, at the edge.

FRP rewards practice: the more you build with it, the more naturally you derive what each screen shows from the events that happened.

Discover how FRP enhances user interaction and responsiveness, next, shows eleven ways FRP changes how an interface answers the people using it.

FRP fundamentals in software development

The core ideas

Practice

Keep going

Marketing

Design

Development

Automation

Local