Implement mongooseResolvers for discriminators

[Tyrubias]

The v9.0.0 release brought a lot of new features to graphql-compose-mongoose; however, it doesn't look like they're implemented for discriminator types. Are there any plans to add this? If so, how would they work and how could I contribute?

[nodkz]

I don't have any ETA (plans) for refactoring discriminators on the new logic. All discriminators logic was written by @mernxl and for preparing some migration plans I need to examine the current code and find a way how to introduce a new logic & keep backward compatibility.

Or we may choose another way – write a new discriminator logic from scratch. New logic will work with composeMongooseDiscriminators method; and old logic will work without changes with composeWithMongooseDiscriminators. According to the new way of generation resolvers (on-demand), there is no need to keep a lot of "sync" methods which helps to modify/remove fields for child type composers in the current discriminator modules.

@Tyrubias it will be very nice if you are able to start the implementation of new discriminators logic. The first step should be some code snippet example of how composeMongooseDiscriminators can be used in your scenarios (which options it has, how it can be used by other developers). Of course without internal implementation, while we are not rich agreement about new interfaces which will provide the new composeMongooseDiscriminators method.

[Tyrubias]

Currently I don't understand the internals of the current discriminator modules well enough to comment further, but I'll take a look and write something up.

@nodkz I'm currently (ab)using the discriminator logic to write resolvers that can update Mongoose documents of the child type composers without actually creating separate updateById resolvers for each type. I'm considering maybe the new discriminator logic should take that option into account. I wrote a gist with an example of what I'm doing right now.