Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 5 additions & 23 deletions src/compat/array/dropRight.ts
Original file line number Diff line number Diff line change
Expand Up @@ -10,40 +10,22 @@ import { toInteger } from '../util/toInteger.ts';
* of elements removed from the end.
*
* @template T - The type of elements in the array.
* @param collection - The array from which to drop elements.
* @param array - The array from which to drop elements.
* @param itemsCount - The number of elements to drop from the end of the array.
* @param [guard] - Enables use as an iteratee for methods like `_.map`.
* @returns A new array with the specified number of elements removed from the end.
*
* @example
* const array = [1, 2, 3, 4, 5];
* const result = dropRight(array, 2);
* // result will be [1, 2, 3] since the last two elements are dropped.
*/
export function dropRight<T>(array: ArrayLike<T> | null | undefined, n?: number): T[];
export function dropRight<T>(array: ArrayLike<T> | null | undefined, itemsCount?: number): T[];

/**
* Removes a specified number of elements from the end of an array and returns the rest.
*
* This function takes an array and a number, and returns a new array with the specified number
* of elements removed from the end.
*
* @template T - The type of elements in the array.
* @param collection - The array from which to drop elements.
* @param itemsCount - The number of elements to drop from the end of the array.
* @param [guard] - Enables use as an iteratee for methods like `_.map`.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that many other places also expose the guard parameter in the JSDoc. Is there a reason for documenting guard explicitly?
As described in the docs, I understand that it's there to support cases where the function is passed as an iteratee to methods like map(for Lodash compability...), but I'm wondering if this is something users actually need to know about.
Would it be better to keep this as an internal implementation detail?

* @returns A new array with the specified number of elements removed from the end.
*
* @example
* const array = [1, 2, 3, 4, 5];
* const result = dropRight(array, 2);
* // result will be [1, 2, 3] since the last two elements are dropped.
*/
export function dropRight<T>(collection: ArrayLike<T> | null | undefined, itemsCount = 1, guard?: unknown): T[] {
if (!isArrayLike(collection)) {
Comment on lines -40 to -43

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that most implementation signatures also include JSDoc. Is there a reason we document those as well?
When overload signatures are present, some of that information seems redundant to me. Am I missing something? 🤔

export function dropRight<T>(array: ArrayLike<T> | null | undefined, itemsCount = 1, guard?: unknown): T[] {
if (!isArrayLike(array)) {
return [];
}
itemsCount = guard ? 1 : toInteger(itemsCount);

return dropRightToolkit(toArray(collection), itemsCount);
return dropRightToolkit(toArray(array), itemsCount);
}