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

DataViews: Refactor the edit function to be based on discrete controls #64404

Merged
merged 1 commit into from
Aug 12, 2024

Conversation

youknowriad
Copy link
Contributor

Related #59745
Follow-up to #64370

What?

In #64370 The notion of "controls" has been introduced to the DataForm, this PR expands on that notion and transforms all the existing field types to rely on controls.

So a Field can say Edit: "radio" but a Field Type can also say Edit: "radio".

One advantage as well is that we can remove the duplication of the "select" control between the different types and factor it in the getControl function.

Testing Instructions

There should be no impact on any public API or feature, this is a code quality change. You can check that the DataForm story is still the same.

@youknowriad youknowriad 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 9, 2024
@youknowriad youknowriad self-assigned this Aug 9, 2024
Copy link

github-actions bot commented Aug 9, 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: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>

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

@youknowriad
Copy link
Contributor Author

One thing I noticed and that I would like to improve separately is that the "label" of the "datetime" control look very different than the other. I understand that we used a fieldset... but I believe that visually we should make it look the same.

Screenshot 2024-08-09 at 6 26 15 PM

}

export function getControlByType( type: string ) {
if ( Object.keys( FORM_CONTROLS ).includes( type ) ) {
return FORM_CONTROLS[ type ];
}

return null;
throw 'Control ' + type + ' not found';
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean that, for TypeScript, getControlByType always returns a control? When implementing this same idea the issue I had was working with the null through all the chain of components.

Copy link
Contributor

Choose a reason for hiding this comment

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

We we need to throw an error here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason, is what @oandregal said above, it's the way to force typescript to consider that this function should always return a defined control.

Copy link
Member

@oandregal oandregal left a comment

Choose a reason for hiding this comment

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

I hadn't tested it but looks good.

I strongly prefer that dataform-controls live within src/components. As I mentioned here, the current folder layout doesn't help navigating and understanding the codebase. This is not a blocker, of course.

@youknowriad
Copy link
Contributor Author

I strongly prefer that dataform-controls live within src/components.

I understand, I wouldn't mind too much either but for me we have clear "concepts" or "abstractions": layouts, field types, controls... and these are not just components for me, they can have labels, sorting functions, icons... So putting them under src/components feels weird. Maybe we should just remove the src/components folder and move everything top level but in that case it's just a way to say "other things".

@youknowriad youknowriad merged commit 4a8b166 into trunk Aug 12, 2024
71 of 72 checks passed
@youknowriad youknowriad deleted the update/dataviews-controls branch August 12, 2024 09:47
@github-actions github-actions bot added this to the Gutenberg 19.1 milestone Aug 12, 2024
getdave pushed a commit that referenced this pull request Aug 14, 2024
#64404)

Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
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.

3 participants