Apollo generates different enums after schema is fetched

[balavor]

Apollo generates different enums after schema is fetched

Intended outcome:

So here we coming back to our query

query {
  languages {
    code
  }
}

The code parameter is an enum type that contains all language codes specified in ISO 639-3 (as far as iOS supports only ISO 639-1 and ISO 639-2).

The expected behaviour is that it will generate an enum only once.

enum Language {
 case eng = "ENG"
 case fra = "FRA"
 case ger = "GER"
 ...
}

Actual outcome:

Every time when we fetch a schema, the enum is parsed in it as an array of enumValues, but all these values are always in different order.

First run

enum Language {
 case fra = "FRA"
 case eng = "ENG"
 case ger = "GER"
 ...
}

Second run for the same schema

enum Language {
 case ger = "GER"
 case fra = "FRA"
 case eng = "ENG"
 ...
}

In git it looks like that

Expected solution

So it would be nice if Apollo will sort all of the enum cases in alphabetical order to avoid so much changes in version control system after each API generation.

Thanks for attention :)

[designatednerd]

Hm, weird - we've seen this for parameter names (which is its own bag of hurt) but not for enum values. Couple follow ups here:

1. Is your schema json or gql?
2. In your schema, has the order in which the enum's values are declared changed at all?

[balavor]

@designatednerd Here's how the schema looks like (yeah, it is json)

First run	Second run

We fetch schema on every run from our backend. And I'm sure that enum. If, for example, I open docs in Altair and try to reload that type, it also reloads in a random order.

Even though it is possible that our server returns that list in schema in random order (not sure if it is possible to handle), maybe Apollo should insure clients from those kinda stuff?

Cause there might be some external GraphQL API's that users use and they won't be able to fix that problem.

[designatednerd]

There are many cases where people want things to be in the order provided by the server because of the semantic meaning provided by the ordering (ex, an enum for Priority with cases like lowest, medium, and highest).

Since the enums are all String enums, it's not as big a deal to switch to alphabetical order as it would be for Int based enums, but it's still enough of a thing that I'm comfortable saying "We're generating this in the order provided by the schema, and the schema should be providing a stable representation of this order" for now.

I'm going to add an this as an enhancement to the swift codegen - default will be as provided but it does make sense to add this as an option for situations like yours.

[balavor]

Cool, thanks a lot for your time😇