Custom Types that are not Graphql scalar types

[morloderex]

Hey guys.

I have an API that provide me with the fallowing type inspection (trimmed down to only the part that is needed):

"currency code alpha 3 (ISO 4217)"
scalar Currency

"Amount with its currency"
type Amount {
  "currency"
  currency: Currency!

  "value of the amount"
  value: AmountValue!
}
"""
Example: Valid representations for EUR with up to two decimals are:

1056
5768.2
-1.50
5877.78
"""
scalar AmountValue

interface Transaction {
   amount: Amount!
}

type CardTransaction implements Transaction {
    amount: Amount!
}

Query {
    transaction(id: ID!): Transaction!
}

As you can see when querying this one would have to do something like this:

query Transaction($id: ID!) {
    transaction(id: $id) {
         amount {
             value
             currency
         }
    }
}

This is all fine and generates the correct ObjectLike php objects for these type of queries, but I can't figure out how i can change that ObjectLike class to be an entirely custom ObjectLike instead. Sense it would be a long more useful if i was able to convert this object into for instance a Money-PHP/Money instead.

But it seems to me that the examples with custom types is only for scalar types not whole objects which contains scalars? Is this something that would be impossible to do?

[spawnia]

I just added an example for converting a custom input object type, see #87. Apart from an unrelated issue with the test setup, it works as written.

However, there are additional complexities when it comes to converting custom object types. For instance, what should we do with a query like this?

query Transaction($id: ID!) {
    transaction(id: $id) {
         amount {
             value
             # Missing currency
         }
    }
}

I presume that without currency, your Money object could not be constructed.

[morloderex]

I would not say that this is an issue this package has to tailor for I would say that it would be a developer issue if that developer decides to invalidate the query in this way.

I don't think we have the power to know how every custom type would be constructed?

[spawnia]

Right. There are things that can go wrong with such an approach, but I see the advantages one could gain.

I reworked #87 to allow EndpointConfig::configureTypes() to customize object, interface and union type code generation. Please require dev-add-custom-object-example in your composer.json and try if it works for you and provide feedback on the pull request.