Specifying enums in JSON

[kjellmorten]

Enums are defined though the EnumType class, in line with the conclusion on issue #2. Here's the example from the README:

const query = {
    query: {
        Posts: {
            __args: {
                orderBy: 'post_date',
                status: new EnumType('PUBLISHED')
            },
            title: true,
            body: true
        }
    }
};

However, this is problematic when I need to actually store this in a JSON file, where the EnumType won't be available. Here's a suggestion for an alternative way to define an enum:

{
    "query": {
        "Posts": {
            "__args": {
                "orderBy": "post_date",
                "status": { "__enum": "PUBLISHED" }
            },
            "title": true,
            "body": true
        }
    }
}

Would you be interested in a PR that implements this as an alternative to the EnumType, @vkolgi?

[vkolgi]

@kjellmorten If we change the way we define enums then we will have two different ways, new and old one for compatibility reasons. If this is only an issue with serialisation (converting to json), we can implement toJson function for EnumType. We did the same with VariableType. Does it sound like a balanced approach ? And PRs are always welcome :-)

[vkolgi]

@kjellmorten Any opinion on this ? Do you want the issue to be kept open for some more time for discussion ?

[kjellmorten]

Sorry, @vkolgi, I've been sick for a few days.

This is more about converting from json, at least for me. I plan to store GraphQL queries in JSON and then use this package before running it. The toJson approach would still make sense, but we'll also need a JSON format for enums that the package can read.

Do you agree and do you think the format I suggested may work?

[vkolgi]

@kjellmorten Hope you are feeling better now. My concern is to have to deal with two different ways of defining the enums or breaking the compatibility. And current way of defining enum (class EnumType) gives room for extensibility vs a flat JS object. I would prefer a solution where we have special serialisation/desirialization functions added to the library, which takes care of persisting meta info about the objects. That way the serialisation/de is decoupled.

[Oleg2tor]

@vkolgi Hi. First of all thanks for what you doing - really great tool.

It would be nice to implement format, that @kjellmorten proposed. I have cases when I want to store requests in files (maybe in db later), so must use .js instead of .json.

Same for __alias / __aliasFor - it’s ok to keep both formats. As for developer it is comfortable to use __aliasFor. As for some library it better __alias, because you can get field name by simple Object.keys without needing to check for having __aliasFor inside.