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

Expose label data for SelectOne/SelectMultiple #155

Open
timkelty opened this issue Sep 12, 2018 · 4 comments
Open

Expose label data for SelectOne/SelectMultiple #155

timkelty opened this issue Sep 12, 2018 · 4 comments

Comments

@timkelty
Copy link
Contributor

SelectOne/SelectMultiple field types end up as enums of the values, but it may be common to want to access the selected label.

Since the label is added to the enum's description, I thought maybe I could do this introspectively already, but didn't find a solution.

Ideas:

  • Split it up into an object type with "label" and "value(s)"
  • Add an @description directive that will get the enum value's desc and return it.
@markhuot
Copy link
Owner

Hrm, I'm worried about switching it to an object because that's not how craft.entries behaves in Twig, I don't think. I don't mind the @description directive, but I do wonder if you can do this with introspection. What about the following,

{
  __type(name:"EnumTestEnum") {
    name
    enumValues{
      name
      description
    }
  }
}

This works with a Craft Field that has a handle of enumTest and then the inferred CraftQL type name of EnumTestEnum (with the Enum suffix).

@timkelty
Copy link
Contributor Author

@markhuot Craft will return craft\fields\data\SingleOptionFieldData and craft\fields\data\MultiOptionFieldData, (which has a getOptions method, that returns the labels and values). In Twig, if you just outputting the field, you'll get the value, but only because of the __toString method.

Yeah the __type method works, it's just seems a little hard to work with, since its not attached to the actual field data.

@markhuot
Copy link
Owner

Ah, I see. Hrm… then the object does sound nice but it's a backwards compatibility break, let me think on it. I'm leaning towards the directive, though.

@markhuot
Copy link
Owner

dev-master now adds an OptionFieldData object type to these sorts of fields. This is implemented as a new GraphQL field with the suffix _FieldData. So, to query a list of selected languages that may be implemented as checkboxes you could do,

{
  entries {
    ...on EntryType {
      checkboxField_FieldData {
        selected {
          label     # the string label of the option
          value     # the string value of the option
        }
        options {
          label     # the string label of the option
          value     # the string value of the option
          selected  # a boolean indicating if the option is selected
        }
      }
    }
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants