Writing fluent functional code

Fluent code should make you feel happy, like this image does.

Fluent Api is code that reads as a sentence. You probably know this if you ever a wrote test code, it reads as a sentence:

If you’ve used an expression builder, you probably noticed it is very easy to read:

To enable this API, you can use a class that returns this from each of it’s methods:

Pretty straightforward, and actually easy to implement but it has it’s drawbacks — having to return this from every method is kind of annoying.

If you’re like me, and you dislike using this, you may have tried looking for alternatives.

The most straightforward functional approach, and in my opinion the best one is using `pipe()` with stateless setters. I’ll use ramda to introduce it:

The idea here is that set(lens, value, src) is a curried function that accepts a

• lens (basically a way to define a path), I’ll explain a little bit on this in the next paragraph.
• value: the value to write to the path defined by lens
• src: set will return a new object (never mutate) based on the source object with the new property and value.

In the end, this has the same result as a class builder but is more concise and no need to deal with redundant this.

A couple of notes on this approach:

1. Not really useful with Typescript right now since curried functions require the use of variadic kinds and Typescript, currently, doesn’t support it. It’s on the roadmap though. You can read here to understand the problem.
2. If you need to write to a path that is deeper than a single level, for (a contrived) example site.services.securityEnabled, you should use lensPath:

Ok, so if you’re reading this you may have noticed that, although it looks great, this pattern doesn’t allow you chaining and while I propose that the definition of fluent should be expanded or put in a broader context, some of us need chaining to feel comfortable in reading code.

Let’s see how we keep the functional aspects of the expression builder while allowing to chain.

So this is a simple example of an expression builder that’s based on functional:

It’s still easy to read, starting to look similar to the class version but without the need to return this from every method.

There is some duplication, still, but we can remove it with some simple refactoring:

It has it’s pros and cons and I’m sure it can be made to look nicer. (Feel free to suggest)

But the bottom line is — It’s a stateless, functional, fluent, expression builder.

WDYT?