Unclear purpose

I got here from your medium article. I’m a long time javascript ninja and am a fan of cleanliness and efficiency. I’ve built a lot of applications, apis, and libraries. But I still don’t really see the point.

This isn’t a criticism of “maybe” itself (yet). On the contrary, I’m intrigued… (enough to write an issue instead of hitting the back button). I just feel like your examples in the readme are a bit basic and on the surface the only thing I see is that they result in more characters, and inevitably slower execution time than the “problem code”.

And with any optional parameter, at some point you’re going to want it to interact with the rest of your logic in a way that is dependant on what the parameter is. So at the end of the day, you’re going to write if ( val.isJust() ){ ... } instead of if ( val != null || val !== undefined ){ ... } or even if ( !_.isEmpty( val ) ){ ... }

So… I’m not understanding something. Can you provide more concrete use-cases to demonstrate what problem this solves?

[alexanderjarvis]

Then you could do this:

function calculatePrice(item: CartItem, coupon?: Coupon): number {
  const price = maybe(item.salePrice).map(salePrice =>
      maybe(item.expiryDate)
        .flatMap(e => e > Date.now() ? nothing : just(item.price))
        .orJust(salePrice)
    )
    .orJust(item.price)

  return maybe(coupon).map(c => price * (1 - c.discount)).orJust(price)
}

But I would suggest splitting into two functions, one for getting the price and another for applying the coupon.

[wellcaffeinated]

Also, it would be great if there were a dist/ folder with a built and minified version so people have something to use for testing on things like jsperf or jsfiddle or codepen