Allow fn passed to Async.fromNode to be partially applied

[JamieDixon]

Async.fromNode returns a function that eventually resolves to an Async type once it has been applied to all of its parameters.

This PR is a first-pass at allowing the function returned from Async.fromNode to be partially applied.

• Dependent on Expose a length property for curried functions #477

Note: In its current form this PR will not pass CI until #477 is merged.

[coveralls]

Coverage remained the same at 100.0% when pulling 17ad78c on JamieDixon:fromNode-curry into df5558b on evilsoft:master.

[JamieDixon]

@evilsoft @dalefrancis88 Just letting you know that this one is now ready for review 🙂

[dalefrancis88]

Thanks mate, i'll get some 👀on this tomorrow or overmorrow

[dalefrancis88]

My knowledge around Async is limited, I don't use it. So i believe @evilsoft will need to add context where i've made uninformed statements

@JamieDixon Reviewed with some questions but this is looking good

[dalefrancis88]

@evilsoft I know there is the issue with Async swallowing errors in one particular scenario, for this change, will wrapping this in the curry and the recursive call to fromNode create a similiar scenario?

[evilsoft]

Nah, we should be good with this.
The Async "issue" is actually the desired behavior when dealing with Promises. And it is a behavior of Promises, so we should be good here!

[dalefrancis88]

Per your documentation and our discussions their is a chance that the given function has a length of 0. Would this be a case to return an error?

[JamieDixon]

My understanding at this point is that if the function has a length of 0 then the safest thing to do is assume that it isn't being partially applied, and apply all of the parameters as per usual. This will mean that any code that currently passes a composed or ...args or argument function will continue to work in exactly the same way as it does today.

[dalefrancis88]

That's true, sounds good to me

[dalefrancis88]

We should avoid starting and ending lines with a `

[JamieDixon]

Thanks! Fixed 😃

[evilsoft]

Got a chance to play with this today and found something I think we should address before this is merged in. One of the goals with crocks is to have the currying "just work". With reliance on the length property, we run into some unexpected behavior when we have something like this:

// fn :: Number -> Number -> NodeCB -> ()
const fn = curry(
  target => (value, cb) => {
    target >= value
      ? cb(null, target - value)
      : cb({ message: 'not valid' }, null)
  }
)

Notice how the curried function is of: Number -> (Number, NodeCB) -> (), this should curry out just fine like:

// logIt :: NodeCB
const logIt = (err, data) => {
  log({ err, data })
}

fn(10)(9)(logIt)
//=> { err: null, data: 1 }

fn(10, 19, logIt)
//=> { err: { message: 'not valid' }, data: null }

So, when this curried function is applied to fromNode, it returns the Async and gets into a state where it never fires the callback to resolve/reject the Async.

// desired siggy
// asyncFn :: Number -> Number -> Async Err Number
const asyncFn =
  fromNode(fn)

asyncFn(10)
  .fork(rej => log({ rej }), res => log({ res }))

// returns an Async that is stuck in a "pending" state
// should return a function, ready for the 'value' argument

Will come up with a couple suggestions, but wanted to let you know what I found