aad0106 refactors the ConnectionResolver to support overloading the $query_class on a resolver level. This differs from #2821 in several ways:

1. The default $query_class is set in the resolver with the query_class() method. It returns null by default, and should be overloaded to return the name of the query class in a Resolver that require one.

protected function query_class() ?: string {
  return 'WC_Query';
}

2. The property is set on the constructor, using get_query_class(). That method will use $context->queryClass before defaulting to query_class(), and wraps it in the graphql_connection_query_class filter.

3. $resolver->set_query_class() can be used to overload the query class on a specific Resolver instance. You can pass an empty string to reset the query class to the default (i.e. ignoring the $context->queryClass or the results of the filter).

...$connectionConfig,
'resolve' => function( $source, $args, $context, $info ) {
  $resolver = new PostObjectConnectionResolver( $source, $args, $context, $info );
  
  $resolver->set_query_class( WC_Query::class ); // If "" is passed, revert to default query class.
  
  return $resolver->get_connection();
},

4. When get_query() is run, a check will be made to is_valid_query_class() to make sure that:

• There is only a query class is the connection requires it (i.e. if query_class() is not null).
• The query class exists.
• The query class is compatible with our Connection Resolver. This is checked with is_valid_query_class(), which should be overloaded if you're using a class that's not compatible with WP_Query.

protected function is_valid_query_class( string $query_class ) : bool {  
  return method_exists( $query_class, 'get_results' ); // Instead of the default `WP_Query::query()`
}

As a result of these changes:

• query() is no longer a required abstract method; however if a ConnectionResolver does not use a query_class, an invariant error will be thrown if the default query() method is not overloaded.
• Extending ConnectionResolver is now DRYer, since in most cases developers will only need to overload the query_class method, instead of the entire query().

rebased on develop.

coverage: 84.442% (+0.1%) from 84.33%
when pulling 025d45e on justlevine:proposal/v2-connection-resolver
into cb18964 on wp-graphql:develop.

Even with the indeterminate model/dataloader pattern unsolved, I'd love to start backporting some of the nonbreaking changes (and close several existing Issues).

@jasonbahl What can I do to make this proposal easier for you to review and give feedback on?

The next batch of backports is up, focusing on improving DX and instantiating class properties only once:

• refactor: wrap AbstractConnectionResolver::is_valid_model() in ::get_is_valid_model() #3120
• refactor: split AbstractConnectionResolver::get_nodes() and get_edges() into prepare_*() methods #3121
• chore: relocate AbstractConnectionResolver::is_valid_offset() with other abstract methods. #3122
• refactor: split AbstractConnectionResolver::get_ids() into ::prepare_ids() #3123
• refactor: split AbstractConnectionResolver::get_args() and ::get_query_args() into ::prepare_*() methods #3124
• refactor: improve query handling in AbstractConnectionResolver #3125

Once this batch is merged, I'll do one more sweep, but I think we're getting close to being able to backport as many of these changes as possible without breaking backwards-compatibility.

cc @jasonbahl

Code Climate has analyzed commit 025d45e and detected 17 issues on this pull request.

Here's the issue category breakdown:

View more on Code Climate.

Hey @justlevine, it looks like most of this has been reviewed and merged as separated pull requests. Is this PR still relevant or would it be safe to close?

Hey @justlevine, it looks like most of this has been reviewed and merged as separated pull requests. Is this PR still relevant or would it be safe to close?

Almost, still on the todo list are:

• Centralized hooks/methods for mapping/sanitizing where args.
• Docs.

Once that's done, I'll rebase and close this, so there's a reference for when we're ready to implement breaking changes.