Introduction to Functional Programming (w/ JS)

INTRODUCTION TO FP
(W/ JAVASCRIPT)

"A monad is just a monoid in the category of
endofunctors..."

SOME FACTS:
(THAT MAY BLOW YOUR MIND)
Elegant, readable and simple code makes it hard for bugs to hide
70% of time spent while maintaining code is spent reading it
Global average for a coder's loc written p/ day is ~10

WHY TO FP?
Because FP "laws" and tools enables us to write a more:
Readable code
Declarative code
Reusable code
Testable code
In general, a more reliable & maintainable code in the long term

READABILITY CURVE
But the journey has its bumps
Source: https://github.com/getify/Functional-Light-JS/blob/master/ch1.md

A PRACTICAL INTRO TO FP
We'll go over some "mandatory" concepts:
First Class Functions
High-Order Functions & Closures
Function Purity
Managing Function Input
Function Composition
Value Immutability
Array Operations
Recursion
Monads Basics

A PRACTICAL INTRO TO FP
Some "mandatory" concepts:
First Class Functions
High-Order Functions & Closures
Function Purity
Managing Function Input
Function Composition
Value Immutability
Array Operations
Recursion
Monads Basics

FIRST CLASS FUNCTIONS
(OR FUNCTIONS AS VALUES)

The majority of patterns and tools around FP requires functions to
be treated as first-class citizens
Which means they can:

BE ASSIGNED TO VARIABLES
// anonymous functions
const aFunction = function () {
console.log('hello fp');
};
// or named functions
const aFunction = function aFunctionName() {
};
// or arrow functions
const aFunction = () => console.log('hello fp');
// or even borrowed methods
const aFunction = someObj.someOtherFunction;

BE ASSIGNED TO DATA STRUCTURES
// With objects
const obj = {
methodAnon: function() { },
methodNamed: function aFunctionName() { },
methodArrow: () => { },
methodBorrowed: otherObj.someOtherFunction;
};
// Or with arrays
const arr = [
function() { },
function aFunctionName() { },
() => { },
otherObj.someOtherFunction
];

BE USED AS OTHER FUNCTIONS ARGUMENTS
const hello = () => {
};
const callFn = fn => fn();
// ...
callFn(hello); // hello fp

BE RETURNED FROM OTHER FUNCTIONS
const getHello = () => {
return () => {
};
};
// or the shorter
const getHello = () => () => console.log('hello fp');
// ...
const hello = getHello();
hello(); // hello fp
// or in one go
getHello()(); // hello fp

HIGH-ORDER FUNCTIONS & CLOSURES
(OR WORKING WITH STATEFUL FUNCTIONS)

HIGH-ORDER FUNCTIONS
A high-order function is a function that does at least one of the
following:

1. TAKES ONE OR MORE FUNCTIONS AS
ARGUMENTS
Useful to separate concerns and abstract/decouple logic
const highOrderSecret = (fnArg) => {
const secret = 'FP rulez!';
fnArg(secret);
};
const logSecret = (secret) => console.log(secret);
const saveSecret = (secret) => secretStorage.add(secret);
// ...
highOrderSecret(logSecret); // FP rulez!
highOrderSecret(saveSecret);

2. RETURNS A FUNCTION AS ITS RESULT
Useful to "hide" state (achieve privacy), persist state to be
processed/used later and compose/add behaviour to other
functions
const makeSecret = () => {
const secret = 'FP rulez!';
return () => secret; // Btw, this is a closure
};
const getSecret = makeSecret();
console.log(getSecret()); // FP rulez!

CLOSURES
A closure is a function that refers to "free variables" (variables
defined in parent scopes)
In other words, it's a function that "remembers" the
state/environment where it was created

A CLOSER LOOK INTO A CLOSURE
// global scope
const makeSecret = () => {
// scope 0
const secret = 'FP rulez';
// following will log undefined because parent a scope
// does not have access to child scopes
console.log(secretSuffix); // ReferenceError: secretSuffix is not defined
return () => {
// scope 1
const secretSuffix = '!!!!!';
return secret + secretSuffix;
};
};
console.log(secret); // ReferenceError: secret is not defined
const getSecret = makeSecret();
// It remembers its own scope plus parent scopes
console.log(getSecret()); // FP rulez!!!!!

FUNCTION PURITY
(OR AVOIDING SIDE EFFECTS)

A function is considered pure if it does not break the following
"laws":
1. Always has to return the same output given the same input
2. Does not depend on/causes any side eﬀect (state mutations, I/O
operations)

PURE FUNCTIONS
const add = (a, b) => a + b;
const getCircleArea = r => Math.PI * r * r;
const getFullName = (first, last) => `${first} ${last}`;
const logUserIn = user => Object.assign(
{},
user,
{ loggedIn: true }
);

IMPURE FUNCTIONS
// I/O operation
const logMsg = msg => console.log(msg);
// Different outputs, same input
const getRandom = (max) => Math.random() * max;
// depends on mutable state
const getFullName = (first, last) =>
`${globalNamePrefix} ${first} ${last}`;
// Mutating object state
const logUserIn = user => user.loggedIn = true;

A program without any observable side eﬀect is also a program that
accomplishes nothing useful
but, side eﬀects should be avoided where possible
as they make programs hard to follow/read, hard to test and hard to
maintain
most of a program codebase should be composed of small, single-
purpose and pure functions

MANAGING FUNCTION INPUT
(OR MANIPULATING FUNCTION ARGUMENTS)

ARGS VS PARAMS
Question: what's the diﬀerence between arguments and
parameters?
// firstName, middleName and lastName are parameters
const getFullName = (firstName, middleName, lastName) =>
`${firstName} ${middleName} ${lastName}`;
// All strings passed into getFullName() call are arguments
getFullName('Allan', 'Marques', 'Baptista');
// arguments < parameters - perfectly valid in JS
getFullName('Emperor', 'Palpatine');
// arguments > parameters - also valid
getFullName('Some', 'Big', 'Ass', 'Freaking', 'Name');

ARGS VS PARAMS
Parameter is the variable which is part of the function signature
Argument is the value/variable/reference/expression being passed
in during a function call

ARITY
The number of parameters a function expects in its signature is
called arity
It's possible to get a function's arity through the
Function.prototype.length property
const double = n => n * 2; // arity = 1 (unary)
// arity = 3 (ternary)
const getFullName = (firstName, middleName, lastName) =>
`${firstName} ${middleName} ${lastName}`;
const double = n => n * 2;
console.log(double.length); // 1

By combining the power of high-order functions (HoF), knowledge of
function arity and loose arguments application, we can build
powerful abstractions

FORCING UNARY FUNCTIONS
Sometimes we need to ensure a function that expects more than
one parameter to receive only one argument
That happens because parseInt's signature is:
parseInt(str [, radix])
And Array.prototype.map calls any function passed in with
the arguments:
fn(item, index, arr)
const strArr = ['1', '2', '3', '4', '5'];
const mumArr = strArr.map(parseInt);
console.log(numArr); // [1, NaN, NaN, NaN, NaN]

FORCING UNARY FUNCTIONS
We can fix that with a utility HoF usually called unary
That can be implemented in JS like so:
And used like this:
const unary = fn =>
param => fn(param);
const strArr = ['1', '2', '3', '4', '5'];
const mumArr = strArr.map(unary(parseInt));
console.log(numArr); // [1, 2, 3, 4, 5]

PARTIAL APPLICATION
Calling a function and passing some arguments to it like:
foo(bar, baz);
can also be described as applying function foo to the arguments
bar and baz

PARTIAL APPLICATION
Means fixing/binding a number of arguments to a function
producing another function with smaller arity
It's useful when we know some of the arguments that'll be applied
to a function ahead of time
But the rest of the arguments we'll only know at a later point in
execution time.

PARTIAL APPLICATION
A partial function application utility can easily be implemented like
so:
And it's used like this:
const partial = (fn, ...eagerArgs) =>
(...lazyArgs) => fn(...eagerArgs, ...lazyArgs);
const fullName = (preferedTreatment, firstName, lastName) =>
`${preferedTreatment} ${lastName}, ${firstName}`;
const maleName = partial(fullName, 'Sir');
const femaleName = partial(fullName, 'Ma'am');
maleName('Allan', 'Baptista'); // Sir Baptista, Allan
femaleName('Nadia', 'Carvalho'); // Ma'am Carvalho, Nadia

PARTIAL APPLICATION
It's also possible to implement a utility that partially applies the
final arguments like so:
That can be used like this:
const partialRight = (fn, ...rightArgs) =>
(...leftArgs) => fn(...leftArgs, ...rightArgs);
const fullName = (preferedTreatment, firstName, lastName) =>
const kirk = partialRight(fullName, 'James', 'Kirk');
kirk('Sir'); // Sir Kirk, James
kirk('Captain'); // Captain Kirk, James

CURRYING
It's creating a function that only executes its actual logic once it has
gathered all parameters it expects
When a curried function is applied to less arguments than its arity it
returns another function
And it keeps returning another function until all arguments are
provided

CURRYING
const curriedFullName = preferedTreatment =>
firstName =>
lastName =>
const getName = curriedFullName('Mr'); // preferedTreatment = 'Mr'
const getLastName = getName('James'); // firstName = 'James'
getLastName('Bond'); // Mr. Bond, James
// or in one go
curriedFullName('Sir')('Leonard')('Nimoy'); // Sir Nimoy, Leonard

CURRYING
In Haskell all functions are curried by default, but in javascript we
need to write a utility function to achieve the same
const autoCurry = (fn, arity = fn.length) =>
(...args) =>
args.length >= arity ?
fn(...args) :
autoCurry(partial(fn, ...args), arity - args.length);

CURRYING
const curriedFullName = autoCurry(
(preferedTreatment, firstName, lastName) =>
`${preferedTreatment} ${lastName}, ${firstName}`
);
const getName = curriedFullName('Mr'); // preferedTreatment = 'Mr'
const getLastName = getName('James'); // firstName = 'James'
getLastName('Bond'); // Mr. Bond, James
// or
curriedFullName('Sir')('Leonard')('Nimoy'); // Sir Nimoy, Leonard
// or
curriedFullName('Sir')('Rowan', 'Atkinson'); // Sir Atkinson, Rowan
// or
curriedFullName('Mr', 'Mickey', 'Mouse'); // Mr Mouse, Mickey

CURRYING
Note that the strict implementation of currying produces only
unary functions a er each call
So the implementation showed here should be called loose
currying, which is o en more useful

FUNCTION COMPOSITION
(OR PLAYING WITH BUILDING BLOCKS)

When a program/application is well split into simple, single-
purpose and pure functions a repeating pattern starts to come up:
And to avoid repetition, it's common to create composed
abstractions:
const outputData = freeze(enhance(escape(inputData)));
const transformData = data => freeze(enhance(escape(data)));
// later somewhere...
const outputData = transformData(inputData);
// and even later...
const dataToPersist = transformData(inputData);

A BETTER WAY
What if there was a way to achieve the same thing in a declarative
way?
const transformData = compose(freeze, enhance, escape);

compose(...fns) takes a list of functions
and returns another function that applies each function from right
to le , so:
// This
const transformData = compose(freeze, enhance, escape);
transformData(...args);
// is the same as this
const escaped = escape(...args);
const enhanced = enhance(escaped);
const outputData = freeze(enhanced);
// or this
const outputData = freeze(enhance(escape(...args)));

One can implement compose in JS like so:
const compose = (...fns) =>
(...args) => fns
.slice(0, -1)
.reduceRight(
(res, fn) => fn(res),
fns[fns.length - 1](...args)
);

FUNCTION COMPOSITION AND ARITY
Note that all functions besides the first one to be applied are
expected to be unary
as it's not possible to return more the one value from a function
By combining the concepts of function composition, arity and input
management one can build very complex logic in a very declarative
way

PIPING
Sometimes reading the flow of data from right to le can be
counter-intuitive
to fix that, we can build a variation of compose that applies each
function from le to right
that variation is usually called pipe or pipeline
const transformData = pipe(escape, enhance, freeze);

PIPING
pipe can be implemented like so:
Other than the diﬀerence on how data flows compose and pipe
works in the same way
(Except this implementation o pipe is a little bit more performant than compose's implementation showed
before)
const pipe = (firstFn, ...restFns) =>
(...args) => restFns.reduce(
(res, fn) => fn(res),
firstFn(...args)
);

VALUE IMMUTABILITY
(OR WRITING PREDICTABLE LOGIC)

In javascript (and the majority of hybrid/OO languages)
immutability is usually not natively enforced on objects
Some may naively think assigning objects with the const keyword
prevents objects from being mutated

But in fact, const only prevents the variable from being re-
assigned
const config = { cannotChange: 'Never changed' };
config.cannotChange = 'Chaos';
console.log(config); // { cannotChange: 'Chaos' }
// but the following throws a TypeError
config = { cannotChange: 'Invalid' };

THE CASE FOR IMMUTABILITY
Mutating an object is a side eﬀect
Mutable objects are hard to follow/read
Mutable objects are hard to predict
Mutable objects o en are the source of hard-to-find bugs
Mutable objects are hard to debug
So, if immutability is not enforced natively by the language, how do
we achieve it?

IMMUTABILITY AS A CHOICE
PLAIN OBJECTS
// Very bad
const logIn = user => {
user.loggedIn = true;
return user;
};
const loggedUser = logIn(anonymousUser);
console.log(loggedUser.loggedIn); // true
console.log(anonymousUser.loggedIn); // true

PLAIN OBJECTS
Pattern: copy objects and mutate the copy
// Good
const logIn = user => {
const userCopy = Object.assign({}, user);
userCopy.loggedIn = true;
return userCopy;
};
const loggedUser = logIn(anonymousUser);
console.log(loggedUser.loggedIn); // true
console.log(anonymousUser.loggedIn); // false

ARRAYS
// Very bad
const addTask = (taskList, task) => {
taskList.push(add);
return taskList;
};
const newTaskList = addTask(taskList, task);
console.log(newTaskList.length); // 10
console.log(taskList.length); // 10

ARRAYS
Pattern: avoid mutable methods (push, pop, shi , unshi , splice,
sort, fill, reverse)
instead use immutable methods (concat, slice, map, filter) or the
spread notation
// Good
const addTask = (taskList, task) => {
// or [...taskList, task];
return taskList.concat(task);
};
const newTaskList = addTask(taskList, task);
console.log(newTaskList.length); // 10
console.log(taskList.length); // 9

IMMUTABILITY AS A LAW
Object.freeze freezes an object, preventing it from being
mutated (works w/ arrays as well)
Pattern: combine Object.freeze with other immutable
patterns to achieve full immutability
const user = Object.freeze({ name: 'Elza' });
user.name = 'Evil'; // throws if in 'strict mode'
console.log(user.name); // Elza

Note that Object.freeze only freezes objects shallowly
So to achieve full immutability all child objects also need to be
frozen
const user = Object.freeze({
name: {
first: 'Elza',
last: 'Arendelle'
}
});
user.name.first = 'Evil';
// { first: 'Evil', last: 'Arendelle' }
console.log(user.name);

Note that these patterns are much less performant than its mutable
counterpart
Even more if we're dealing with deep nested objects
If you need immutability as well as performance maybe it's time to
bring a library in

IMMUTABILITY LIBS
(by facebook)
(port of ClojureScript data structures)
ImmutableJS
mori

But if performance is still an issue, you should think about
replacing parts of your code with mutable patterns
but remember:
"Premature optimization is the root of all evil"
- Donald Knuth

ARRAY OPERATIONS
(OR MORE READABLE LOOPS)

ARRAY METHODS VS LOOPS
const activeItems = [];
for (let i = 0; i < arr.length; i++) {
if (arr[i].active === true) {
activeItems.push(arr[i]);
}
}
// vs
const activeItems = arr.filter(item => item.active === true);

ARRAY METHODS VS LOOPS
Array methods are usually better because:
Traversal logic is abstracted
Terser, more readable and declarative code
Functions and all its goodness!

Loops are better when:
Performance is needed (still, very questionable)
Need to break out of loop early

MAP()
Array.prototype.map is a HoF that traverses the list applying
the provided operator function to each item
and produces a new array with the values returned from each
operator call
const bananas = [' ', ' ', ' ', ' ', ' ', ' '];
const mix = bananas.map((banana, index) => (
index % 2 === 0 ? ' ' : banana
));
console.log(mix); // [' ', ' ', ' ', ' ', ' ', ' ']

MAP()

A WORD ABOUT THE FEARED FUNCTOR
In FP terminology, a Functor is a wrapper object that has a utility
method for applying an operator function to its wrapped value
returning a new Functor wrapping the new value produced by the
operator
If the wrapped value is compound the Functor applies the operator
to each indidual value instead
All this is just a fancy way of saying that Functor is just an object
that has a map method

FILTER()
Array.prototype.filter is a HoF that traverses the list
applying the provided predicate function to each item
and produces a new array with the values of which the predicate
function returned truthy
const badDiet = [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '];
const goodDiet = badDiet.filter(food => !food.includes(' '));
console.log(goodDiet); // [' ', ' ', ' ', ' ']

FILTER()

REDUCE()
Array.prototype.reduce is a HoF that traverses the list
applying the provided reducer function to the previous returned
value and current value
And produces whatever the last reducer call returns
const people = [' ', ' ', ' ', ' '];
const family = people.reduce((str, person) => (
str === '' ?
person :
str + 'u200D' + person
), '' /* <- initial value */);
console.log(family); // ' '

REDUCE()

RECURSION
(OR RECURSION (OR RECURSION...))

Recursion is when a function calls itself until a base condition is
satisfied
const fib = n =>
n <= 1 ?
n :
fib(n - 2) + fib(n - 1);
fib(10); // 55

DECLARATIVE ITERATIONS
Although it may be less performant, expressing repetition with
recursion is usually more readable because of its declarative nature
const sum = (...values) => {
let total = 0;
for(let i = 0; i < values.length; i++) {
total += values[i];
}
return total;
};
// vs
const sum = (firstValue, ...otherValues) =>
otherValues.length === 0 ?
firstValue :
firstValue + sum(...otherValues);

"Loops may achieve a performance gain for your
program. Recursion may achieve a performance
gain for your programmer. Choose which is
more important in your situation!"
- Leigh Caldwell

DIVIDE AND CONQUER
An common strategy to apply when creating a recursive functions is
taking the divide and conquer approach:
Treat every list as a pair containing the first value and a list with
the rest of the values
Define the base condition
Define logic around the first value
Apply the function itself to the rest of the values

DIVIDE AND CONQUER
Iterative:
Recursive:
const map = (arr, fn) => {
const newArr = [];
for (let i = 0; i < arr.length; i++) {
newArr.push(fn(arr[i]));
}
return newArr;
};
const map = ([firstVal, ...rest], fn) =>
firstVal === undefined ?
[] :
[fn(firstVal), ...map(rest, fn)];

DIVIDE AND CONQUER
Note that this technique doesn't only work with lists. Lists are just
easier to wrap you head around the concept
This approach can be applied to almost anything
const iterativeRangeSum = (start, end) => {
let result = start;
for (let i = start; i < end; i++) {
result += i;
}
return result;
}
// vs
const recursiveRangeSum = (start, end) =>
start === end ?
0 :
start + recursiveRangeSum(start, end - 1);

STACK OVERFLOW
The function stack is a limited resource
If the base condition of a recursive function is not met until the
environment runs out of stack frames
The program/application will crash and burn
Always ensure the base condition will be satisfied before that or
refactor the function to use the benefits of tail call optimization
// If list has something like 200 items or more,
// Stack Overflow!
const values = recursiveMap(bigList, item => item.value);

TAIL CALL OPTIMIZATION
Tail call is when a function call is the very last thing evaluated inside
a function
When this happens the compiler can optimize the runtime by
reusing the last stack frame
const foo = () => {
const value = 'tail call';
return bar(value); // <- bar is being tail called
};

TAIL CALL OPTIMIZATION
By refactoring the recursive map utility from:
To use TCO:
map() will now support mapping over lists of any size
const map = ([firstVal, ...rest], fn) =>
[] :
[fn(firstVal), ...map(rest, fn)];
const map = ([firstVal, ...rest], fn, result = []) =>
result :
map(rest, fn, [...result, fn(firstVal)]);

MONADS BASICS
(OR THE THING THAT, ONCE UNDERSTOOD, YOU WON'T BE ABLE
TO EXPLAIN)

But first, some boring topics that won't be covered:
(but you should at some point)
Abstract Algebra
Category Theory
Type Theory
Some people say these fundamental topics are mandatory to start
FPing
I disaggree. But when you feel ready to dive into the theory behind
FP, it's' recommended you do so

REVISITING FUNCTORS
Meet something and nothing:
Note: the names of this Functor implementations vary a lot
(Some/None, Just/Nothing, Something/Empty...)
That happens because Functors, like any other FP type, is like a loose interface
Implementations must respect the type laws but their names are not enforced
const something = (value) => ({
map: fn => something(fn(value))
});
const nothing = () => ({
map: nothing
});

REVISITING FUNCTORS
something is useful
const getUser = userId => {
const user = repository.findUserById(userId);
return user ? something(user) : nothing();
}
// now we can write
// beautiful, idiomatic, declarative code
getUser(existingId) // User exists
.map(attachPermissions(permissions))
.map(attachOrders(orders))
.map(showProfile(template));

REVISITING FUNCTORS
nothing is useful
It's the same exact code, but nothing happens. Not even an
exception!
return user ? something(user) : nothing();
}
// now we can write
getUser(nonExistantId) // User is not found
.map(showProfile(profileTemplate));

REVISITING FUNCTORS
Maybe?
When we use the Something and Nothing Functors together in a
function like this, we're actually implementing the Maybe Functor.
It allows easier and safer null/empty checks without sacrificing
readability.

REVISITING FUNCTORS
handling branches/errors
const success = (value) => ({
map: fn => something(fn(value)),
catch: nothing
});
const error = (e) => ({
map: () => error(e),
catch: fn => something(fn(e))
});

REVISITING FUNCTORS
handling branches/errors
return user ? success(user) : error(new Error('User not found'));
}
// now we can write
getUser(nonExistantId) // User is not found
.map(showProfile(profileTemplate))
// error branch executed when is error
.catch(showError(errorTemplate));

REVISITING FUNCTORS
Either?
When we use the Error and Success together in a function like this,
we're actually implementing the Either Functor.
Its strict implementation is more complex, but the core concept is
the same.
In the strict implementation of the Either Functor, the Error and Success Functors are o en called Le and Right
respectively.

REVISITING FUNCTORS
Containing containers
const attachPermissions = permissions => user =>
permissions ?
something(user.setPermissions(permissions)) :
nothing();
const attachOrders = orders => user =>
orders ?
something(user.setOrders(orders)) :
nothing();
getUser(nonExistantId)
.map(attachPermissions(permissions)) // something(something(user))
.map(attachOrders(orders))// Error: setOrders is not a function

MONADS TO THE RESCUE
Much like the Functor, the Monad has a utility method for applying
an operator function to its wrapped value
But unlike the Functors map() utility, it does not wrap the output
value in a new monad
Because it expects the value to be already wrapped in a monad
This utility function has many names: bind(), chain() and
flatMap()

Unboxing a box
const something = (value) => ({
flatMap: fn => fn(value)
});
const nothing = () => ({
map: nothing,
flatMap: nothing
});

Unboxing a box
const success = (value) => ({
flatMap: fn => fn(value)
catch: nothing
});
const error = (e) => ({
map: () => error(e),
flatMap: () => error(e),
catch: fn => something(fn(e))
});

Unboxing a box
const attachPermissions = permissions => user =>
permissions ?
something(user.setPermissions(permissions)) :
nothing();
const attachOrders = orders => user =>
orders ?
something(user.setOrders(orders)) :
nothing();
getUser(nonExistantId)
.flatMap(attachPermissions(permissions))// something(user)
.flatMap(attachOrders(orders))// something(user)

YOU ARE USING MONADS ALREADY
Let's create a fictional monad that wraps a future value
That can be used like this:
const future = futureValue => ({
map: fn => future(fn(futureValue)),
flatMap: fn => fn(futureValue)
});
future(asyncGetUser(userId))
.flatMap(asyncAttatchPermissions(userId))
.flatMap(asyncAttatchOrders(userId))
.map(showProfile(profileTemplate));

But map() and flatMap() are not very meaningful when dealing
with future values
What if we "merged" and renamed them?
const future = futureValue => ({
then: fn => {
const nextFutureValue = fn(futureValue);
const isFutureMonad = (
nextFurureValue &&
typeof nextFutureValue.then === 'function'
);
return isFutureMonad ?
nextFutureValue :
future(nextFutureValue);
}
});

Now it reads a lot better:
future(asyncGetUser(userId))
.then(asyncAttatchPermissions(userId))
.then(asyncAttatchOrders(userId))
.then(showProfile(profileTemplate));

Feeling a déjà vu?
Yes! Promise is a Monad!
Promise.resolve(asyncGetUser(userId))
.then(asyncAttatchPermissions(userId))
.then(asyncAttatchOrders(userId))
.then(showProfile(profileTemplate));

IMPERATIVE VS DECLARATIVE
WHAT THIS CODE IS DOING?

const words = [
'The', 'quick', 'brown', 'fox,', 'jumps', 'over',
'the', 'lazy', 'dog.', '- It', 'was', 'a', 'german',
'shepherd!'
];
const removeInvalidChars = word => word.replace(/[ -_:;.,!?]/g, '');
const enoughChars = word => word.length >= 3;
const canContainGod = word => word.length >= 3 && word.length <= 6;
const toUpperCase = word => word.toUpperCase();
const reverseStr = word => word.split('').reverse().join('');
const toBibleCode = compose(reverseStr, toUpperCase);
const isGod = word => word === 'GOD';
const logIf = (condition, str) = condition && console.log(str);
const result = words
.map(removeInvalidChars)
.filter(canContainGod)
.map(toBibleCode)
.some(isGod);
logIf(result === true, 'Found GOD...');
logIf(words[0] !== 'The', '...and the devil');

ANSWER:
(ALMOST) THE SAME THING
Challenge: Can you spot a diﬀerence between both outputs?

JS FP LIBS
- Functional utilities on top of lodash
- Functional utilities
- Functional utilities
- Suite of functional libraries
lodash/fp
Ramda
functional.js
Folktale

RESOURCES
- Great FP book, greatly inspired
this talk
- Awesome FP book, dives into
theory more
- A must read for every JS developer
- List of resources about FP in JS
Functional Light JS (by getify)
Mostly adequate guide to FP
JavaScript Allongé
Awesome FP JS

CONTACTS
Linkedin:
Github:
Skype:
E-mail:
/in/allanbaptista
m4n3z40
abaptista.daitan
abaptista@daitangroup.com

Introduction to Functional Programming (w/ JS)

More Related Content

What's hot (20)

Similar to Introduction to Functional Programming (w/ JS) (20)

Recently uploaded (20)

Introduction to Functional Programming (w/ JS)