feat: add prop to include deep nesting

[ridge-kimani]

Description

• updates the prop function to fetch deeply nested attributes. It works the same way as the path.
• it also ensures it runs faster recursively

closes #3426

Type of change

• feature(non-breaking change which adds functionality)

How Has This Been Tested?

• Run npm test and npm run browser_test

[kedashoe]

Hi @ridge-kimani , we have R.path for this.

[ridge-kimani]

Hello @kedashoe. Yeah sure. I saw the need to add deep nesting to extend R.prop functionality to be similar to R.path.
Is there a major "choice" difference between "Prop" and "Path"? Why would I pick "Prop" over "Path" if I don't have a nested object?
I felt like having the two functions working similarly wouldn't break a sweat if it comes down to picking either or.
It also runs faster compared to the path fn.

[semmel]

As an isolated change, this introduces a great inconsistency in Ramda's API.

Where they now accept a property name, all the various *prop* functions (eqProps, props, propSatisfies, ...) would have to accept property name arrays as arguments too. All the has* functions too – I guess – because they serve a related purpose.

In Ramda, the name "prop" refers to an established mental image/concept which is of great benefit when reasoning about code.

[Berndy]

I have to agree with @kedashoe , this function already exists as R.path. If we really wanted this functionality, I feel like it would make more sense to upgrade R.path to also support props, as it already is the function that does "more"? Or just have a new function that decides whether to call prop or path?

I also ran a quick benchmark of path and this new prop function, and it runs significantly slower when inputting an array. This is likely due to creating a lot of new functions due to using curried and arrow functions, creating some new arrays in reduce and not exiting when possible.

// inputting arrays for nested values
path arr x 5,773,850 ops/sec ±1.52% (20 runs sampled)
prop arr x   158,810 ops/sec ±0.62% (24 runs sampled)

// inputting string / [string] to get prop
path str x 4,316,608 ops/sec ±0.88% (23 runs sampled)
prop str x 4,556,412 ops/sec ±0.84% (23 runs sampled)

[ridge-kimani]

I've seen it will also have some inconsistencies with other functions like props which rely on it. If there's any significant improvement to be done it would make sense to be in the R.path function.

Thanks for the feedback.

I will close this issue.