An action is code whose meaning depends on when it runs, how many times it runs, or both. It affects the world or is affected by it, so repeated or reordered execution can change the result. Sending email, reading a database, changing state, and handling a UI event are actions. section 1.19 section 3.9
Actions belong beside calculations and data in a basic functional-programming distinction. Calculations derive outputs from inputs without time-dependent effects, while data records facts. Prefer data and calculations where possible, then isolate the actions that must perform work. section 3.1 section 3.11
Recognize actions by their dependence on execution:
- Treat sending an email as an action because sending it twice differs from sending it once. section 1.17
- Treat database reads, message receipt, database changes, and UI events as actions because timing or repetition matters. section 1.12 section 1.14 section 1.15
- Watch for function calls, method calls, constructors, expressions, and statements; JavaScript can implement actions and calculations with the same function construct. section 3.9
- Remember that actions spread: a function calling an action becomes an action, as do its callers. section 3.8
Planning before sending
A coupon campaign fetches subscribers and coupons, both actions, then calculates an email plan as data. Sending the prepared emails remains an action. Separating decisions from execution makes the calculations easier to test and leaves the time-sensitive work in a smaller boundary. section 3.5 section 3.6
Tracing action spread
In an affiliate payout flow, transferring money is an action. The payout calculator, affiliate loop, and program entry point become actions when they call it, even though some surrounding code only computes amounts or chooses recipients. section 3.7
Use the category diagram to compare actions with calculations and inert data, then locate time-dependent work before refactoring. section 1.10
