Lodash: Refactor away from _.clamp()
#41735
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tyxla
added
[Type] Performance
tyxla
requested review from
mirka,
gziolo,
swissspidy,
ciampo,
chad1008,
ntsekouras and
fabiankaegy
|
Size Change: +184 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
ciampo
reviewed
Jun 15, 2022
Comment on lines
+62
to
+64
| * @param {number} value The value. | ||
| * @param {number} min The minimum range. | ||
| * @param {number} max The maximum range. |
There was a problem hiding this comment.
These 3 parameters are marked as non-optional, but they are assigned a default value in the function's signature — wouldn't this kind-of make them optional?
There was a problem hiding this comment.
Good point 👍 I've actually gone and removed the default values. They actually make the function pretty meaningless if you ask me. If we want to clamp something, we better provide the right boundaries.
| * | ||
| * @return {number} The clamped value. | ||
| */ | ||
| export function clamp( value = 0, min = -Infinity, max = Infinity ) { |
There was a problem hiding this comment.
Looking at types for lodash's clamp, the min argument can be omitted (the function seems to have 2 different signatures, one with 3 arguments and one with 2 arguments).
Although it looks like throughout the repo we always use the version with 3 arguments, and so it's probably ok go forward with these changes
There was a problem hiding this comment.
I actually intentionally didn't replicate this behavior, because I find it ambiguous. Actually, usages like this are one of the primary reasons for my desire to remove any Lodash 😉 It tolerates so much, but that makes the code so ambiguous and error-prone. And we don't use that here, so what better reason to keep it simple.
| @@ -37,6 +37,27 @@ describe( 'subtract', () => { | |||
| } ); | |||
| } ); | |||
|
|
|||
| describe( 'clamp', () => { | |||
| it( 'should clamp a value between min and max', () => { | |||
There was a problem hiding this comment.
Since all tree arguments are optional/have default fallback values, should we add tests for when some/all arguments are not provided?
There was a problem hiding this comment.
Good point, but that's no longer necessary since I removed the default values as I mentioned above.
|
Thanks a bunch for the feedback @ciampo! I think this is ready for another 👀 |
chad1008
approved these changes
Jun 15, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Lodash's
clampis used only a few times in the entire codebase, and it's only in the components package. This PR aims to remove that usage.Why?
Lodash is known to unnecessarily inflate the bundle size of packages, and in most cases, it can be replaced with native language functionality. See these for more information and rationale:
@wordpress/api-fetchpackage haslodashas a dependency #39495How?
Removing
clampis straightforward in favor of a simple custom implementation that does aMath.max()andMax.min(). Since we already have aroundClamp()utility function in the package, it made sense to abstract theclamp()part into its own. We're adding some tests as well. We're not exporting the utility function outside of the package intentionally, but that can easily be done if necessary.Testing Instructions
npm run test-unit packages/components