furious-luke/polecat

Refactor the resolver system

Closed this issue · 0 comments

Tweak the resolver system to make it a bit more friendly. The principle components of the system will be:

  • ResolverList - a utility to help compose lists of resolvers. This is what the mutation_resolvers and query_resolvers lists will be on the Meta classes. These should do things like track from where the resolvers were added and be able to report on what's currently in the chain. In the end this is really just an enhanced list.

  • ResolverManager - a utility that knows which chains should be composed together and from where. The manager is what traverses the chain of resolvers (usually by itertools.chaining lists together). Managers will be attached to model Meta classes for each of the queries (create_mutation, update_mutation, all_query, etc). These can be replaced on the Meta.

  • Resolver - an individual resolver, can override the cut-points and resolve methods. I reeeeally want these to be able to have no base class. Not sure it'll work.

Adding custom resolvers to the manager needs to be carried out in either the App or the Project. The plan is to keep all additions in the same place, and to allow Polecat to track where each of them have come from. Perhaps even have a method on Apps and Projects, like .use_resolver().

In apps we will keep separated models and resolvers. In order to override a manager we might need to be bale to lazily load them.

To tackle this one we'll approach like this:

  • Rename the current ResolverChain to ResolverManager, and update the manager to know where to find the appropriate lists to chain together.
  • Create a new ResolverList class to better manage adding resolvers. Replace the standard lists with this one.
  • Remove the declarative meta override system with hooks in apps and projects to add extra resolvers.