expose base context to context resolver, and allow for custom user resolving #71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I changed the dataflow for the contexts a bit to fix two issues:
#49, I needed to be able to specify my own
user resolver
, and preferably disable the default one to prevent redundant DB hits.#51, I needed the base context (db functionality) to be available in the context creator
The first one, can, for example, be used to replace the
users.find
query with ausers.findAndModify
to update hislastActivity
timestamp. Or perhaps to use user accounts other than Meteor's native one.This PR solves the issues above. I changed the way the context is being called, in such a way that it's being called for both the
http requests
as well as thesubscription requests
. The subscriptions now store their headers and cookies in the subscription context, which are then being passed down the context creator as fake request object.This makes context management easier, as it now happens at a single place. This gives us full control of the context, regardless if we are in a subscription or http request.
Another supported scenario is when we need the user object inside the context creator:
Or override the default
db
proxyAgain; all these contexts are merged with the base context, that is
{ db }
ifmeteorAccounts === false
, and{ db, user, userId }
otherwise. And all these contexts are available in both resolvers and queries, as well as subscriptions.resolves #49
resolves #51