Skip to content
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

DataForm: centralize edit logic in field type definitions #64171

Merged
merged 2 commits into from
Aug 1, 2024

Conversation

oandregal
Copy link
Member

Part of #59745
Follow-up to #64164 and #64168

What?

Centralizes the edit logic for fields into the field type definitions.

Why?

Follows suit what we did for validation and sorting.

How?

Moves the DataForm controls to the corresponding field type definition.

Testing Instructions

  • With the "quick edit" experiment enabled, visit the Pages page.
  • Switch to the table view, select a row (multi-selection also works), and open the quick edit action.
  • Modify the values and verify that it works as expected.

Copy link

github-actions bot commented Aug 1, 2024

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <[email protected]>
Co-authored-by: youknowriad <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@oandregal oandregal added [Type] Code Quality Issues or PRs that relate to code quality [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Aug 1, 2024
@oandregal oandregal mentioned this pull request Aug 1, 2024
21 tasks
@@ -156,6 +167,19 @@ export type Form = {
visibleFields?: string[];
};

export type DataFormProps< Item > = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting this one here, means we should also put the DataViewsProps here rather than collocating by the file. So far for this kind of components we kept the types collocated though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 40043fc I collocated DataFormProps back into the component.

DataFormControlProps still lives in the types file: it's required there and there are multiple places where it's used (every type definition). Is there a better place for this one?

@oandregal oandregal enabled auto-merge (squash) August 1, 2024 13:15
@oandregal oandregal merged commit 58166db into trunk Aug 1, 2024
62 checks passed
@oandregal oandregal deleted the update/field-type-definition-edit branch August 1, 2024 13:20
@github-actions github-actions bot added this to the Gutenberg 19.0 milestone Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants