Swift Codegen Not Respecting --mergeInFieldsFromFragmentSpreads Flag

[alex-king-ck]

Using CLI version 0.2.0 (The latest version supported by apollo-ios)
The same issue is present when using 0.6.0 (latest current version)

We're trying to upgrade our version of apollo-ios. This means updating our version of the CLI (coming from apollo-codegen v0.17). Generating our API.swift file with all of our queries produced a 180MB file. We had seen this previously and the resolution was to disable merging fields from fragment spreads. However, the output of apollo-cli 0.2.0 doesn't change when we use the --mergeInFieldsFromFragmentSpreads flag.

Here is a small sample query that can be used to illustrate the issue:

query Hub($useForce: Boolean) {
    hubsInfo(useForce: $useForce) {
        hubs {
            ...hubInfo
        }
    }
}

fragment hubInfo on Hub {
    discriminator
    label {
    ...formattedTextInfo
    }
}


fragment formattedTextInfo on FormattedText {
    spans {
        text
        format {
            italic
            strong
        }
    }
}

Generating using apollo-cli v0.6.0 with and without --mergeInFieldsFromFragmentSpreads produced the following output:
API.swift.txt

Here is the expected output, generated with apollo-codegen v0.17:
API.swift.txt

[chrislconover]

@martijnwalraven

@alex-king-ck, I previously had this flag set as --merge-in-fields-from-fragment-spreads false, after the --output API.swift, to avoid the code bloat that you speak of. I feel like the syntax has changed, can you tell me what your current syntax is? I get an error if I include it at all now.

Previously I had something like:
--schema service/schema.json --output service/API.swift --merge-in-fields-from-fragment-spreads false

but it appears that the flag name has changed to camelcase, and that output has been removed. Have you figured out of you can set this flag to false or is one only supposed to use it for the positive?

Thanks,

Chris

[namnguyens]

@chrisco314 I think that @alex-king-ck has indeed been using the flag with camel case --mergeInFieldsFromFragmentSpreads and regardless whether the flag is on or off the output is the same.

I have the same issue and cannot seem to set the flag to false. Tried with and without the flag, and also --mergeInFieldsFromFragmentSpreads=false and --mergeInFieldsFromFragmentSpreads false.

I run Apollo/1.6.0.

[chrislconover]

Thanks, @namnguyens .

I had upgraded from Apollo iOS framework version 0.8 to 0.9.2 to fix a crash bug in GraphQLError from force unwrapping a dictionary result. I hit the problems of this post - project became unworkable, an so rolled back to 0.8.0 again, and coded around my error (error.message -> error["message"]).

For what it's worth, you can get clean internal models even with fragments, if you unwrap as needed, in the model level protocol extensions. Not as idea as plain old Swift objects, but workable...

Example:

public protocol Event: ModelType {

    var info: [EventInfo] { get }. // use an alias in .graphql, to avoid collisions here: // infoAlias: info

    var name: String { get }

    var location: String? { get }
    var imageUrl: String { get }
    var eventDefinition: EventDefinition { get }

    var color: UIColor { get }
}

extension EventFragment: Event {

    public var imageUrl: String {
        let url = info.first?.icon.url
        assert(url != nil)
        return info.first?.icon.url ?? App.missingIconUrl
    }

    public var eventDefinition: EventDefinition {
        return eventDefinitionAlias!.fragments.eventDefinitionFragment }

    // map our aliased `infoAlias` back to our cleansed `info` of the protocol
    public var info: [EventInfo] { return infoAlias.map { $0.fragments.eventInfoFragment } }
}

This then affords you a clean, Uncle-Bob compliant app that does not leak Apollo innards and lead to vendor lock-in.

func doSomethingWithNoKnowledgeOfApollo(event: Event) { ... }

[martijnwalraven]

This should be fixed in Apollo iOS 0.9.3 (which depends on the Apollo CLI 1.8.x).