fix(compat/dropRight): clean up JSDoc by removing duplicate overload and guard param#1789
fix(compat/dropRight): clean up JSDoc by removing duplicate overload and guard param#1789Antoliny0919 wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Antoliny0919
left a comment
Antoliny0919
left a comment
There was a problem hiding this comment.
I left a few comments on things I was curious about while making the changes, as I wanted to better understand the project 😉
| * // 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)) { |
There was a problem hiding this comment.
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? 🤔
| * @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`. |
There was a problem hiding this comment.
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?
1 participant
Summary
I don't think this is something consumers of dropRight need to be aware of when using the function directly.