Message from JavaScript talks

June 2017

— I just prefer passing and returning functions rather than objects

— 

Probably not the best example, but just as easy as objects:

const header =
await getResponseHeaders(url);

header('location');

— Headers work better as objects, but heh

— I usually combine it with the revealing module pattern in several scope layers, in which the innermost layer can access a single object containing all members, then the next highest scope gets a different object with references to only the public members.

Like this, in a factory:

 
var self = {};
self.private = {
hello: "world"
};
self.public = {
what: "is up?"
};
var combined = Object.assign({}, self.public, self.private);


In a large framework I then return combined to the next highest scope which may contain the friend classes or the event bus to them, then return public to a userspace scope (the original caller).

Message permanent page

— So in a class instantistion there may be multiple objects flying around in the background, while the user only gets the public one. This usually requires special thunks instead of letting the user instantiate the classes directly

Message permanent page

— Interesting

— Complicated, but interesting

— Heh, I always try to keep my functions tiny

— Like this:

function newThing () {
var thing = new Thing();
sendFriends(thing.combined);
return thing.public;
}

Message permanent page

— I see

— I don't think I've ever had the need to share privates with 'friends' that can't just be public

— And the function definition for the thunk must be scope restricted so that it may see the event bus or friend classes, while the user cannot

Message permanent page