Tracking issue - Enumeration values limited by GraphQL

[derrickmehaffy]

Describe the bug

This is a tracking issue for all the various references to the limitations of the enumeration field. All other issues, feature requests, and discussions will be closed and redirected here.

Context

Currently within Strapi, the enumeration field is a literal usage of the definition of enumeration data type defined here in which generally speaking a boolean data type is also considered an enumeration type with the value options of true and false.

For Strapi, due to us supporting GraphQL, we have restricted the types of values that can be used based on the following regex provided by Facebook, whom built GraphQL:

Name :: /[_A-Za-z][_0-9A-Za-z]*/
GraphQL query documents are full of named things: operations, fields, arguments, directives, fragments, and variables. All names must follow the same grammatical form. Names in GraphQL are case‐sensitive. That is to say name, Name, and NAME all refer to different names. Underscores are significant, which means other_name and othername are two different names. Names in GraphQL are limited to this ASCII subset of possible characters to support interoperation with as many other systems as possible.

http://facebook.github.io/graphql/#sec-Names

Current behavior

Using the above provided regex /[_A-Za-z][_0-9A-Za-z]*/ values for enums are limited to:

• Must start with a letter, lower or upper OR and underscore _
• May have an infinite sane length
• May only contain upper or lowercase letters, numbers, and underscores

Expected behavior

Requests from users (though not limited to, this will be updated over time)

• Spaces
• Dashes -
• Special characters for different languages
• Alternative symbols

Currently none of the above are allowed, and manually setting them via the model settings may work if you don't have the GraphQL plugin installed, but are not supported and you do so at your own risk until we find a valid replacement.

Related Issues, Feature requests, Discussions, and Forum threads

Please note, the below are not the limit and additional entries may be linked to this issue, you can find them referenced in the comments.

• Original Discussion (very long): https://github.com/strapi/strapi/discussions/4780
• Enum graphql/graphql-js#936 (comment)
• Enumerables don't allow list items with non-alphanumeric characters #4250
• Enumeration Field does not allow for special characters #3921
• Eumeration field special character causes GraphQL error.  #3340
• [Improvement request] Content Type: Enumeration #2494
• Enum value with hyphen breaks #1698
• https://github.com/strapi/strapi/discussions/7208
• Allow '-' & '/' in enumeration type in content type builder #7896
• Content-Type builder doesn't allow specials chars in enum values #7873
• Unable to create list of numeric values.  #7600
• Enumerated values with "/" character break the graphql plugin #7234
• Can't add some another languag character in ENUMERATION from Content-Type #6328
• Enum with multiple times the same value breaks #5343

More will be shown below

Possible workarounds depending on the use case

• Using relations such as oneWay with a storage model for the values (single select)
• Using relations such as manyWay with a storage model for the values (multi select)
• Use a standard enum that fits the regex and map these values out on your frontend (what is currently expected)

To be very clear, we have no ETA on this, please do not reply asking for one.

[imaksp]

EDIT: I think we can ask both field value & its display name for enum type & save it in model json to handle this. & Select menu on edit page can use displayName.

{
  "type": {
    "type": "enumeration",
    "enum": [
      { "value": "en_US", "displayName": "en-US" },
      { "value": "en_GB", "displayName": "en-GB" }
    ],
    "required": true
  }
}

[derrickmehaffy]

yup that was a suggestion made in the original discussion @aksdevac and I think it's a good idea, but we may get some push-back from the rest of the core team about display names within the model settings.

In this case I agree because you can't change these non-display values in production anyway. This solves the issue in the admin, but we also need to figure out how we return these to the user via REST/GraphQL as I'd hazard a guess some will want the display value which GraphQL won't do.

[imaksp]

@derrickmehaffy yes query will return value which is stored in db, but front end can have same mapping.
& for normal/custom rest service server can also return display name, & as you said it will at-least solve issue within admin.

[lauriejim]

This issue has been mentioned on Strapi Community. There might be relevant details there:

https://forum.strapi.io/t/strapi-enumeration-regex/450/2

[finfa]

Looks like there is no way in Strapi to create a simple dropdown of human-readable options without the need of extra database tables and joins. Right?

[derrickmehaffy]

Looks like there is no way in Strapi to create a simple dropdown of human-readable options without the need of extra database tables and joins. Right?

Currently no, not yet.

[iksent]

Is there any workaround, so we can translate the enum's strings directly to Strapi UI for admins/editors/...?
Maybe use a mapping somewhere in the code?

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/how-to-use-russian-symbols/1694/3