A side effect is work a function does beyond producing its return value, such as writing to a file or changing state visible outside the function. A function is pure when its inputs determine its output and running it leaves the application’s observable state unchanged. The same expression can then be replaced by its value without changing behavior—a property called referential transparency. section 4.1.2
Watch for functions that:
- Print to the console, log to a file, make an HTTP request, or access a network socket or filesystem. section 4.1.2 section 4.3.1
- Read or write variables outside their scope, rely on Math.random, or take needed data implicitly from this. section 4.1.2 section 4.3.2
Useful applications cannot avoid effects. Keep them at the edges of a workflow and make the central transformations explicit, pure, and composable. For example, counting words in a file requires a read, but decoding, splitting, and counting can remain separate functions. Composing those functions organizes the workflow; it does not make the file read pure. section 4.3.1
Listing 4.6 countWordsInFile implemented with compose
const countWordsInFile = compose(
count,
split,
decode,
read
);
countWordsInFile('sample.txt'); // 9
The composed word-count pipeline makes the boundary visible: read accesses the file, while decode, split, and count transform its result. section 4.3.1
Make an implicit dependency explicit
An assemble function that reads properties through this depends on its calling context. Give it the data instead: function assemble(keys, obj) { return keys.map(key => obj[key]).join(''); }. The caller can pass its object, while the extracted function no longer has to infer where its data comes from. section 4.3.2
The distinction is practical rather than a ban on every assignment: a hash calculation can use local mutable variables without letting those changes escape its scope. By contrast, a wallet balance method that reads this and repeatedly reassigns a running balance can be refactored to pass the address and ledger to a separate computation using filter, map, and reduce. section 4.3.2 section 4.7
Do not confuse a side effect with every effect. Validation and error handling may be called effects because they are tasks alongside business logic; an effect in that sense need not be a side effect. Wrapping such tasks can keep them from being repeated throughout a function pipeline. section 5.1
