Multiple Api.Query.user

[ronanyeah]

If I run elm-graphql against a Graphcool endpoint the generated code has multiple Api.Query.user functions.

user : (UserOptionalArguments -> UserOptionalArguments) -> SelectionSet decodesTo Api.Object.User -> Field (Maybe decodesTo) RootQuery
user fillInOptionals object_ =
    let
        filledInOptionals =
            fillInOptionals { id = Absent }

        optionalArgs =
            [ Argument.optional "id" filledInOptionals.id ((\(Api.Scalar.Id raw) -> Encode.string raw)) ]
                |> List.filterMap identity
    in
      Object.selectionField "User" optionalArgs (object_) (identity >> Decode.nullable)


user : SelectionSet decodesTo Api.Object.User -> Field (Maybe decodesTo) RootQuery
user object_ =
      Object.selectionField "user" [] (object_) (identity >> Decode.nullable)

which causes:

-- NAME CLASH ------------------------------------------------ src/Api/Query.elm

This file has multiple `user` declarations. One here:

208| user fillInOptionals object_ =
     ^^^^
And another one here:

221| user object_ =
     ^^^^
How can I know which one you want? Rename one of them!

This endpoint can be used to investigate it: https://api.graph.cool/simple/v1/cjltfi0tf0z820102nn7jras5

[dillonkearns]

Hello @ronanyeah, thank you for reporting the issue!

So the problem is that all fields need to be normalized to valid Elm function names, but these two fields normalize to the same thing. An Elm function cannot start with a capital letter, so the field User -> user. But there is also a field called user, which of course is just used directly.

To fix this, you would either 1) need to keep track of the context and check for any clashes, and do special behavior there (I don't want to go this route because it significantly increases complexity and the possibility of bugs), or 2) always normalize "irregular" field names like these ones starting with capital letters.

I think 2 is the way to go, and since it is unusual to name fields starting with capitals, I think this is quite reasonable.

So then there's the question of how to normalize it, and it's a bit tricky.

Here are some possibilities for how to normalize the field User:

1. user_capital
2. user_Capital
3. capital_User
4. normalize_User
5. user_

Something like user_ would probably not be a good idea because it would potentially clash with other things that normalize to the same name.

What are your impressions on this?