Skip to content

Getting the parent argument name in InputObject#prepare methods #5266

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

Open
eapache-opslevel opened this issue Mar 7, 2025 · 1 comment
Open

Comments

@eapache-opslevel
Copy link
Contributor

eapache-opslevel commented Mar 7, 2025

We are implementing prepare methods on several input objects. They do some validation, and may raise/return various errors in those cases. We would like to have those prepare methods automatically generate error messages based on the path to the input object.

For example, given

class MyInputType < GraphQL::Schema::InputObject
  def prepare
    raise GraphQL::ExecutionError, "some error message"
  end
end

# elsewhere
argument :input, MyInputType
argument :something_else, MyInputType

We would like the error message to contain input or something_else as appropriate, but there does not appear to be a way to access that information at the moment.

context.current_path exists, but only includes field names, not the (potentially many) argument names needed to get to the currently-preparing argument.

Describe the solution you'd like

Maybe context.current_argument_path is possible? Or maybe there are reasons this is really tricky?

In general we only need the last element, i.e. the name of the specific argument that holds the current input type, so some sort of parent access would also work. TBH I thought that already existed, but I couldn't find the right incantation.

Describe alternatives you've considered

We currently define our prepare methods as class methods returning procs, and then do e.g.

argument :something_else, MyInputType, prepare: MyInputType.prepare(:something_else)

Which works but is of course a bunch of duplicative boilerplate.

@rmosolgo
Copy link
Owner

Hey, thanks for the detailed writeup. I also don't know of any way of getting the current input path.

I'm open to adding it but I think the trick will be finding an implementation that handles possible fiber switches while maintaining compatibility.

In the meantime, you could reduce boilerplate by adding prepare: ... programmatically, for example:

class Types::BaseArgument < GraphQL::Schema::Argument 
  def initialize(...)
    super 
    if @prepare.nil? && @type.respond_to?(:build_prepare_proc)
      @prepare = @type.build_prepare_proc(@name) # could use @name.underscore.to_sym here instead
    end 
  end 
end 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants