Add isVisible option to fields within DataForm

[louwie17]

What?

This adds the isVisible callback to the field type for determining if a field should be visible within DataForms.
It also adds a dependency array option that gets used by the isVisible callback. By default it only listens to the field value for changes.

Why?

This solves the problem for dynamically showing/hiding fields within the form that depend specific field values. For example we want to hide the password field when the post status is set to private, but display it otherwise. Instead of filtering the form.fields list at the top level, this allows us to handle this on a per field level.

How?

It adds a isVisible callback that passes the data being edited. It should return a boolean.
In addition, there is a dependency array, that works similar as the dependency array passed to useMemo or useEffect calls. It takes a list of keys that the isVisible function may depend on.

In the case of the password field, it depends on the status field. So it would take dependency: [ 'status' ] and the isVisible function will only be run if status changes.

Testing Instructions

1. Run storybook npm run storybook:dev
2. Go to the DataViews > DataForm storybook
3. Switch the status to private in the sample data form and notice how the password field disappears

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

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

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

[louwie17]

Both of these options may not make sense in the DataViews context? In which case we should create a specific DataFormField type.

[oandregal]

We have the same with isValid or sort. It's tempting to create separate "field types" for DataViews and DataForm but I don't think it's worth it right now. The consumers of this code will declare fields only once for both.

[louwie17]

@youknowriad and @oandregal here is the initial proposal for the isVisibility option.

[oandregal]

@louwie17 I've left some minor comments and the PR needs rebasing. Other than that, I think this is good!

[youknowriad]

I'm a bit skeptical about this personally. I'm not sure if this should be an isVisible API for a field or some kind of "rules" definition passed to the DataForm. I think isVisible might not be flexible enough and it might also be not a generic enough API for field registration.

That said, I'm ok iterating if you feel like this is a good first step.

[louwie17]

I'm a bit skeptical about this personally. I'm not sure if this should be an isVisible API for a field or some kind of "rules" definition passed to the DataForm. I think isVisible might not be flexible enough and it might also be not a generic enough API for field registration.

That said, I'm ok iterating if you feel like this is a good first step.

Yeah I like the "rule" definition approach, and was thinking we should add support for the rule parser when that is finalized that Nadir is working on.
But decided to just stick with a simple function for now, as that keeps it very flexible on the JS side. We can later on add support for a rule based definition.

[louwie17]

@louwie17 I've left some minor comments and the PR needs rebasing. Other than that, I think this is good!

Thanks for the review and feedback @oandregal, I updated the PR with your feedback. It should be ready for a re-review for when you have time :)