Field hashing breaks subscriptions

[NickGeek]

Hi,
I've spent some time today fighting this and ultimately I'm not sure of a solution. If a subscription is sent off with one argument it cannot be parsed without also knowing the value of the argument.

So if my query is:

subscription {
    person(name:"bob") { name, age }
}

I cannot have a general purpose decoder using Graphql.Document.decoder without knowing that bob will be
in the name field.

This makes a generic subscription port impossible for me to implement if the subscription query is written by elm-graphql.

[dillonkearns]

Is the situation you're describing one where the subscription request lives outside of elm-graphql, and elm-graphql is just being used to decode the incoming responses? The assumption is that the subscription selection set is both serialized and decoded by elm-graphql. The contract of type-safe requests only works because it controls both sides. It works under the assumption that it controls both sending the GraphQL query and decoding it, so that's part of the contract that it operates under. Not sure if that helps at all.

You can also see an example of a wired up subscription at https://github.com/dillonkearns/elm-graphql/blob/master/examples/subscription/Main.elm.

[Birowsky]

@dillonkearns can you please confirm that if we make our own version of Graphql.Document.Field without this line

elm-graphql/src/Graphql/Document/Field.elm

Line 45 in 63de2e2

|> Maybe.map (hashString 0)

things would work for us? Or is there anything else we need to do to have the decoders be hash-free?

A bit of a background:
The channels I use for push messaging are AWS IoT and Firebase Cloud Messaging. The concept here is that the client doesn't need to ask for the data for it to be delivered. Just needs to decode it when it arrives. But I already have the decoders in the SelectionSets for the rest of the Query/Mutation APIs, so they're just sitting there waiting to be useful : )

[dillonkearns]

Yeah, I would try returning a hardcoded Nothing there and that should remove hashes. You can run the test suite with that change to confirm. Just keep in mind that you won't be able to get multiple fields with the same name but different arguments.

[Birowsky]

Oh i see.. there is no way to parametrize that change the way things are now..

I was hoping to make a version of Graphql.Document.decoder that would disregard hashes, but hashing is done from the generated code. Yeah.. I don't see a way to do this without hurting the same-named fields.

[dillonkearns]

Yeah, I wrote about what the hash design does here: https://medium.com/@dillonkearns/how-elm-guides-towards-simplicity-3d34685dc33c.

You could potentially add a string alias to the SelectionSet data type and add a helper to add an alias to a given SelectionSet so you can manually add an alias to some fields. Not sure it would still be worthwhile at that point, but you could explore that direction.

[hariroshan]

@NickGeek I believe the newer version solves this problem. Can you verify?