Functional reactive programming treats an application as events over time and the values derived from them; on the Sean Dinwiddie’s Webmastery team, those ideas become Redux Toolkit’s actions, reducers and selectors.
What FRP is
Functional reactive programming describes values that change over time by what they are derived from. You state once how a value follows from the events so far, declaratively, instead of updating it by hand wherever something changes.
In Redux Toolkit, the store tells each view after each action, or once after a run of the low-priority actions RTK Query sends, and the view reads its values again through selectors.
FRP suits user interfaces and any software whose screens follow from things that happen: a cart, a booking calendar, a kitchen queue.
Key concepts
- Events and behaviors: FRP models a program as events, things that happen at a moment, and behaviors, values that change over time: the two ideas Conal Elliott and Paul Hudak set out in Functional Reactive Animation (1997). On the team, the events are dispatched actions and the behaviors are selectors composed from small pure functions, so the flow of data reads declaratively.
- Functional programming: Pure functions and immutable data do the heavy lifting: the same input always gives the same output, and nothing changes behind your back, so the code is predictable, easy to test and less error-prone. The lecture Basic Functional Programming TypeScript Knowledge covers both.
- Declarative style: A value is defined once, by what it is derived from, as a cart’s total is by its lines, rather than updated by hand in every handler that touches it; Introduction to FRP sets the two side by side.
Why it matters
- Responsiveness: After an action, a view’s selector asks for a re-render only when it returns a new value, and a memoized selector returns one only when its inputs change, so a busy screen re-renders no more than its changes need; how fast it answers still comes down to the view and the network.
- Predictability: Pure reducers and selectors return the same output for the same input, so replaying the actions behind a wrong value reproduces it exactly, and that list of actions becomes its test.
- Real-time data: Data that arrives while a screen is open, such as a new booking, enters as an action like any other, so the screen updates the same way it does for a click.
- One home for each piece of state: It lives in one place (a component, the router, a slice or RTK Query), which keeps a growing codebase readable.
In the team’s work
Sean Dinwiddie’s Webmastery builds the state layer of custom apps on these ideas, in Redux Toolkit. Applied that way, FRP helps you:
- Build screens that update the moment an order, a booking or a click changes what the app knows.
- Write reducers and selectors a test can run with no browser or server.
- Keep each request, timer and follow-up effect at the boundary, where it can be traced and tested.
- Keep each piece of state in one place, so the software stays readable as it grows.
Module 3 teaches these ideas one at a time, in Redux Toolkit, written the way the team writes it on its own jobs.
Next steps
The curriculum comes next, and the course outline after it maps every module and its lessons.