You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
constarr=[{score: 1},{score: 2}];// This works:_.map(arr,'score');// => [1, 2]// This doesn't:_mapFP('score')(arr);// => Error: func is not a function// Works, but is ugly:_mapFP(item=>item.score)(arr);// => [1, 2]
This is a huge regression for me. Using strings/objects for iteratees has been one of the most important lodash features for me.
Now I'm trying to import lodash methods individually in order to minimize distro size. That forces me to replace chaining with flow, and flow needs FP-style lodash functions.
Compared to chaining, flow is a huge hit on readability by itself, and the inability to use objects/strings for iteratees makes it even worse! 😭 The longer the flow chain, the harder it is to read all those callbacks.
Please let FP-style lodash functions accept non-functions as iteratees. If this is planned, please add it to the roadmap, mentioning the target version number.
🙇
The text was updated successfully, but these errors were encountered:
This is a huge regression for me. Using strings/objects for iteratees has been one of the most important lodash features for me.
Now I'm trying to import lodash methods individually in order to minimize distro size. That forces me to replace chaining with
flow
, andflow
needs FP-style lodash functions.Compared to chaining,
flow
is a huge hit on readability by itself, and the inability to use objects/strings for iteratees makes it even worse! 😭 The longer theflow
chain, the harder it is to read all those callbacks.Please let FP-style lodash functions accept non-functions as iteratees. If this is planned, please add it to the roadmap, mentioning the target version number.
🙇
The text was updated successfully, but these errors were encountered: