Introduction to functional reactive programming (FRP)

Updated October 4, 2026· Development

Sean Dinwiddie

This lesson takes FRP’s two ideas apart, events and behaviors, then shows the fold that joins them and where Redux Toolkit bends Elliott and Hudak’s model.

Key concepts

1. Events and behaviors: At the core of FRP are events, things that happen at a moment, and behaviors, values that change over time. An event can be a user interaction, a timer or a network response; in Redux Toolkit, a behavior is a value derived from the events so far.
2. State as a fold: The state at any moment is every event so far, folded through a pure function. In Redux Toolkit that is actions.reduce(reducer, initialState): the reducer combines the last state with the next action and reads nothing else.
3. Declarative programming: A declarative program says what a value is, and leaves keeping it current to the events. A click handler that runs total += price says how to update the total, so every path that changes the cart needs a line of its own, and the one a removal forgets leaves the total wrong. A selector says what the total is, the sum of each line’s price times its quantity, so every change to the cart is already counted. From scenario to slice writes it as selectTotalCents.
4. Immutable data: FRP usually treats data as immutable: a change makes a new version and leaves the old one untouched, which supports referential transparency and keeps side effects down.
5. Event-driven programming: FRP suits event-driven programming, where code reacts to events as they occur. In Redux Toolkit, a reducer decides what each event changes, and selectors combine what the events have left in state.

How it works

FRP works by modeling what happens as events and what the program knows as values derived from them. Developers declare how each event changes the state and how each value is derived, and compose small pure functions into larger ones, rather than writing callbacks that change things in place.

FRP turns up everywhere from games and simulations to the interfaces this course builds: a cart, a menu that marks what sold out, a kitchen queue. It fits wherever what the software shows follows from things that happen, as a cart’s total follows from what was added and removed.

Where FRP comes from

FRP starts with Conal Elliott and Paul Hudak’s Functional Reactive Animation (1997), built on two ideas: behaviors, values that change over time, and events, things that happen at a moment. Observable libraries often borrow the name but model only streams of events.

In custom apps, the Sean Dinwiddie’s Webmastery team builds the same ideas in Redux Toolkit: actions are the events, reducers fold them into state, and selectors derive the values a view shows. The lecture What Is a Function? shows the boundary that keeps those reducers pure: a pure core decides, and a thin shell acts.

Side by side, the two kinds of time look like this:

So FRP describes a program as events and the values derived from them, with a pure function at every step between. Redux Toolkit builds it from actions, a reducer that folds them into state, and selectors; the next lesson, Event streams and reactive programming, reads the dispatched actions as the event stream and shows where the time is stamped: when an action is created, never in a reducer.