Javascript Combinators (2016)

JavaScript Combinators (2016)

we'll talk about
Using combinators for
decomposi2on and composi2on

and we'll think about
Making responsibili/es and
rela/onships explicit

Decomposi)on

We decompose en%%es to make
discreet responsibili%es explicit

a monolith
Parse.User.logIn("user", "pass", {
success: function (user) {
query.find({
success: function (users) {
users[0].save({ key: value }, {
success: function (user) {
currentUser = user;
}
});
}
});
}
});

decomposi)on by extrac)ng func)ons
let assignCurrentUser = (user) => {
currentUser = user;
};
let saveFirstUser = (users) =>
users[0].save({ key: value }, {
success: assignCurrentUser
});
let logUserIn = (user) =>
query.find({
success: saveFirstUser
});
Parse.User.logIn("user", "pass", {
success: logUserIn
});

Composi'on

We compose en%%es to make the
rela%onships between them explicit

promises explicitly compose asynchronous func3ons
let findUser = (user) => query.find();
let saveFirstUser = (user) => users[0].save({ key: value });
let assignCurrentUser = (user) => {
currentUser = user;
};
Parse.User.logIn("user", "pass")
.then(findUser)
.then(saveFirstUser)
.then(assignCurrentUser);

Decomposi)on is about en))es

Composi'on is about rela'onships

Back to decomposi.on

extrac'ng named func'ons
The most obvious form of
decomposi2on

Extrac'ng func'ons works from the
inside-out

extrac'ng named func'ons
Decomposi)on of Implementa)on

Let's look at something else

pluck: "A convenient version of what is
perhaps the most common use-case for map,
extrac8ng a list of property values."

let pluck = (collection, property) =>
collection.map( (obj) => obj[property] );
var deStijl = [
{name: 'Theo van Doesburg', occupation: 'theorist'},
{name: 'Piet Mondriaan', occupation: 'painter'},
{name: 'Gerrit Rietveld', occupation: 'architect'}];
pluck(deStijl, 'name')
//=> ["Theo van Doesburg", "Piet Mondriaan", "Gerrit Rietveld"]

func%ons have interfaces
pluck's interface has two parts: The
collec0on, and the property

manually decomposing pluck's interface
let pluckFrom = (collection) =>
(property) => pluck(collection, property);
var deStijl = [
pluckFrom(deStijl)('name')

manually decomposing pluck's interface
let pluckWith = (property) =>
(collection) => pluck(collection, property);
var deStijl = [
pluckFrom(deStijl)('name')

pluckFrom and pluckWith
par'ally apply pluck

Par$al applica$on decomposes
func$ons from the outside-in

par$al applica$on
Decomposi)on of Interface

Decorators

A decorator is a higher-order
func1on that takes a func1on, and
returns another func1on that adds
to or modiﬁes its argument's
behaviour.

par$al applica$on decomposes a func$on from the
outside-in
let pluck = (collection, property) =>
collection.map( (obj) => obj[property] );
// decomposes into:

extract closed-over binding
// becomes:
let leftApply = (fn, a) =>
(b) => fn(a, b);
leftApply(pluck, collection);

Closed over bindings can be
extracted, just like parameters

Decomposing pluckFrom into
leftApply gives us a decorator

leftApply is a decorator that
decomposes a func1on's interface

hmmmm
What does
leftApply(leftApply,
leftApply) do?

back to par*al applica*on
let rightApply = (fn, b) =>
(a) => fn(a, b);
let pluckWith = (property) =>
rightApply(pluck, property);

more decomposi+on with par+al applica+on
let get = (object, property) =>
object[property];
get({name: 'Gerrit Rietveld'}, 'name')
//=> Gerrit Rietveld
let getWith = (property) => rightApply(get, property);
let nameOf = getWith('name');
nameOf({name: 'Gerrit Rietveld'})
//=> Gerrit Rietveld

more decomposi+on with par+al applica+on
let map = (collection, fn) =>
collection.map(fn);
let mapWith = (fn) => rightApply(map, property);

Back to composi,on

Simple Composi+on

let compose = (a, b) =>
(c) => a(b(c));

compose in ac&on
var deStijl = [
let pluckWith = compose(mapWith, getWith);
let namesOf = pluckWith('name');
namesOf(deStijl)
//=> ["Theo van Doesburg","Piet Mondriaan","Gerrit Rietveld"]

pluckWith =
compose(mapWith, getWith);
compose wires the output of one
func/on into the input of another

reminder:
We compose en**es to make the
rela*onships between them explicit

More Composi+on

let mix = (...ingredients) => console.log('mixing', ...ingredients);
let bake = () => console.log('baking');
let cool = () => console.log('cooling');
let makeBread = (...ingredients) => {
mix(...ingredients);
bake();
cool();
}

composi'on with before
let before = (fn, decoration) =>
(...args) => {
decoration(...args);
return fn(...args);
};
let bakeBread = before(bake, mix);
let makeBread = (...ingredients) => {
bakeBread();
cool();
}

before makes the )me rela)onship
between two func)ons explicit

composi'on with after
let after = (fn, decoration) =>
(...args) => {
let returnValue = fn(...args);
decoration(...args);
return returnValue;
};
let bakeBread = before(bake, mix);
let makeBread = after(bakeBread, cool);

after also makes the +me
rela+onship between two func+ons
explicit

decomposing before
let beforeWith = (decoration) =>
rightApply(before, decoration);
let mixBefore = beforeWith(mix);
let bakeBread = mixBefore(bake);

decomposing after
let afterWith = (decoration) =>
rightApply(after, decoration);
let coolAfter = afterWith(after);
let makeBread = coolAfter(bakeBread);

beforeWith and afterWith are
combinators that turn func1ons into
decorators that compose behaviour

JavaScript invoca-ons are coloured

coloured decorators
let before = (fn, decoration) =>
function (...args) {
decoration.apply(this, args);
return fn.apply(this, args);
};
let after = (fn, decoration) =>
function (...args) {
let returnValue = fn.apply(this, args);
decoration.apply(this, args);
return returnValue;
};

Why coloured decorators ma0er

bread, revisited
class Bread {
constructor (...ingredients) {
this.ingredients = ingredients;
}
mix () {
console.log('mixing', ...this.ingredients)
};
bake () {
console.log('baking');
}
cool () {
console.log('cooling');
}
make () {
this.mix();
this.bake();
this.cool();
}
}

bread, revisited
class Bread {
// ...
make () {
this.mix();
this.bake();
this.cool();
}
}

Classes can be decorated too

beforeAll
const beforeAll = (behaviour, ...methodNames) =>
(clazz) => {
for (let methodName of methodNames) {
const method = clazz.prototype[methodName];
Object.defineProperty(clazz.prototype, property, {
value: function (...args) {
behaviour.apply(this, args);
return method.apply(this, args);
},
writable: true
});
}
return clazz;
};

afterAll
const afterAll = (behaviour, ...methodNames) =>
(clazz) => {
for (let methodName of methodNames) {
const method = clazz.prototype[methodName];
Object.defineProperty(clazz.prototype, property, {
value: function (...args) {
const returnValue = method.apply(this, args);
behaviour.apply(this, args);
return returnValue;
},
writable: true
});
}
return clazz;
};

be#er bread
let invoke = (methodName) => function (...args) {
return this[methodName](...args);
}
let Bread = beforeAll(invoke('mix'), 'make')(
afterAll(invoke('cool'), 'make')(class {
// ...
make () {
this.bake();
}
})
);

Looking Forward

ES.who-knows-when

be#er bread with class decorator sugar
let invoke = (methodName) => function (...args) {
return this[methodName](...args);
}
@beforeAll(invoke('mix'), 'make')
@afterAll(invoke('cool'), 'make')
class Bread {
// ...
make () {
this.bake();
}
}

method decorators
let methodDecorator = (decorator) =>
function (target, name, descriptor) {
descriptor.value = decorator(descriptor.value);
}
let invokeBefore = (methodName) =>
methodDecorator( (methodBody) =>
before(methodBody, invoke(methodName))
);
let invokeAfter = (methodName) =>
methodDecorator( (methodBody) =>
after(methodBody, invoke(methodName))
);

be#er bread
class Bread {
// ...
@invokeBefore('mix')
@invokeAfter('cool')
make () {
this.bake();
}
}

What have we seen so far?

• Extract func,on
• Promise interface
• Par,al applica,on
• Extract closed-over binding
(more!)

• Simple composi,on
• Composi,on decorators
• Class decorators
• Method decorators

Don't worry about the details!

it's all the same idea
Decomposi)on makes
responsibili)es explicit

and it's all the same idea
Composi'on makes rela'onships
explicit

These ideas ma*er

There are only two hard problems in
Computer Science: Cache
invalida9on, and naming things.

Naming en))es is hard because you
have to ﬁgure out which en))es
need to be named

Naming rela+onships is hard
because you have to ﬁgure out
which rela+onships need to be
named

Combinators do not make naming
easy

Combinators give us a language for
naming things

Do not follow
in the footsteps of the sages.

Seek what they sought.

Reg Braithwaite
PagerDuty, Inc.
raganwald.com
@raganwald

Javascript Combinators (2016)

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Javascript Combinators (2016)

Semelhante a Javascript Combinators (2016) (20)

Mais de Reginald Braithwaite

Mais de Reginald Braithwaite (6)

Último

Último (20)

Javascript Combinators (2016)