-
-
Notifications
You must be signed in to change notification settings - Fork 842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GraphQL] Custom Operations #2755
Comments
@SCIF @alanpoulain @dunglas What do you think about this? |
Yes I'm working on it. |
I'm ready to work on custom naming which makes a lot of sense for me. In my opinion, the name should be fully customizable. Let's arrange a way of defining the name? I don't like that name even for custom resolvers cannot be fully customized. Do you have any particular idea in mind about way of specifying an operation name? Hi @alanpoulain , so, will it bring support of Interfaces?
|
Naming: I thought about either letting the resolver override the operation name (e.g. For the |
Hi @lukasluecke , Not sure if it a good idea to get a resolver locator and instantiate all resolvers just to build a schema. In my opinion just |
@alanpoulain , @dunglas , can we arrange some way and I will implement that? I'm ready to implement custom names and it could be used in my project :) BTW, I'm still thinking it's really not good idea to keep all attributes under |
Hi @lukasluecke , could you check my comment there? Is it expected requirement to specify |
I think that this deserves an ADR @alanpoulain @lukasluecke wdyt? |
Any updates on this ? |
I am playing around this from a week now. I was able to make custom naming for Mutation, Query, Subscription. I added a operation config called overrideName and decorated api_platform.graphql.fields_builder to achieve this. What's difficult is to modify and make the operation to use custom output DTO or even another API resource. That's because everywhere in the code the resourceClass is being passed to other functions. During recurring function calls the value of the resourceClass changes the reference to the main resource class is lost. Now because custom GraphQL operations can't return custom DTO / API resource, my project has reached dead end. @SCIF @alanpoulain @dunglas |
Any updates on this? |
I moved out of API Platform for my project. Now I am using GraphQLite. It's more straight forward to create a query and mutation. You can create a controller class and then create a functions inside it. You can mark these functions either as query or mutation. Needless to say, you can do anything inside the function and return the final data. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I would also appreciate it if you could easily customize the format of the query name. |
@SCIF @alanpoulain @dunglas Could you please reopen this? |
I'd like to open a discussion on the future potential for custom GraphQL operations beyond what's currently possible with #2445 and #2447 (and the minor changes afterwards).
Naming
Currently the only way to name operations is to specify a name that will get suffixed by the resource name. It would be nice to have a bit more control about this, maybe with a token for the resource name? E.g.
create${Resource}Custom
Arguments
Currently the following methods exist:
denormalization_context
)input
)args={}
)It would be nice to be able to specify custom fields with types inline (I think @alanpoulain mentioned something about this once).
In the meantime maybe we could at least enable changing the nullability of existing fields per operation, e.g. the
id
field. (#2738, but customizable)Result
Currently the following methods exist:
normalization_context
)output
)Setting
output
does not seem to work at the moment (#2754). Might be enough for now to fix this.Otherwise the same options for custom fields and types as in the arguments would be nice to have.
The text was updated successfully, but these errors were encountered: