Support for non-empty constructor of custom types about graphql-doctrine HOT 7 CLOSED

So I went ahead and implemented 77b356a. I believe it should solve pretty much any cases you might have. Let me know how it goes for you.

from graphql-doctrine.

What about supporting instance of types in $customTypeMapping argument of Types::__construct() ? Would that solve your use-cases ?

from graphql-doctrine.

No, because custom GraphQL Type doesn't necessary have any related PHP type. For instance I have a mutation which returns two lists of different entities, so for response say I will have some shape like
{ posts:[Post], comments:[Comment]}
and I am definitely not creating a class for that structure, but instead returning an associative array or an stdClass instead, Still I have to define a type for GraphQL Layer for it to work properly.

That might be a bad example, since creating this kind of structure as a class is not that big of an effort, but right now I have a necessity to operate almost arbitratry JSON objects received from 3rd party API inside my GraphQL API, without actually having any server-side structure for them - that what causes me to create fancy complex types and that's when a problem arises

from graphql-doctrine.

The map is internally used as $customTypeMapping as $phpType => $graphQLType, but here $phpType (the map key) does not have to be an actual PHP class name, it can be any arbitrary string. It has been documented as "PHP type" because it was the use-case we thought about, but if it can fit your use-case, we could re-word the documentation to make it more clear.

So you could do something like:

$mapping = [
    DateTime::class => DateTimeType::class,
    'foo' => new CustomObjectType($whatever),
    'bar' => new OtherCustomObjectType($whatever),
];

$types = new Types($entityManager, $mapping);

// Build schema...

Wouldn't that work ?

from graphql-doctrine.

This particular thing will not work since to get a type definition for a dependent type (OtherCustomObjectType) inside a "master" type (CustomObjectType in this example) I have to make a call to $types->get, so I need to pass an instance of TypeManager, which is not instantiated at the moment of creating the type instance given that syntax the module is providing. So basically it's a circular reference problem, and I don't see a way to instantiate a secondary type lazily. Static calls would have solved that

But I've tried several similar tricks, most of them lead to an API layer failing because either of one of those types being declared more than once or "Not a doctrine entity" error

Also the secondary problem is that I can't use those types as an input type because it's explicitly prohibited by $this->throwIfNotEntity($className);

from graphql-doctrine.

So as a temporary workaround what I did is creating my own higher-level TypeManager which has type definitions accessible statically, the problem though is that I need to pass EntityManager into the module's Types non-statically. and, since I can't use DI or whatsoever, it can cause a race condition error, when a certain custom type is referenced in the @Field annotation of an entity, whose "type" is being requested from Type::get prior to that custom type itself being registered within it.

And for Input type I had to pass a custom hack into Types constructor like this
CustomGraphQLType::class . 'Input' => CustomGraphQLType::class
which is very dirty :)

Anyhow it seems to work, but I really hope you'll come up with some cleaner and more predictable solution, or at least document this use case so others can find a way to do it too.

from graphql-doctrine.

I still don't have too much time to spend on this, but I wonder if something like the PSR-11 container interface could help us with this case...

In the meantime, if you can create a MCVE that expose your original issue, and another one with your current workaround, that could help further the discussion.

from graphql-doctrine.