Fluent code should make you feel happy, like this image does. is code that reads as a sentence. You probably know this if you ever a wrote test code, it reads as a sentence: Fluent Api expect(someValue).to.equal(expectedValue) View GitHub gist If you’ve used an expression builder, you probably noticed it is very easy to read: theSite = SiteBuilder()
  .withSiteName( )
  .withDomain( )
  .build(); const new 'a Site' 'www.some-domain.com' View GitHub gist To enable this API, you can use a that returns from each of it’s methods: class this {
  private site: any;
  withSiteName(name: string) { .site.name = name; ;
  }

  withDomain(domain: string) { .site.domain = domain; ;
  }

  build() { .site;
  }
} class SiteBuilder this return this this return this return this View GitHub gist Pretty straightforward, and actually easy to implement but it has it’s drawbacks — having to return from every method is kind of annoying. this If you’re like me, and you dislike using , you may have tried looking for alternatives. this 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: withSiteName = set(lensProp( )); withDomain = set(lensProp( )); site = pipe(withSiteName( ), withDomain( ));
site({}); const 'name' const 'domain' const 'a Site' 'domain' // site is the function that returns the value View GitHub gist The idea here is that is a curried function that accepts a set(lens, value, src) (basically a way to define a path), I’ll explain a little bit on this in the next paragraph. lens the value to write to the path defined by lens value: set will return a new object (never mutate) based on the source object with the new property and value. src: 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: Not really useful with Typescript right now since curried functions require the use of and Typescript, currently, doesn’t support it. It’s on the though. You can read to understand the problem. variadic kinds roadmap here 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: withSecurityEnabled = set(lensPath([‘services’, ‘securityEnabled’])) const View GitHub gist 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: SiteBuilder = ({ : SiteBuilder({...value, ...{name}}), : SiteBuilder({...value, ...{domain}}), : value
}); site = SiteBuilder({})
  .withSiteName( )
  .withDomain( )
  .build(); const => value withSiteName => name withDomain => domain build => () const 'hello' 'some-domain' View GitHub gist It’s still easy to read, starting to look similar to the class version but without the need to return from every method. this There is some duplication, still, but we can remove it with some simple refactoring: wrapWith = obj => val => wrapper({...obj, [key]: val}); wrapWithSiteBuilder = wrapWith(SiteBuilder); { siteBuilderWrapper = wrapWithSiteBuilder(value); { : siteBuilderWrapper( ), : siteBuilderWrapper( ), : value
  };
}

SiteBuilder({}).withSiteName( ).withDomain( ).build(); // Helper Functions const => wrapper => key const // Expression Builder ( ) function SiteBuilder value const return withSiteName 'name' withDomain 'domain' build => () 'hello' 'some-domain' View GitHub gist 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?

Writing Fluent Functional Code

Too Long; Didn't Read

Coin Mentioned

@hesher

RELATED STORIES