AxeWP/wp-graphql-gravity-forms

Address Field Enum for State / Province when `addressType` is US or Canada respectively

natac13 opened this issue · 3 comments

natac13 commented

What problem does this address?

When an AddressField has its addressType set to US or Canada the country sub field is hidden and the state field turns into a select field.

Because there is a lack of a State / Province enum like the Address Country Enum a frontend is not able to create a select field unless it handles the logic itself.

What is your proposed solution?

With the Address Country Enum the frontend can use typescript Object.values to create an array of select field options.
This allows the frontend to build a select field

Therefore I believe this plugin should expose a Province / State enum. BUT instead of codes for the keys the actual name of the province / state is used so graphql codegen can generate a typescript enum from the graphql province / state enum. Keeping in mind graphql codegen does not handle the graphql enum value but insteads constructs the typescript enum with the graphql enum key only

What alternatives have you considered?

No response

Additional Context

No response

justlevine commented

Something to consider:

While we can directly swap GfFieldWithAddressSetting.defaultProvince and GfFieldWithAddressSetting.defaultState with respective State/Province enums, handling this on fieldValues and mutation inputs are more complicated, since state can be:

  • an AddressFieldStateEnum (when addressType is US),
  • anAddressFieldProvinceEnum (when addressType is CANADA), or
  • any String value (when addressType is INTERNATIONAL).

Possible workarounds:

  • AddressFieldValue: We could make AddressFieldValue.state an enum, add AddressFieldValue.province as the other enum, and add stateOrProvince as a string used for international addresses. However, it adds a bit of cognitive overhead to the schema since you need to know the addressType and when to use state, province, or stateOrProvince` fields.

  • AddressValuesInput: This is less straight forward, but we'd essentially add the above as input fields, and then require stateOrProvince || state, stateOrProvince || province, or just stateOrProvince depending on the field's addressType. This is a bigger issue than the above, since the user now needs to know the addressType to best compose their mutation input variables.

Thoughts before I proceed?

  • 🚀1
justlevine commented

@natac13 I spoke prematurely.

GF doesnt validate the submitted state/province, just populates a dropdown on the frontend if the addressType is set to something other than international. That means we cannot use enums on addressValues, since changing a field's Address Type after submission will break the schema in a way that can only be recovered by manually editing/deleting previous entries.

Which begs the question whether we're gaining anything other than complexity if we add these fields to AddressValuesInput, and my gut tells me probably not.

Since the enums will exist for AddressField.defaultState and AddressField.defaultCountry as CAPITAL_CASE users can still use those generated types and convert them to Title Case...

natac13 commented

Sounds good. just a nice way to generate the select field with the values is all the frontend really needs. It can send a string value for the field input no problem