ramda: `propOr`/`pathOr` inconsistency

propOr('bar', 'foo')({ foo: undefined }); // -> undefined
pathOr('bar', ['foo'])({ a: undefined });  // -> 'bar'

Both propOr and pathOr define themselves as returning the value if it is non-null; else the ‘or’ value. These two functions should consistently handle undefined

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 16 (11 by maintainers)

Most upvoted comments

Not sure if I should piggy-back on this or open a new issue. I get that it behaves the way the docs say it does, but I am not convinced that this is the right approach.

To restate the issue:

propOr returns the default if it fails a hasOwnValue check, but pathOr returns the default if the path lookup returns a falsy value null, undefined, or NaN. (thanks for the correction @Bradcomp)

I find this to be confusing and inconsistent.

const foo = { bar: null }
R.propOr('hello', 'bar', foo) // null
R.pathOr('hello', ['bar'], foo) // 'hello'

The similarity in the fn names would make you think intuitively that they behave the same way.

Personally, I think I prefer the way this is handled in R.pathOr because it seems more intuitive. Its like using R.path(...) OR (||) the default.

R.path(['bar'], foo) || 'hello' // 'hello'

(Note: its not immediately clear to me how/if this relates to https://github.com/ramda/ramda/issues/1712, apologies if this is a dupe)

@nfantone: I’m going to try very hard to get a release out this weekend. That should be part of it.

It’s worth noting that Sanctuary doesn’t need any *Or functions because the return values of functions such as S.head and S.get are never ambiguous.