Support Fantasy Land / Custom Types

[JAForbes]

Thank you everyone for their hard work on this project and lodash/fp. Anything that encourages composition is a huge win for the JS ecosystem.

I'm proposing that Lodash supports dispatch to methods on custom types. This is the number one feature I miss when using lodash/fp in place of Ramda.

An example: say I am using a Bluebird promise that has the methods filter, reduce and map. With Ramda I can use R.filter, R.reduce and R.mapto dispatch to these methods on the Promise.

var R = require('ramda')
var Promise = require('bluebird')

var numbers = Promise.all([1,2,3,4])

var f = R.pipe(
  R.map(R.multiply(2))
  ,R.filter( R.gt( R.__, 4))
  ,R.sum // dispatches to Promise::reduce
)
await f(numbers) //=> 14

f([1,2,3,4]) //=> 14

This dispatch allows you to write one function that can traverse multiple data types. You could just as easily pass in a fantasy land compatible stream like most.js or flyd. Or a Future, Task, Maybe, Either etc. And most importantly it would support any type that the user may want to develop within their own code base.

Note that above we don't need to concern ourselves with chaining .then calls. We have abstracted away the specifics of the underlying type. And now the function f (from above) would work equally well on an array, or a hundred other types.

Lodash is such an important part of the JS ecosystem, I would see supporting this functionality as both extremely useful and also a vote of confidence in composition.

[jdalton]

Thanks @JAForbes!

Lodash and Underscore used to dispatch to methods here and there. Over time that was pulled. I can see the benefits for sure. It can also introduce accidental dispatching since it's just duck typing. I dig giving devs options though, and I'm curious if lodash/fp could implement it in a configurable way.

We'll keep an eye on the popularity of the request.

Related to #527.

[barneycarroll]

Accidental duck typing is theoretically precluded by the fantasy land specification, no? By opting in to APIs that explicitly conform to the spec, the user should be able to isolate any such accidents — and by deferring to the spec, any implementation washes it's hands shares responsibility for producing rational outcomes. Which isn't to say fantasy land adherence guarantees a totally procedural conversion task for Lodash's entire API — but duck typing is part and parcel of the exercise, as it were.

I think this should be developed as a persistent fork with the aim of replacing / providing a 'stronger' flavour of the current FP branch.

[Avaq]

It can also introduce accidental dispatching since it's just duck typing

It's worth noting that Fantasy Land might move to prefixing its functions (fantasyland/fantasy-land#122), to reduce the chances of ducktyping clashes.

[JAForbes]

@jdalton The Fantasy Land spec now prefixes all function names. So name collisions are no longer an issue when implementing the specification.

[gunar]

How many more votes do we need?

[jdalton]

Voting is used as an indicator to see what features folks are interested in. There is no magic number that will force me to implement something. I use this metric to make better informed API decisions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.