-
Hi everyone, I'm writing to try to get some information on the best practice for using contextValue. From docs I see that it is possible to use this parameter to route a shared object to all resolvers:
Currently this package routes the user object through an execution middleware but one could pass a more structured object/array what he needs (user, tenancy, dataloaders?, ..) even implementing (from what I understand) the ScopedContext interface if yes wants to keep it “isolated”. This could allow you to manually force the context (e.g. in tests) in operations like GraphQL::query (which could be a good or bad thing). What would be the best practices? Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
But no one is stopping you from doing so: just return That's what I do and the context holds some requested-shared information, which is quite useful. Though in recent years I reduced the "shared state" as much, it's like a global var and thus always prone to create hard to predict code. But anyway, it's possible. Or did I misunderstand? |
Beta Was this translation helpful? Give feedback.
But no one is stopping you from doing so: just return
new YourSuperChargedContext
, you even type hint it in every resolver.That's what I do and the context holds some requested-shared information, which is quite useful.
Though in recent years I reduced the "shared state" as much, it's like a global var and thus always prone to create hard to predict code.
But anyway, it's possible. Or did I misunderstand?