8000 Allow contexts provided to resolvers to have attributes · Issue #105 · graphql-python/graphql-server · GitHub
[go: up one dir, main page]
Skip to content

Allow contexts provided to resolvers to have attributes #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
leonardwellthy opened this issue Jan 9, 2023 · 1 comment
Closed

Allow contexts provided to resolvers to have attributes #105

leonardwellthy opened this issue Jan 9, 2023 · 1 comment

Comments

@leonardwellthy
Copy link
Contributor
leonardwellthy commented Jan 9, 2023 •
edited
Loading

(I filed this issue as graphql-python/graphene-mongo#198 in graphene-mongo, but possibly the solution should be implemented in graphql-server)

A graphql resolver function is provided a context which can hold important information like the currently logged in user or the current HTTP request

In Graphene, graphene-django, graphene-mongo and the old flask-graphql , the context is an object that can have attributes read and written to it (for example context.db.loadHumanByID(args.id) ). However, graphql-server provides a dict that must be accessed by key name e.g. context['request']

If we were programming in Javascript, both syntaxes would work. It would be nice if the context provided by graphql-server could be made more flexible, for instance by making the default context a collections.UserDict.

edit: I see now that the class property context on the GraphQLView can be specified, so that let's me workaround my particular use case
@leonardwellthy
Copy link
Contributor Author

#106

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@leonardwellthy
0