-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Subscriptions RFC: How to pass payload data into subscription resolvers? #280
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.
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
Comments
So, here are some options:
I think 3 wouldn't be great, because I don't think non-root resolvers should have access to the payload. 2 also seems weird, although it's the least "breaking" of these options. That seems to leave us with:
For passing as the root object, the extra information we want to gather is how people are using this parameter today. For myself personally, I put everything on the Passing as an extra parameter also comes with some questions. Does every resolver get this extra argument, or do subscription resolvers get a different number of arguments than others? Also, this could end up being a pretty big breaking change for the GraphQL execution libraries, since the arguments will end up moving around. I suppose there is another option - the spec says it's an "extra parameter", but the actual implementations put it somewhere implementation-specific, for example as a property on |
I'd prefer But I think this is entirely an implementation-level question. The GraphQL spec doesn't talk about things like |
rootValue it is. Since this is specific to the GraphQL-js implementation, it will be left out of the spec. |
I see the tradeoff similar to how @taion describes it. While #267 appropriately calls out that this can be confusing if resolvers are relying on |
How should we pass event payloads/data into the subscription resolvers?
@stubailo @taion @leebyron @dschafer @wincent
Continuing the conversation from: #267 (comment)
The text was updated successfully, but these errors were encountered: