Skip to content
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

Cannot set query argument in Product_Connection_Resolver Class #321

Closed
jacobarriola opened this issue Jul 10, 2020 · 3 comments
Closed

Cannot set query argument in Product_Connection_Resolver Class #321

jacobarriola opened this issue Jul 10, 2020 · 3 comments
Assignees
Labels
bug
Milestone

Comments

@jacobarriola
Copy link
Contributor

jacobarriola commented Jul 10, 2020

Describe the bug
When attempting to create a new Connection via register_graphql_connection(), my set_query_arg() argument does not take effect in the resolve callback function.

Specifically, I am trying to add a post__in argument to the query similar to what's being done here. ie, instead of getting the first n products, only return back specific ones.

To Reproduce
Steps to reproduce the behavior:

  1. Register a new connection via register_graphql_connection (product <-> product should be testable)
  2. in the resolve callback, instantiate a new Product_Connection_Resolver Class and set it to $resolve
  3. execute the $resolve->set_query_arg('post__in', ['123, '456']) method (test, hard-coded IDs for demo purposes)
  4. return the $resolver->get_connection() method

Expected behavior
post__in argument to be included in query

Actual behavior
post__in does not get added to the query.

Screenshots

add_action( 'graphql_register_types', function () {
	register_graphql_connection( [
		'fromType'      => 'BundleProduct',
		'toType'        => 'Product',
		'fromFieldName' => 'bundleItemConnection',
		'resolve' => function( $source, $args, $context, $info ) {
			$resolver = new Product_Connection_Resolver( $source, $args, $context, $info );
			$resolver->set_query_arg( 'post__in', [  '115042', '115061' ]);

			return $resolver->get_connection();
		},
	] );
} );

Additional context
While debugging, returning both $resolver->get_query() and $resolver->get_query_args() doesn't reflect my post__in argument that I'm attempting to pass.

Additionally, if I go into the Class' get_query_args() method here and manually check for a post__in, my query works:

if ( ! empty( $this->query_args['post__in'] ) ) {
	$query_args['post__in'] = $this->query_args['post__in'];
}

Also, if I change the method inside get_query() method here from $this->get_query_args() to $this->query_args, my query works as expected. Interestingly, the default PostObjectResolver uses the $this->query_args in its get_query() method.

// current
public function get_query() {
	return new \WP_Query( $this->get_query_args() );
}

// changes
public function get_query() {
	return new \WP_Query( $this->query_args );
}

I have a workaround, if this is expected behavior

For now, I'm using the graphql_product_connection_query_args filter, which allows me to insert my post__in argument. Ideally, it seems as though this should happen at the resolver level, unless I'm misunderstanding the logic.

@jacobarriola
Copy link
Contributor Author

jacobarriola commented Jul 21, 2020

Closing this out so it doesn't linger. Sometimes you just have to let go 👋🏽

@kidunot89
Copy link
Member

kidunot89 commented Jul 21, 2020

@jacobarriola I'm actually resolving this issue is a big PR coming up soon so I'm leaving this open until this issue is patched.

@kidunot89 kidunot89 reopened this Jul 21, 2020
@kidunot89 kidunot89 added the bug label Jul 21, 2020
@kidunot89 kidunot89 self-assigned this Jul 21, 2020
@jacobarriola
Copy link
Contributor Author

jacobarriola commented Jul 22, 2020

@kidunot89 ok great - thanks! 👍🏽

@kidunot89 kidunot89 added this to the v0.6.0 milestone Jul 27, 2020
@kidunot89 kidunot89 mentioned this issue Jul 29, 2020
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug
Projects
None yet
Development

No branches or pull requests

2 participants