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)
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 ahasOwnValue
check, butpathOr
returns the default if the path lookup returnsa falsy valuenull
,undefined
, orNaN
. (thanks for the correction @Bradcomp)I find this to be confusing and inconsistent.
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 usingR.path(...)
OR (||
) the default.(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 asS.head
andS.get
are never ambiguous.