Fork me on GitHub

does lacinia support complex enum like this? I'm trying to find a simple way to translate between :MY_STATE and a corresponding value such as "some-state-A". Custom scaler almost work, except it doesn't list all possible enum value so I have to add them into description every time I make a change.


Short answer: no. Long answer: I'd need to understand the use case better, but typically you would expose an enum and use a field resolver to convert from internal representation to the GraphQL enum representation.


@hlship Enum’s like that look very much like rust enums, and they could make a lot of sense. For example you could have a location value, which could be either an ADDRESSS or a GEOCOORDINATE where depending on the enum you have properties like ‘country’ ‘postcode’ or ‘latitude’ and ‘longitude’


for my personal use case, it's just to get around the restriction where enum value can't take -


If I'm understanding this, you want to have Lacinia identify particular types in the resolved value and convert it, much like a scalar, to an enum? I just don't see how a client will see the someRandomValue: 123 structure ... they'll just see "TWO".


i understand this is a graphQL restriction, but it's a bit awkward to convert between db value "my-state" and :MY_STATE. I guess i'll just stick with string type for now. resolver works for one way, but we'd still need to parse incoming query to string


(-> state (str/subts '_') str/upper-case keyword) ?


resolver doesn't work in input object right? I would need to explicitly parse MY_STATE back to "my-state"


That is true.


anyway, it's not a big deal, just trying to see if i'm missing anything. I'll stick with string. thanks for explaining!


lacinia 0.27.0-rc-1 and lacinia-pedestal 0.8.0-rc-1 are up on clojars; it'll be a week or so until I can get them into production here for a formal release

👍 20
👀 4
🍬 4