Message from JavaScript discussions

March 2017

— Which is why you encapsulate those moving parts in OOP


Take a basic FP concept, a projection. A projection is a string of functions combined to create a single result.
Here's the most basic way to do it:

var myResult = myFunction(myFunction2(myFunction3()));

And here's a way to do it which makes both more readable and less verbose:
var myResult = run(myFunction1, myFunction2, myFunction3);

Finally, here's another way to do it which involves OOP, and requires each function to return myObj, a concept jQuery users may be familiar with:
var myResult = myObj.myFunction().myFunction2().myFunction3().value();

All 3 examples do the same thing in terms of giving Function A's output to Function B's input and so on.

— The last one, because it is a combination of FP and OOP, happens to be not only the easiest to write, but also the easiest to read.

Message permanent page

— (the .value() function at the end runs the projection)

— There is also the case of the OOP-only projection, something you might see in Flux, in which sections of code are represented by flat objects like so:

actionName: "doSomething",
parameters: 123
}, {
actionName: "doSomething2",
parameters: 456

this is by far the most verbose method, however the reason it is used is to adhere as closely as possible to the law of demeter. In reality, at least in the frameworks I've made and seen, the nitty gritty that runs this type of code makes heavy use of FP a priority.

Message permanent page

— Wait wat

— Why is there a new package manager every time I want to finally use full modern best practices instead of jquery

Message permanent page

— Bower, npm

— And now... there's suddenly yarn? wat? where did that come from?

— Lol

— They actually have their own discord

— notafile But yarn is much faster than npm but has the same packages