[Epic] Additional checkout fields API – implement visibility rules

[senadir]

We should add the possibility to filter out additional fields based on an array of options, to do that, we will introduce a visibility rules engine (initially experimental despite the main API being stable).

The architecture of that API is explained here: https://github.com/woocommerce/woocommerce/discussions/42995#discussioncomment-9144308

The work should be split into 6 issues, some of them can be done in parallel:

### Tasks
- [ ] https://github.com/woocommerce/woocommerce/issues/46685
- [ ] https://github.com/woocommerce/woocommerce/issues/46686
- [ ] https://github.com/woocommerce/woocommerce/issues/46687
- [ ] https://github.com/woocommerce/woocommerce/issues/46688
- [ ] https://github.com/woocommerce/woocommerce/issues/46689
- [ ] https://github.com/woocommerce/woocommerce/issues/46690

[senadir]

I'm moving this to blocked for not until we figure out a better visibility system since hiding by country wasn't a requested feature.

[webdados]

Since we're implementing an easy way to create custom blocks, with only a few lines of PHP code, I think we need this to be done outside the scope of "anything more complicated should be implemented as a block or a custom block handler".

I would suggest having a PHP "visibility callback function" that could get all the current fields/values of the form and developers are responsible to just return true or false based on their own rules. It could be country, but it could be anything else, even cascading custom fields, which makes me think of another possibility:

• Having the ability to set dynamic options array on the select field, also based on a PHP "callback function" with access to all the current form fields and values.

[senadir]

For visibility rules we're looking at some to have this work in client and server at the same time, but it should be real time, if you change country, the field should disappear now, it shouldn't wait for a server request before being hidden.

For dynamic options, this is something I'm struggling with as well, in my store, I have this custom field that can have up to 1700 values (basically reimplement the city field to act like State), I don't think returning possible values with existing Cart/Checkout responses is going to work here for the same reason as it have to be real-time or near real time, this is one thing I'm going to tackle in the future and will be possibly via a custom JS wrapper for fields that allows you to fetch the values yourself.

[webdados]

Whatever way things are implemented, server or client side, we need to keep the focus on "non-react developers friendliness", because that's what this API is all about :-)

I do have plugins where we're developing with React all kinds of more complicated stuff on the checkout, but this is not what this project/api is about.

[ralucaStan]

@senadir as discussed please outline the expected outcome, and give some consideration to splitting this ticket

[senadir]

@ralucaStan I split the issue into smaller ones, and shared the expected outcome in the linked comment.

[ralucaStan]

@pmcpinto looks like this one won't be part of cycle 3, as it's not going to be part of the Graduate epic.

[ludsloper]

Any idea on the timeline for this?

[senadir]

We will start working on this some time mid-June (after I come back from WordCamp Europe), tentative release will be whatever WC release that will be, most likely 9.2-9.3

[ralucaStan]

@senadir I've blocked the tickets of this epic. The issues need a clear description. There are some vague points and not a lot of context present. Once we update the tickets we can unblock them.