enhance: update path to use prop function

[ridge-kimani]

Description

• updates the R.path to reuse the prop function.

Type of change

• chore(non-breaking change which adds functionality)

Closes #3429

How Has This Been Tested?

• Run npm test and npm run browser_test

[kedashoe]

ty for the PR @ridge-kimani , however I don't see the need to refactor here unless you can prove this version is faster which it seems to me it would not be.

[ridge-kimani]

@kedashoe there are some significant improvements in performance. For the test cases, the highest runtime was at 1.6s compared to 1.4s for this case. The obj null check also comes before the loop.

[kedashoe]

Running tests isn't meant to be used as a benchmark, too much noise. I built a quick benchmark and the current impl is significantly faster

│ this-pr                │ 3,186,532              │ 0.53%                  │
├────────────────────────┼────────────────────────┼────────────────────────┤
│ current                │ 5,016,350              │ 0.19%                  │

[Berndy]

I'm a bit late to the party, but I have thought about this as well... I think it makes sense to only have a single definition how we get properties from an object, the same way we use nth everywhere to get a value form an array/string or path to get a nested value.

The performance hit here almost certainly comes from calling a curried version of R.prop. We'd have to move an uncurried version to an internal file and replace the usage of the curried version everywhere, similar to how nth and path were refactored in my earlier PR. This would result in some performance gain for all prop related functions, with this refactor being a nice side effect.

Also the null check needs to stay in the for loop as we want to escape as soon as we hit any null-ish value.

[kedashoe]

I think it makes sense to only have a single definition how we get properties from an object, the same way we use nth everywhere to get a value form an array/string or path to get a nested value.

For me the reason using/optimizing nth makes sense is that it is doing more stuff (checking for negative indexes, checking if target object is a string). Having a single definition for getting properties might be nice, but as ramda is a library, it is more important for me what our users experience than what we experience writing the library, ie performance is more important than that our code is nice.

Can we really make _path faster by replacing a plain js val = val[p]; with a call to an internal _prop function?

Having said that, a PR for an internal _prop function that does not use currying to replace our current calls to prop would make sense to me.