Functional design patterns

Having seen several OOP design patterns, it may seem a cheat to say that there’s no approved, official, or even remotely generally accepted similar list of patterns for FP. There are, however, several problems for which there are standard FP solutions, which can be considered design patterns on their own, and we have already covered most of them in this book.

What are the candidates for a possible list of patterns? Let’s attempt to prepare one – but remember that it’s just a personal view. Also, I’ll admit that I’m not trying to mimic the usual style of pattern definition; I’ll just be mentioning a general problem and refer to the way FP in JavaScript can solve it, and I won’t be aiming for nice, short, and memorable names for the patterns either:

• Processing collections using filter/map/reduce: Whenever you have to process a data collection, using declarative higher-order functions such as filter(), map(), and reduce(), as we saw in this chapter and previously in Chapter 5, Programming Declaratively, is a way to remove complexity from the problem. (The usual MapReduce web framework is an extension of this concept, which allows for distributed processing among several servers, even if the implementation and details aren’t exactly the same.) Instead of performing looping and processing as a single step, you should think about the problem as a sequence of steps, applied in order, and doing transformations until obtaining the final, desired result.

Looping in other ways

JavaScript also includes iterators, another way of looping through a collection. Using iterators isn’t particularly functional, but you may want to look at them, since they may be able to simplify some situations. Read more at developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols.

• Lazy evaluation with thunks: The idea of lazy evaluation is not doing any calculations until they are actually needed. In some programming languages, this is built in. However, in JavaScript (and most imperative languages), eager evaluation is applied, in which an expression is evaluated as soon as it is bound to some variable. (Another way of saying this is that JavaScript is a strict programming language, with a strict paradigm, which only allows calling a function if all of its parameters have been completely evaluated.) This sort of evaluation is required when you need to specify the order of evaluation with precision, mainly because such evaluations may have side effects.

In FP, which is more declarative and pure, you can delay such evaluation with thunks (which we used in the Trampolines and thunks section of Chapter 9, Designing Functions) by passing a thunk that will calculate the needed value only when it’s needed, but not earlier.

Generating more results

You may also want to look at JavaScript generators, another way of delaying evaluation, though not particularly related to FP. Read more about them at developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator. The combination of generators and promises is called an async function, which may be of interest to you; refer to developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function.

• Persistent data structures for immutability: Having immutable data structures, as we saw in Chapter 10, Ensuring Purity, is mandatory when working with certain frameworks, and in general, it is recommended because it helps to reason about a program or to debug it. (Earlier in this chapter, we also mentioned how the Memento OOP pattern can be implemented in this fashion.) Whenever you have to represent structured data, the FP solution of using a persistent data structure helps in many ways.
• Wrapped values for checks and operations: If you directly work with variables or data structures, you can modify them at will (possibly violating any restrictions), or you may need to do many checks before using them (such as verifying that a value is not null before trying to access the corresponding object). This pattern aims to wrap a value within an object or function, so direct manipulation won’t be possible, and checks can be managed more functionally. We’ll refer to more of this in Chapter 12, Building Better Containers.

As we have said, the power of FP is such that, instead of having a couple of dozen standard design patterns (and that’s only in the GoF book; if you read other texts, the list grows!), there isn’t yet a standard or acknowledged list of functional patterns.