DataForm: enable fields to declare a different layout #66531
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
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
louwie17
added
[Type] Enhancement
louwie17
commented
Oct 28, 2024
| @@ -0,0 +1,41 @@ | |||
| /** | |||
There was a problem hiding this comment.
Added a DataForm context to store the field definitions. This way I can more easily manage the layout on a field level without having to make sure I drill down the field definitions.
|
Thanks for keep using the storybook as an example, that's really valuable! 👏 What do you think of doing the reverse example? In the combinedFields story ( There's some other challenges with this approach like making the styles work well together (note how the title "Status" has different styles/font size) that make the current example look a bit weird: 
|
oandregal
reviewed
Oct 29, 2024
packages/dataviews/src/components/dataform/stories/index.story.tsx
Outdated
Show resolved
Hide resolved
oandregal
reviewed
Oct 29, 2024
packages/dataviews/src/types.ts
Outdated
| @@ -536,12 +536,21 @@ export type NormalizedCombinedFormField< Item > = CombinedFormField< Item > & { | |||
| Edit?: ComponentType< DataFormCombinedEditProps< Item > >; | |||
| }; | |||
|
|
|||
| export type FormField = | |||
There was a problem hiding this comment.
Based on what I saw so far, this is the API I was expecting for FormField:
export type FormField =
| string // The field id
| {
id: string; // The field id
layout?: '...';
fields?: FormField[]; // Allows grouping fields
};Some thoughts:
- Why do we need
fieldinFormField? - Can the
form.combinedFieldsAPI be removed? Why do we need both FormField and combinedFields?
There was a problem hiding this comment.
I reckon some of this is pre-existing to this PR. If you think it's too much for this PR, we could do a PR to simplify the implementation first, and then rebase this PR to use that.
There was a problem hiding this comment.
Why do we need field in FormField?
Actually my thought was to use field for the field id instead of id, as field is more clear. We did probably want to replace fields with children to not make it to confusing.
Mostly for this scenario, where what would you do if you wanted to display a horizontal column layout within a panel. Or any horizontal layout in general. In this case we are just grouping fields, without needing to reference a specific field.
It may look like this:
{
id: "status",
layout: "panel",
fields: [
{
layout: 'horizontal' // if we go this route
fields: [ 'status', 'password' ]
}
]
}
We may still want to add an id here as a key, although we could also generate one.
Can the form.combinedFields API be removed? Why do we need both FormField and combinedFields?
Yeah combinedFields can be removed, as this API replaces that functionality. I was thinking of doing that as a follow up. But happy to remove it as part of this PR.
There was a problem hiding this comment.
We did probably want to replace fields with children to not make it to confusing.
Agree to this, it'd make the code clearer.
Why the regular layout can't take children but the panel layout can? The existing combinedFields API worked for both.
There was a problem hiding this comment.
Another thought is: why only the fields that are defined via object in form.fields should have the layout property? It looks like this is optimizing for the current use case (combining status + password), but I wonder if the layout should be part of the Fields API instead?
oandregal
reviewed
Oct 29, 2024
oandregal
reviewed
Oct 29, 2024
louwie17
force-pushed
the
update/dataform_combined_fields_api
branch
from
a707275 to
58150ef
Compare
|
Size Change: +834 B (+0.05%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
louwie17
commented
Oct 31, 2024
| /> | ||
| ); | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Added sticky example, which flows nicer for the inline example.
louwie17
commented
Oct 31, 2024
| typeof field !== 'string' && field.label | ||
| ? field.label | ||
| : definition.label, | ||
| }; |
There was a problem hiding this comment.
I added the label option to the FormField definition, which overwrites the field definition label if provided.
I did this for two reasons:
- This way the individual layouts won't need to worry about this
- The regular layout doesn't handle the label rendering and renders the Edit component directly, which would require us to overwrite the label there anyway.
louwie17
commented
Oct 31, 2024
| if ( | ||
| ! fieldDefinition || | ||
| ( fieldDefinition.isVisible && | ||
| ! fieldDefinition.isVisible( data ) ) |
There was a problem hiding this comment.
Added the isVisible logic here
louwie17
commented
Oct 31, 2024
| visibleFields.push( | ||
| ...normalizeCombinedFields( combinedFields, fields ) | ||
| ); | ||
| } |
There was a problem hiding this comment.
Removed the combined fields related stuff
|
Thanks for the initial review @oandregal, I did some clean up and addressed some of your suggestions. I also left some replies to your above comments.
Good suggestion on the reverse, I end up creating a simple |
gigitux
reviewed
Oct 31, 2024
oandregal
reviewed
Oct 31, 2024
|
Thanks for updating! It looks like the initial status for the layout of the Screen.Recording.2024-10-31.at.17.11.13.mov |
|
Flaky tests detected in 179696f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11910144881
|
|
This is nice, thanks for the effort! The main blocker I see is adding support for |
youknowriad
reviewed
Nov 4, 2024
louwie17
force-pushed
the
update/dataform_combined_fields_api
branch
from
5e91b52 to
ddf996a
Compare
oandregal
force-pushed
the
update/dataform_combined_fields_api
branch
from
179696f to
a813725
Compare
|
Finalized implementing the Also updated the description to better reflect what this PR does. |
oandregal
approved these changes
Nov 20, 2024
|
I'm really excited about this one. I think this is where the power of the DataForm starts to show up. Thank you all for the collaboration. |
louwie17
commented
Nov 20, 2024
| return { | ||
| id: child, | ||
| }; | ||
| } |
There was a problem hiding this comment.
Currently we have this same logic in the panel and regular layouts, which is very similar to the normalizeFormFields function ( I believe I implemented this ). I think we could call that instead:
return normalizeFormFields( {
type: 'regular' as const,
fields: field.children
} );
This is something I can do as a follow up PR as this works fine as is.
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?
This PR enables a field to declare a layout different from the one defined by the form.
Why?
In the QuickEdit, we want to display the featured image field using a regular layout, not the panel one. See related conversation.
How?
string, aSimpleFormField, or aCombinedFormField.labelPositionas a prop toformas well as the field (eitherSimpleFormFieldorCombinedFormField). The valid values aretop(default forregularlayout),side(default forpanellayout), ornone.For example:
How
labelPositionworks with panel layout (using thetitlefield as an example):topside(default)noneHow
labelPositionworks with regular layout (using thetitlefield as an example):top(default)sidenoneTesting Instructions
Test the QuickEdit:
panelcontrols:In the storybook, test the type & labelPosition:
npm run storybook:devand go to the default DataForm story.stickyfield should always be rendered withlabelPosition:sideandlayout: regular.typeandlabelPositionvalues.