Event Streams in FRP | Sean Dinwiddie's Webmastery

Updated October 4, 2026· Development

Event streams and reactive programming are two core ideas of functional reactive programming (FRP): what happens, in order, and how a program answers it without updating values by hand. Take them one at a time, then see how they fit together.

1. Event streams

An event stream is a sequence of events, or changes in data, over time. The events can come from anywhere: a user’s interaction, a sensor, a network response.

In Redux Toolkit, the event stream is the sequence of dispatched actions, and the store’s state is that sequence folded through the reducer; the lecture Redux Standard Patterns and Functional Programming models those events in a slice.

A kitchen order’s actions, folded. Each action meets the reducer, which turns the last state into the next, and the violet line carries the state down. Replay the same actions in the same order and the same state comes out.

Characteristics of event streams:
- Asynchronous: Events arrive whenever they happen, on no fixed schedule.
- Ordered: Events keep the order they happened in, so the program answers them one after another.
- Discrete: Each event happens at a moment. Values that change over time are FRP’s behaviors; Redux Toolkit derives them with selectors, which read the state after each action rather than in continuous time.

2. Reactive programming

Reactive programming reacts to changes and events as they occur, instead of steering everything with explicit control flow and callbacks. The program declares how it responds to each event, and derives its values from state instead of updating them by hand.

Key principles of reactive programming:
- Declarative approach: Each value is defined once, by what it is derived from, rather than updated by hand wherever an event lands; Introduction to FRP sets a running total against a selector.
- Composability: Reactive programming composes complex behavior from small pure functions: map, filter and reduce over events, and selectors built from smaller selectors.
- Efficiency and responsiveness: The work follows the changes. A selector recomputes only when its inputs change, and a view re-renders only when what it reads is different.
Effects over time: Timing belongs at the boundary, never in a reducer: in Redux Toolkit, listener middleware debounces, delays and cancels work in response to later actions.

Where it bends. FRP samples a behavior when an event occurs: it reads the value something has at that moment. Redux Toolkit has no continuous time, so a sample is taken in one of two places:

A listener samples the state when an action arrives, with listenerApi.getState(), or listenerApi.getOriginalState() for the state just before it.
The clock is sampled when the action is created, never in a reducer: a prepare callback stamps the event with the time it happened.

// features/kitchen/kitchenSlice.ts, in createSlice({ reducers: { ... } })
orderPickedUp: {
  reducer(state, action: PayloadAction<{ orderId: string; at: string }>) {
    const order = state.queue.find((o) => o.id === action.payload.orderId)
    if (order) order.pickedUpAt = action.payload.at
  },
  prepare: (orderId: string) => ({ payload: { orderId, at: new Date().toISOString() } }),
},

The kitchen’s wait times are then part of the events themselves, and replaying the same actions gives the same state tomorrow as today. A reducer or selector that reads Date.now() breaks the fold. To try it, give the slice one order in its queue, build one orderPickedUp action for it, and run the reducer on that action twice, a second apart: the two states match. Move new Date().toISOString() from prepare into the reducer and run the same two steps again: pickedUpAt differs, and a slice test that compares the whole state fails. The lecture Modern Redux Architecture Patterns sets out what listeners are for.

3. Integration in FRP

In FRP, event streams and reactive programming work as one. Each event is an action, each reducer a pure step from one state to the next, and each derived value a selector. So every change on screen traces back to an action, and a test can replay it.

4. Example use cases

A search box: each keystroke is an event, and listener middleware waits for a pause in them before the search goes out.
A restaurant’s kitchen queue: each order placed, started and picked up is an event, and the queue on screen is derived from them.
A food truck’s menu: each item marked sold out is an event, and the menu customers see is derived from them.
Table bookings: each booking made, changed or cancelled is an event, and the evening’s open tables are derived from them.

Event streams and reactive programming are FRP’s two halves: the actions, in the order they happened, and the state and values derived from them. The next lesson, FRP fundamentals in software development, turns these two ideas into a path of practice, from events and behaviors to FRP’s advanced topics, and folds a cart’s events with no library at all.

Event streams and reactive programming

1. Event streams

2. Reactive programming

3. Integration in FRP

4. Example use cases

Marketing

Design

Development

Automation

Local