Clarified context passing for queries when used from server #3153
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.
When calling Operations from the server (instead of the client), you need to pass the information about the authenticated user, if Operations expects it. On client that happens automatically, on server you have to specify it.
You can do that by passing
context
object, and specifyinguser
field in it. That is what we say in the docs.However, what was not clear to me (when I was answering a user and reading our docs to figure it out), was what happens with the rest of the
context
object. If we pass our owncontext
, what aboutcontext.entities
if Operation needs that -> will that be automatically set for us, so "merged" into thecontext
that we provide, or are we then expected to provide that also, since we provided our owncontext
and therefore took over the "control" of it in our hands?Turns out, the
context
we pass will be merged with the "wasp prepared"context
, so it is enough to just specify theuser
and notentities
or anything else.So what I did was add a single sentence to the docs that explains that the rest of the
context
will be provided automatically.