Recompose: A reversed alternative to compose

[adrianmcli]

The current implementation of compose() is idiomatic and works great. However, I find that many beginners to functional composition find the ordering to be quite awkward. I propose an alternative function, pipe() where the order of the arguments are reversed (i.e. performing left-to-right composition instead of right-to-left, which is what compose() does).

The Problem

As in the documentation, the current implementation is like this:

const composedHoc = compose(hoc1, hoc2, hoc3)

// Same as
const composedHoc = BaseComponent => hoc1(hoc2(hoc3(BaseComponent)))

However, most people tend to prefer reading function calls from left-to-right, such that they sometimes get confused as to what compose() actually does.

To experienced users, the compose function reads like this:

Wrap hoc1 over hoc2 over hoc3 (and then over the to-be-passed-in component).

But to beginners, they sometimes might read it as:

Wrap hoc1 over the component, and then wrap hoc2 over that, and then wrap hoc3 over that one.

The Proposed Solution

Ramda has compose and pipe.

Perhaps we should have our own pipe() function as well so users can choose to use left-to-right composition? It is trivial to implement, but might be useful in winning more users over to this library.

Since the implementation is so trivial, I may consider submitting a PR for this feature later in the week.

[istarkov]

With compose u can think that enhancers "works" in normal order plz read
https://github.com/acdlite/recompose/issues/235

[istarkov]

I wanna say more: I'm not sure, but I think that all that pipe, flow functions, was introduced to make reading code more easily from top to down like

flow(
x => x * 2,
x => x + 2
)

It's easy to read this expression, take x multiply it on 2, then add 2,
but in recompose usual compose do the same, so you can read enhancers top down

compose(
  mapProps(({ x }) => ({x : x  * 2}))
  mapProps(({ x }) => ({x : x + 2}))
)

will give the same result at BaseComponent for property x as flow above.
So it's already readable.

I think there is no need in pipe operator here, as who is reading the code bottom up.
So no.

[wuct]

Close this issue because it's inactive recently. Please feel free to reopen it.