Calling `resolver.getArgs()` resets the `filter` arguments

[Thammada]

When calling .getArgs() on a mongoose resolver, arguments added by addFilterArg will get reset.
I also observe that calling .addFilterArg() on a cloned resolver also affect the original resolver, but calling .addArg() doesn't

See the following snippet:

const mongoose = require('mongoose');
const { composeMongoose } = require('graphql-compose-mongoose');

const Person = mongoose.model('Person', new mongoose.Schema({
  firstName: String,
  lastName: String
}))

const PersonTC = composeMongoose(Person)

const findManyResolver = PersonTC.mongooseResolvers.findMany()

const personsResolver = PersonTC.mongooseResolvers.findMany().clone().addFilterArg({
  name: 'fullName',
  type: 'String'
}).addArgs({
  username: 'String'
})

console.log('personsResolver username', personsResolver.hasArg('username')) // true -> OK, expected
console.log('personsResolver filter.fullName', personsResolver.getArgITC('filter').hasField('fullName')) // true -> OK, expected

console.log('findManyResolver username', findManyResolver.hasArg('username')) // false -> OK, expected
console.log('findManyResolver filter.fullName', findManyResolver.getArgITC('filter').hasField('fullName')) // false -> NOT EXPECTED, .addFilterArg not consistent with .addArg

PersonTC.mongooseResolvers.findMany().getArgs() // this line resets the `filter` arguments
// calling findManyResolver.getArgs() does not trigger the issue

console.log('personsResolver username', personsResolver.hasArg('username')) // true -> OK, expected
console.log('personsResolver filter.fullName', personsResolver.getArgITC('filter').hasField('fullName')) // false -> NOT EXPECTED, `filter.fullName` suddenly disappeared

console.log('findManyResolver username', findManyResolver.hasArg('username')) // false
console.log('findManyResolver filter.fullName', findManyResolver.getArgITC('filter').hasField('fullName')) // false

[nodkz]

@Thammada I need to clarify some new concept added to v9.0.0:
PersonTC.mongooseResolvers.findMany() – now creates resolver & subtypes every time when you call it. No need to call clone() method.

In your case, you creating several resolvers but under the hood, they are using the same input types with the same names.
So existed types may be overwritten. For avoiding this bad behavior you need to provide a custom suffix when you call findMany() fabric method.

Eg the following code will create two different resolvers with different subtype names which helps to avoid type name collisions:

const findManyResolver = PersonTC.mongooseResolvers.findMany();
const personsResolver = PersonTC.mongooseResolvers.findMany({ suffix: 'Extended'}).addFilterArg({ // <--- add any suffix
  name: 'fullName',
  type: 'String'
}).addArgs({
  username: 'String'
});

[toverux]

Hi @nodkz,

In your case, you creating several resolvers but under the hood, they are using the same input types with the same names. So existed types may be overwritten.

I encountered the same issues and it was hard to troubleshoot.
I am migrating an app to v9 and somewhere I have this:

const findMany = tc.mongooseResolvers.findMany().addFilterArg(brandFilter);
const connection = tc.mongooseResolvers.connection();
const pagination = tc.mongooseResolvers.pagination();

Calling connection() or pagination() after the modded findMany() effectively makes the filter arg disappear.
I find this to be very surprising and unexpected.

To make it work, I have to append the addFilterArg call to pagination(), the last call that generates the filter input type shared by all these resolvers.

Shouldn't a new resolver reuse the existing subtypes when they already exist?
It's not perfect, in both cases there are side-effects, but it seems much more logical as this can be seen as some form of inheritance. And if that's not what you want, then and only then you could use suffix on the resolver where you don't want to inherit the existing types.
Older versions were working like this.

[nodkz]

@toverux Good catch! I've just added customization param findManyResolver to connection & pagination resolvers.

A new version will be published in some minutes.
With your example above you will need to create resolvers in the following way:

const findMany = tc.mongooseResolvers.findMany().addFilterArg(brandFilter);
const connection = tc.mongooseResolvers.connection({ findManyResolver: findMany });
const pagination = tc.mongooseResolvers.pagination({ findManyResolver: findMany });

[nodkz]

Also for filterHelperArgs() I added reusing of existed type if it is already present in schema.

📦 published as 9.5.1

[toverux]

As always @nodkz, you're being just awesome. I will try it asap but I like this API, thank you very much!