Flip andThen parameters for better currying [breaking change]

[MazeChaZer]

Right now, the signature of andThen is

andThen(decoder, fn)

Changing the order of the parameters to

andThen(fn, decoder)

would adhere to the idea that you first pass configuration into the function, and later the data the function operates on.

Elm also did this change in 0.18: https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.18.md#backticks-and-andthen

[MazeChaZer]

Ramda also takes this approach:

The parameters to Ramda functions are arranged to make it convenient for currying. The data to be operated on is generally supplied last.

http://ramdajs.com/

[ooesili]

I don't really see any benefit in doing this, since JavaScript does not support currying or the pipeline operator. I'd love to hear an argument on this though.

[MazeChaZer]

I am aware that this change doesn't give much advantage when it comes to currying or pipelining because JavaScript doesn't support this (yet?). For me, this is more about a consistent rule how function arguments are ordered. I don't want to think about or look up what the order of the arguments is, it helps me, if that just follows a simple rule. Right now map looks like map(fn, decoder) and andThen looks like andThen(decoder, fn). Additionally, people coming from Elm won't be irritated. Elm is not yet very popular, but if you have ever done some stuff in Elm and you have to come back to TypeScript, you probably want Elm-like JSON decoders, and this is the only good and maintained library that I know of.

[MazeChaZer]

I don't use this library anymore, closing after no response for a few months.

[ooesili]

Sorry for the radio silence, work has been keeping me super busy. I've actually been thinking about this quite a bit, and I have a little regret with the way I designed this library. I tried to make the API as close to Elm's as possible, and I think I should have embraced the OO part of JavaScript more.

decoder.map(fn)
decoder.andThen(fn)

I think this fits better into the JavaScript/TypeScript world, and I could get rid of a weird hack in the source code that I had to make in order to allow "package private functions". Any thoughts?

[MazeChaZer]

This is a conflict I've been struggeling with, too. For my current project and for my JSON decoder I just used functions everywhere, just like Ramda. The advantage is that I can discard all the strange OO-stuff in JavaScript and just work with functions and values. The problem with this approach is that you can't really hide implementation details, because TypeScript doesn't have features like opaque types. I think both approaches are valid in the current JavaScript landscape and your suggestion looks reasonable to me.