{"componentChunkName":"component---src-templates-blog-post-js","path":"/demystifying-functional-programming-with-ramda/","result":{"data":{"site":{"siteMetadata":{"title":"Fabrizio Fortunato","author":"Fabrizio Fortunato","siteUrl":"https://izifortune.com"}},"markdownRemark":{"id":"08b06741-f886-5606-8ac3-36a956419203","excerpt":"A very opinionated introduction to functional programming in Javascript using Ramda. The benefits of using functional programming in Javascript and a first look…","html":"

A very opinionated introduction to functional programming in Javascript using Ramda. The benefits of using functional programming in Javascript and a first look at functions composition.

\n

I also need to say that i’m definitely not an expert on the field but i’m really starting to appreciate the subject and i’m realising all the benefits that it brings to the table.

\n

Speaking about Javascript at work, yes i work in Ryanair as Lead Frontend Developer, we already banned long time ago the use of for and while loops ( where performance it’s not an issue ), using only map/filter/reduce over the other ones.

\n

We can say that we are on our journey on functional programming.

\n

First i want to start by answering the easy questions so:

\n\n
\n

functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. —Wikipedia.

\n
\n

So what we can get from Wikipedia definition is that is paradigm, like object oriented or imperative programming.\nThe basic computation are functions which lead us to the following question, why Javascript is a functional programming language.

\n

In javascript functions are first class functions, in fact we can assign a function to variable, as an array element.

\n
const foo = () => 'bar';\n\nconst list = [foo];
\n

The other point revolves around functions of course, in javascript you can have a function as a result of another function or you can pass function as a parameter of another function, this is called higher order functions.

\n
const higher = f => f('bar');\n\nconst another = () => {\n  return () => 'bar';\n};
\n

Why

\n

Having introduced a little bit what is functional programming and why javascript is a functional programming language the following question is why we should worry about learning and write in this new paradigm?

\n

Attention the following statements are very subjective and personal.

\n

First it comes down to readability, when doing code reviews or peer reviews i can see what is going on inside a pull request without poking the developer asking what is going on inside.

\n

\n

In Ryanair we used different frameworks for different projects, we started out with Angular 1 and now we are moving also to Angular 2, while those two frameworks are very different the paradigm that we are following is the same.

\n

Frameworks will come and go, yesterday was Backbone, today it’s React tomorrow who knows.

\n

Learning a new paradigm and particularly functional programming, enables to solve problems in a completely different way, which in my opinion is more elegant and more robust.

\n
\n

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

\n
\n

Why not object oriented

\n

We followed an object oriented approach at the start of the new web site and we probably stumble into all the problems that comes with it:

\n

Inheritance

\n

One of the pillar of Object oriented paradigm for code reuse. When using inheritance you are creating a taxonomy, a hierarchy for the concepts that you have to shape. Forcing you to inherit from a single ancestor, in a large project pretty soon you will have the famous gorilla/banana problem

\n
\n

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

\n

Joe Armstrong

\n
\n

Interfaces can save you here instead of directly relying on inheritance.

\n

Encapsulation

\n

Encapsulation is one of the other pillars of object oriented programming, variables are protected from access because they are encapsulated inside the object. In javascript this is true about primitive types which they are passed by value. But objects are passed always through reference which means that the passed object is not safe at all.

\n

Immutability will rescue here and the use of pure functions, but we will explore them later on.

\n

Ok stop chatting and now let’s dive into it. We choose Ramda as a helper library to start this journey into functional programming.

\n

Composition

\n

One of the most fundamental concepts of functional programming. Composition let us break down our logic, our operations into smaller functions which later on we can just compose them together.

\n

If we look at Ramda it exposes different functions for doing this, we start with compose

\n
const compose = (f, g) => x => f(g(x));
\n

R.compose in Ramda take n functions and as the function name tell compose them together. One thing to note about compose is that we define the functions to execute from right to left.

\n

We define them right to left because we are following the mathematical composition which applies right to left as well, this way our compose will follow the same laws that the mathematical one has: associativity

\n

It doesn’t matter how you group compose, the result will be equivalent.

\n

Given this data structure for a flight and three functions a b c:

\n
const flight = {\n  options: {\n    1: {\n      globalCode: 'foo'\n    }\n  }\n};\n\nconst a = data => data.options[1].globalCode;\n\nconst b = data => data.toUpperCase();\n\nconst c = data => data + '-BAR';
\n

And we want to compose them together

\n
R.compose(\n  R.compose(c, b),\n  a\n)(flight) //=> 'FOO-BAR'
\n

it’s equal to

\n
R.compose(\n  c,\n  R.compose(b, a)\n)(flight) //=> 'FOO-BAR'
\n

So how can we leverage composition in javascript and what it enables?

\n

Let’s see a small example, we want to filter all the flights that have a discount, our flight structure is really nested so we have to walk through it and not all the flights will have this nested attribute so we want to be safe at the same time that we are not causing any errors.

\n
const getDiscountFlights = flights => {\n  return flights.filter(flight => {\n    if (flight && flight.options && flight.options[1] &&\n        flight.options[1].globalCode) {\n      return flight.options[1].globalCode.indexOf('ESDSC') !== -1;\n    }\n    return false;\n  })\n};
\n

Now let’s try to break down our functions into smaller ones and composed them together:

\n
const hasDiscountCode = R.contains('ESDSC');\nconst getGlobalCode = R.pathOr(\n  '',\n  ['options', '1', 'globalCode']\n);\nconst getDiscountFlights = R.filter(\n  R.compose(\n    hasDiscountCode,\n    getGlobalCode\n  )\n);
\n

This code is more or less equivalent, which one do you think is more readable and maintainable?

\n

We have introduced some other Ramda functions in here:

\n\n

In the end we are composing the two functions together to check if the flight has a discount or not.

\n

Breaking down the functionality into smaller functions allow also to reuse them in different part of the application, avoiding code duplication and also it enables very quick refactoring of the functionality. For example what we could do is extract the hasDiscount function into a generic file

\n
//util.js\nexport const hasDiscount = R.compose(\n  R.contains('ESDSC'),\n  R.pathOr(\n    '',\n    ['options', '1', 'globalCode']\n  )\n);\n\n//main.js\nimport { hasDiscount } from './utils';\n\nconst getDiscountFlights = flights => {\n  return R.filter(\n    hasDiscount\n  )(flights);\n};
\n

Reverse compose

\n

If instead of applying functions right to left you prefer to apply the functions left to right, Ramda has already a function for it which is called pipe.

\n

It’s just a different flavour of composition and you can choose which one you are more comfortable with it.

\n

On the next post i will talk about pure functions.

","frontmatter":{"title":"Demystifying functional programming with Ramda","date":"February 15, 2017","description":null,"socialImage":{"childImageSharp":{"fixed":{"src":"/dist/static/72c312f02a59fd6e8c04a294115645bc/bdf9d/post_image-2.png"}}},"image":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAECAIAAAABPYjBAAAACXBIWXMAAAsSAAALEgHS3X78AAAAxElEQVQI12P4fl/u2z25p+dlHpySBqKHp0HoxBaJZxdk7p2UfnxW5v9L+fXzJJZPl5w/Qbgglc/PjevKAal/T+W/3pVj+PFA7stduSMbJbYsEls1U2TrYrE9q8RXzBA5uE582xKxG4dB6p6ck7m8X7o6n392j3BFLn9zucD/F2DNQJuBCKji/3P5v2Dy3zN5IPfXIzkI+nJHDmg50KC8FN6dy8VKMvnm9AoDlSE0A1nICOgROIIogNrxTP7DTdnfT+QhXAD46IppFiP+1QAAAABJRU5ErkJggg==","aspectRatio":4.513513513513513,"src":"/dist/static/72c312f02a59fd6e8c04a294115645bc/a5924/post_image-2.png","srcSet":"/dist/static/72c312f02a59fd6e8c04a294115645bc/17cc0/post_image-2.png 167w,\n/dist/static/72c312f02a59fd6e8c04a294115645bc/f7869/post_image-2.png 333w,\n/dist/static/72c312f02a59fd6e8c04a294115645bc/a5924/post_image-2.png 666w,\n/dist/static/72c312f02a59fd6e8c04a294115645bc/997c6/post_image-2.png 999w,\n/dist/static/72c312f02a59fd6e8c04a294115645bc/7f237/post_image-2.png 1332w,\n/dist/static/72c312f02a59fd6e8c04a294115645bc/4ce6a/post_image-2.png 1920w","sizes":"(max-width: 666px) 100vw, 666px"}}}}}},"pageContext":{"slug":"/demystifying-functional-programming-with-ramda/","previous":{"fields":{"slug":"/mvc-is-dead-even-for-angularjs/"},"frontmatter":{"title":"MVC is dead - even for AngularJS"}},"next":{"fields":{"slug":"/unit-testing-angular-applications-with-jest/"},"frontmatter":{"title":"Unit testing Angular applications with Jest"}}}}}