Comments (4)
I thought of this while working on this PR: #3140
I think maybe one use case would be to update the context based on the directive on the operation
from strawberry.
In my mental model, field extensions handle this. This is also why we once talked about allowing field extensions to apply schema directives to the respective fields. I'm not sure about the benefits of merging that into strawberry.directive
. In any case, we need to define one clear path to solve such problems.
Either
Field Directive -> Applies Field extension and adds directive to schema
Or
Field Extension -> Can Specify a directive that is added when the extension is added
from strawberry.
@erikwrede this is for operation directives 😊
from strawberry.
@patrick91 oops, the mentions of field wrongly made me think of field extensions 🤦 . As to this case, I believe we should allow also modifying the resolver & variables, i.e. pass the resolver to the directive function.
Speaking of field extensions, maybe we can re-use / unify some of that code as the flow of calling an operation extension would be very similar to that of a field extension.
Regarding the execution timing of directives, there's an important decision to be made:
Post-Individual Resolver Execution: Do we apply the directive immediately after each field's resolver has run? This would mean the directive operates on the output of a single field as soon as it's available. The advantage is that we can modify or utilize the output right away. For example, if a field resolver returns a string and we want to change it to uppercase, the directive can do so immediately after that specific resolver finishes its job.
Post-Subtree Resolution Execution: Or, should we wait until an entire section of the query (a "subtree") has been fully resolved before executing the directive? It allows the directive to consider the larger picture—the collective result of a type and all its nested fields—before making any changes.
The key question here is about timing: do we want to intervene early, field by field, or do we want to wait and have the complete context of a larger part of the graph before we act?
For field extensions / schema directives, the immediate answer for me is Post-Individual Resolver Execution. However, I am unsure wether this is the right way to go for Operation directives. As a user, I would expect such directives to be applied on the actual result I would normally receive. We can for now postpone this decision by just focusing on fields without a selection set, but this will be a discssion we need to have as we grow this feature 😊
from strawberry.
Related Issues (20)
- Field Extensions incorrectly rely on resolver context to determine execution context for their own resolution. HOT 1
- schema-codegen should generate mutation methods HOT 1
- optional input fields are not allowed to be strawberry.UNSET HOT 2
- Python code generation from schema has invalid forward type references HOT 1
- AttributeError: 'GraphQLWSConsumer' object has no attribute '_handler' HOT 3
- Outdated documentation or a bug: `KeyError: 'ws'`? HOT 3
- Incongruity with the `Context` type across the library. HOT 2
- strawberry.asdict doesn't recognize strawberry.UNSET
- Expose fragments as a property on Info HOT 2
- Unresolved attribute reference 'from_pydantic' in PyCharm HOT 1
- Incorrect template rendering when overriding graphql IDE template HOT 2
- Ability to change StrawberryConfig's relay_max_results value HOT 1
- Pydantic models as a default values in inputs
- To modify status code of GraphQL query/mutation response right before it returns a result HOT 1
- Malformed request with `operationName` that isn't in `query` gives 500 error: `Can't get GraphQL operation type`
- Strawberry cannot resolve type by inheriting a generic type with union type applied to it. HOT 1
- DataLoader custom cache cannot be used with redis HOT 2
- Input extensions, needed for automatic peristed queries
- Maximum recursion depth exceeded when running codegen
- Support codegen for GQL files with multiple operations
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from strawberry.