-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Indicate nested paths on __experimentalSaveSpecifiedEntityEdits #54161
Indicate nested paths on __experimentalSaveSpecifiedEntityEdits #54161
Conversation
Size Change: +9.12 kB (+1%) Total Size: 1.52 MB
ℹ️ View Unchanged
|
Flaky tests detected in de832bf. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6162487003
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, this is looking good to me, I tested this manually by using the site editor Save Hub component and ensuring things were working as expected there, since it is the only other place I can find where this function is used.
I left some minor comments, otherwise LGTM.
Co-authored-by: Jeff Ong <[email protected]>
Co-authored-by: Jeff Ong <[email protected]>
@jffng those are good suggestions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's quite unfortunate to be introducing yet another version of _.get()
in the codebase. After finishing the Lodash migration, my goal was to actually unify the existing getValueFromObjectPath()
ones, rather than create more duplicates of that utility function. Since this utility is needed in various packages, which aren't necessarily interconnected, the best way to do it is in an external package IMHO. Is that something you're interested in doing instead?
* @param {*} defaultValue Default value if the value at the specified path is nullish. | ||
* @return {*} Value of the object property at the specified path. | ||
*/ | ||
export default function getNestedValue( object, path, defaultValue ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a bummer that we're introducing yet another version of that utility function. While migrating away from Lodash we had to introduce (almost duplicate) a few of those in various packages, because this was the very last function to remove and we were willing to make some temporary compromises. But ideally, we should unify them all and avoid to introduce new ones if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tyxla I agree. I think we can merge this and follow up with the creation of the package after.Right now we need this util to launch the Font Library. This change is in use here: #53884
*/ | ||
export default function setNestedValue( object, path, value ) { | ||
if ( ! object || typeof object !== 'object' ) { | ||
return object; | ||
} | ||
|
||
path.reduce( ( acc, key, idx ) => { | ||
const normalizedPath = Array.isArray( path ) ? path : path.split( '.' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that when introducing setNestedValue()
we intentionally kept it array-only. I'd prefer that because it helps keep a simpler and more predictable utility function; while if we support multiple formats and types, it more or less emulates the complex Lodash behavior, which is something we want to avoid.
Also, keep in mind I'm not saying that we shouldn't use the dot notation (x.y.z
). I'm just saying that the normalization part (string to array) can be done outside of the utility function, at the place where we're utilizing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we work on this as a follow-up when we make this a new package?
Hi, thanks for the review!
Yes, I agree that it's unfortunate, but that util function is needed to make this work. I don't have strong preferences around this type of simple util functions. I added it because the Lodash package was removed, and no alternatives were provided.
No, right now, I'm currently working on something else for 6.4, and I won't have time for that. |
Co-authored-by: Marin Atanasov <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the feedback @matiasbenedetto , components that consume this function still works as expected.
I created a new issue as a follow-up of the discussion about re-usability: #54407 |
Addressing the reusability concern in a follow-up sounds good, thanks for considering it @matiasbenedetto 🙌 |
What?
Indicate nested paths on
__experimentalSaveSpecifiedEntityEdits
.Why?
Currently, you can only indicate which top-level properties you want to save using
__experimentalSaveSpecifiedEntityEdits
. We can only do this with the current implementation:This PR enables developers to indicate which nested paths want to be saved into the database. For example, if you made some client side changes to the
fontFamilies
array of the global styles settings (settings.typography.fontFamilies
) and you want to save to the database only those changes instead of all the changes that thesettings
objects may have.How?
The changes make
__experimentalSaveSpecifiedEntityEdits
understand nested paths instead of only top-level property names.Testing Instructions