Lodash: Refactor away from _.set() in global styles#52279
Conversation
94b2cd9 to
6500e0f
Compare
There was a problem hiding this comment.
Pretty straightforward to trace - result is already declared to be an object, and setting is already a string, which is handled just fine by setImmutably once we split it to an array path.
There was a problem hiding this comment.
Simplifying because we don't need to deep clone - setImmutably will already do that.
There was a problem hiding this comment.
We just have to split contextualPath to an array path to have it properly handled by setImmutably.
There was a problem hiding this comment.
We just have to split finalPath to an array path to have it properly handled by setImmutably.
There was a problem hiding this comment.
Simplifying because we don't need to deep clone - setImmutably will already do that.
|
Size Change: -19 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
53afeeb to
19bff9b
Compare
19bff9b to
2ffb692
Compare
|
Ready for a review after #52280 landed. |
|
Flaky tests detected in 2ffb692. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5483183123
|
Mamaduka
left a comment
There was a problem hiding this comment.
The changes look good to me, and I couldn't spot any regressions when working with Global Styles.
What?
This PR removes Lodash's
_.set()from the global styles hooks.We have a few more usages of
set()left in the codebase, but we might have to tread carefully, since some of them may have to deal with Unicode characters, and I prefer testing them one by one.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?
We're replacing the usage with the existing
setImmutablyutility function, which we're already utilizing in a few other places.Testing Instructions