Feature request: ability to get a null/undefined

Use case example - the ORM I’m using (Objection.js) wants a null or undefined to not update a field. In a situation where the field is optional (e.g. for an update), it would be nice to be able to do something like:

Person.patch({
  firstName: Maybe.of(request.firstName).unwrapOrNull()
})

In this case unsafelyUnwrap() would yield an undefined, which might work in this scenario, but it throws instead.

Thanks for taking a look and for the library (and New Rustacean)!

[bmakuh]

@flyiniggle so this is super interesting to me. I also struggle with the interop question. Obviously if you’re dealing with a language where everything is built with variants in mind, then you never run into uncomfortable situations like you’re describing. To me, I’d like to take a step back for a second into the broader question of design before debating this specific method. How do you build a library like this that creates a “pit of success”? We want to make it very easy to bring data into a type variant rather than dealing with raw nullability, but we don’t want to make it trivial to bring it back out again because then you end up straddling the fence between normal JS ways of doing things and doing things in a type variant kind of way. For example, you could do this:

function MyNeatComponent() {
  const firstName = Maybe.of(this.props.firstName)

  if (firstName.isNothing()) {
    return null
  }

  return (
    <div>{firstName.value}</div>
  )
}

But while I’m an FP nerd and I like modeling missing data with Maybe variants, if I’m intellectually honest, the above doesn’t really warrant bringing in the size and complexity of an additional library when I’m basically just doing this:

function MyNeatComponent() {
  const { firstName } = this.props

  if (!firstName) {
    return null
  }

  return (
    <div>{firstName.value}</div>
  )
}

It’s a trivial example and doesn’t reflect real-world data complexity, but now in a world where we have ?. and ?? operators, it’s honestly pretty trivial to handle nullability without having to litter your code with big null guard blocks everywhere. I still would prefer to handle uncertainty “at the edge of the system” so to speak so that I have data guarantees throughout the rest of the app, but what does that actually have to look like? If we were to design the next major version of True Myth with these new operators in mind, what value proposition would True Myth provide?

Another way to say it is, how do we provide the niceties that monadic variants like Maybe and Result give you while also acknowledging that JavaScript is what it is and not trying to make it into something that it’s not? To me, I find it to be a very nice experience to be able to map, ap, etc. and do data transformations on a piece of data without having to worry about whether it exists or not.

I work with libraries like React and Sequelize and various native DOM APIs that assume “nothing” will be represented by null or undefined, so I would also like to have a really killer interop story that would sell itself. I’d just love to solve that at the design level rather than just growing the library organically by adding a method here and a method there; let’s make sure the design “fits” with plenty of use cases. Thoughts?

[bmakuh]

Cool cool. @atrick-speedline if you’re still interested in this feature, feel free to file the PR.