Indicate nested paths on __experimentalSaveSpecifiedEntityEdits #54161
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
matiasbenedetto
added
[Type] Enhancement
16 tasks
|
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
|
3 tasks
jffng
reviewed
Sep 5, 2023
There was a problem hiding this comment.
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 <jonger4@gmail.com>
Co-authored-by: Jeff Ong <jonger4@gmail.com>
|
@jffng those are good suggestions. |
tyxla
reviewed
Sep 11, 2023
There was a problem hiding this comment.
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.
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.
@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.
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.
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 <8436925+tyxla@users.noreply.github.com>
jffng
approved these changes
Sep 12, 2023
There was a problem hiding this comment.
Thanks for addressing the feedback @matiasbenedetto , components that consume this function still works as expected.
matiasbenedetto
deleted the
try/paths_on__experimentalSaveSpecifiedEntityEdits
branch
|
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 🙌 |
bph
added
[Type] Code Quality
10 tasks
priethor
removed
the
[Type] Code Quality
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?
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
fontFamiliesarray 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 thesettingsobjects may have.How?
The changes make
__experimentalSaveSpecifiedEntityEditsunderstand nested paths instead of only top-level property names.Testing Instructions