Discussion on: Practical Functional Programming in JavaScript - Side Effects and Purity

Nice work on the functional paradigm Richard,

Let me give you a couple ideas I use with piping and logging.

Let's say we have this...

const p1 = pipe(
  func1,
  func2,
  func3,
  func4,
);

//@tests
p1(val)

I keep log statements out of the funcs themselves, otherwise you can't run them in a loop.

One of the cognitively challenging things about pipes is keeping the output of one func compatible with the input of the next. So I'll use a set of strongly-typed log utils for dev-side troubleshooting.

Here's an example of logging a pipe (exaggerated with lots of log utils for demo purposes)

const p1 = pipe(
  func1, llArr,
  func2, lFirstElems(3),
  func3, lStr,
  func4, lNum,
);

//@tests
p1(val)

The "l" prefix means "log"
The "ll" prefix means "log length"
"Elems" implies an arr, so in this case only the first 3 elems (elements) are logged
Note that I keep the log util on the same line of the returning func, for readability.

If the type passed into the log util is wrong, it throws. (we have a bug!)
The throw message tells me what this "wrong" type was, and it's value (up to 500 chars).

By reading this, I know, for example, that func3 takes an arr and returns a str, and func4 takes a str and returns a num.

If not, this pipe won't run, it'll throw.