Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(head): add optional n elements parameter #5841

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

danielbayley
Copy link

@danielbayley danielbayley commented Apr 8, 2024

For example:

const array = [1, 2, 3, 4]

_.head(array, { n: 2 }) // [1, 2]
// or
_.first(array, { n: 2 }) // [1, 2]

_.head(array) // 1

[array].map(_.head) // [1]

@Trott
Copy link

Trott commented Apr 8, 2024

I imagine this breaks usage of .head() as a callback with Array.prototype.map() and similar functions. map() sends the index of the array as the second argument to the callback. With this change, that will now affect how many elements are returned.

@Trott
Copy link

Trott commented Apr 8, 2024

Currently, head() always returns the first element.

With this change, head([0,1], 500) returns an array, but head([1], 500) returns 1. Seems like a footgun.

@danielbayley
Copy link
Author

I imagine this breaks usage of .head() as a callback with Array.prototype.map() and similar functions. map() sends the index of the array as the second argument to the callback. With this change, that will now affect how many elements are returned.

@Trott Fair point. My first contribution to this project, so not entirely sure what the design goal specifics are… But my assumption was that pure functional methods—with strict arity—were for lodash/fp?

Anyway, just pushed a fix to avoid said potential foot injuries!

An alternative approach might be to have something like headN/firstN additional methods…

@Trott
Copy link

Trott commented Apr 9, 2024

My first contribution to this project, so not entirely sure what the design goal specifics are… But my assumption was that pure functional methods—with strict arity—were for lodash/fp?

Yeah, I'm not a maintainer or even much involved in lodash whatsoever. So feel free to disregard for the reasons you state and await a review from a project member.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants