Should function pipelines be promise-aware?

[briancavalier]

Right now, function pipelines are composed using compose() in lib/functional, which is not promise-aware. We could (fairly easily) create a promise-aware version based on when.reduce(). That'd allow any function in a pipeline to return a promise, and the pipeline would still work out.

This change would also allow the compose factory to compose functions that return promises.

There would be a small perf hit, of course. The tradeoff is probably that all synchronous pipelines will be slightly slower (probably only noticeable if the pipeline is used in a tight loop), but async pipelines become possible.

Performance in async pipelines is likely to be completely dominated by the time of the async operations themselves, so I don't see any perf concerns there.

Seem like a good idea to me, and fits with wire's general "we handle the async for you" model, but want to see what others think.

[briancavalier]

There is a trick here. We can't simply make all function compositions async. The reason is that it forces the composition to return a promise. That's bad for people creating simple compositions and injecting them as methods onto components, for example. They'll be expecting a sync composition that returns a value not an async one.

So, I think we need to be careful only to introduce async compositions into places where they will be invisible, such as pipelines created as a side effect of creating a connection, i.e. where the composition's return value can't be observed.

We could additionally provide an explicit mechanism for creating async compositions for times when a user really wants to do that.

[briancavalier]

Implemented in dev. The approach is pretty flexible: when all functions being composed return values (i.e. no promises are returned), then the entire composition returns a value, but when any one function returns a promise, the entire composition will return a promise.

This applies to connection pipelines and to the compose factory.