Filter from Graphcool API causes self-referential type & thus compilation error

[dillonkearns]

Filter from Graphcool API causes self-referential type & thus compilation error

[dillonkearns]

Hello @nicolasartman, thank you so much for reporting the issue! This should be a pretty simple fix, I'll push something to address it soon.

[dillonkearns]

@nicolasartman in the meantime, as a workaround if you simply do a find and replace of API.InputObject.UserFilter.UserFilter => UserFilter within UserFilter.elm that will get you past that compilation error.

I'll get to this soon but hopefully that helps until then!

[Frozen666]

@dillonkearns This workaround fixes the "Cannot find type ..." error message, unfortunately it leads to a recursive type alias (see here: https://github.com/elm-lang/elm-compiler/blob/master/hints/recursive-alias.md).

[Frozen666]

I posted a somewhat related problem concerning the graph.cool APIs on the slack channel already. Those filters will also reference the filters of their relation objects, which in turn reference the starting filter, leading to circular dependencies. This can be seen using the API https://api.graph.cool/simple/v1/cjct1ri2d0twa0114q7ld4xqu, where InputObject.Postfilter imports InputObject.CommentFilter and vice versa

[dillonkearns]

@Frozen666 ah, indeed you're correct, with the workaround there are still issues. Thanks for reporting back with that, that saved me some time.

What the code generation needs to do is generate union types (with just a single tag) instead of type aliases. And because of the issue you mention of the circular dependencies, I will need to generate all these types inside of a single file, that way no imports are needed so there is no circular dependency issue. Not too complicated, actually.

[dillonkearns]

@Frozen666 @nicolasartman I published a fix for this in npm version 3.0.0! I've got some pretty extensive tests and it's looking good.

I'll leave this open a bit and wait to hear that everything is looking good in case I missed a case in my end-to-end tests. Thanks again to both of you for reporting this issue!

[nicolasartman]

Fantastic! I’ll check this out tonight and will let you know. Thanks so much!

…

On Thu, Feb 1, 2018 at 5:09 PM Dillon Kearns ***@***.***> wrote: @Frozen666 <https://github.com/frozen666> @nicolasartman <https://github.com/nicolasartman> I published a fix for this in npm version 3.0.0! I've got some pretty extensive tests and it's looking good. I'll leave this open a bit and wait to hear that everything is looking good in case I missed a case in my end-to-end tests. Thanks again to both of you for reporting this issue! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dillonkearns/graphqelm/issues/24#issuecomment-362454268>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAiZM6QvqfcWbH_TkuzgcP-RxEgIx3Qlks5tQmBfgaJpZM4RovQ1> .

[nicolasartman]

Sorry for the delay @dillonkearns—I just tested this against my initial API and it's really close I think, but there's one error remaining. For the User object (and only that one it seems), it generates two functions with the same name:

{-|

  - auth0UserId -
  - id -
-}
user : ({ auth0UserId : OptionalArgument String, id : OptionalArgument API.Scalar.Id } -> { auth0UserId : OptionalArgument String, id : OptionalArgument API.Scalar.Id }) -> SelectionSet decodesTo API.Object.User -> Field (Maybe decodesTo) RootQuery
user fillInOptionals object =
    let
        filledInOptionals =
            fillInOptionals { auth0UserId = Absent, id = Absent }

        optionalArgs =
            [ Argument.optional "auth0UserId" filledInOptionals.auth0UserId Encode.string, Argument.optional "id" filledInOptionals.id (\(API.Scalar.Id raw) -> Encode.string raw) ]
                |> List.filterMap identity
    in
        Object.selectionField "User" optionalArgs object (identity >> Decode.maybe)
user : SelectionSet decodesTo API.Object.User -> Field (Maybe decodesTo) RootQuery
user object =
    Object.selectionField "user" [] object (identity >> Decode.maybe)

This, as expected, fails compilation due to top-level identifier ambiguity.

[dillonkearns]

Hey @nicolasartman, thank you for reporting back! This is a separate issue so I've created #34 to discuss this problem. Would you mind giving your feedback there? I'll close this one as it appears to be fixed from your account and @Frozen666's.

Thanks again for helping me track this down!