search

thecodingmachine / graphqlite

Use PHP Attributes/Annotations to declare your GraphQL API
https://graphqlite.thecodingmachine.io
MIT License
554 stars 95 forks source link

AbstractEntity and input #686

Closed tasselchof closed 2 months ago

tasselchof commented 2 months ago

I'm currently working on a project where I'm dealing with abstract inputs and facing some challenges with annotation. I have an entity, let's call it AbstractUser, and several types of users inheriting from it, such as RegularUser and Employee. Additionally, there's another entity named Business, which can be owned by either a RegularUser or an Employee.

In my code, I have a method setUser(AbstractUser $user) which should accept an AbstractUser as a parameter. However, I encountered an issue where using AbstractUser as an input parameter isn't feasible because it's not a final class and cannot be instantiated. In my case it's Doctrine inheritance and annotated entities.

What is the right path in that case?

oojacoboo commented 2 months ago

So, input types don't support inheritance in GraphQL. I think you're going to have to annotate this with a union...

/** @param RegularUser|Employee $user */`

And actually, this might not work either, since polymorphic input types aren't implemented yet. See https://github.com/thecodingmachine/graphqlite/issues/238.

Assuming a PR isn't submitted for the above, which would be really great to have... another option would be using #[ExtendType] and implementing individual setters for each user child type/class.

tasselchof commented 2 months ago

And actually, this might not work either, since polymorphic input types aren't implemented yet. See #238.

Just to confirm, this won't work - I tried this way and failed.

tasselchof commented 2 months ago

The only other option would be using #[ExtendType] and implementing individual setters for each user child type/class.

Why in that case ExtendType is needed at all? If we have an individual setters we can just set it without ExtendType.

oojacoboo commented 2 months ago

ExtendType isn't needed. However, if you don't want to modify your domain model/entities for your public API, it's best to separate those concerns with extended types.

tasselchof commented 2 months ago

ExtendType isn't needed. However, if you don't want to modify your domain model/entities for your public API, it's best to separate those concerns with extended types.

Oh yes, this makes sense. Thanks for clarifying. I have a little bit different structure so ExtendType won't work for me for that case and only will complicate things - it was easier to modify trait, that was adding this functionality.