new API ideas #1372
Replies: 4 comments 5 replies
-
I think it would be nice to just be able to pass a function as DataLoader, instead of having to implement a class just for a function? What do you think? Something like:
then you can something like
Not sure if it is possible, but I am just not 100% convinced on having a custom class just to customise a method |
Beta Was this translation helpful? Give feedback.
-
I agree with this 100%. I much prefer the nested |
Beta Was this translation helpful? Give feedback.
-
Also, while I'm not completely sold on switching away from decorators (there are still many questions to be answered before that could even be considered), inheritance does have one key advantage. It makes the plan to have everything on the internal Strawberry type/object tree be an instance of I will note for the other developers that we can still have the dataclass-style syntax (i.e. with the type annotations), but just swapping the decorator for inheritance. |
Beta Was this translation helpful? Give feedback.
-
What I really like about Strawberry are actually the decorators :D I also don't understand why a The example you gave gives me Graphene vibes: https://docs.graphene-python.org/en/latest/types/objecttypes/ which feels like a downgrade to our easy to understand syntax. Now you need to remember, what do I need to import? ObjectType? InputObjectType? ArgumentObjectType? A simple |
Beta Was this translation helpful? Give feedback.
-
This discussion has been made in good faith. I am not forcing that all of these changes must be implemented in Strawberry. These are rather my opinions and suggestions, from my experience with the library.
pythonic dataloader API
The current dataloader implementation is a port of the js version, which is lacking a few features:
prime
,clear
,clear_all
load_many
methodJavascript is a callback-based language. Therefore, the following javascript code:
would be equivalent to the following python code:
IMO this isn't pythonic. In python, you cannot define functions dynamically, like javascript. Therefore, the load function will be lying around somewhere in the air. We could make the API more pythonic by making the load function a method on the dataloader, like this:
I have already got a dataloader implementation ready locally with all these features, if you're okay with these changes I can submit a PR! :)
this implementation has been inspired by Shopify's graphql-batch gem.
Here's the full API I've been working on!
moving away from decorators
strawberry decorators take too many arguments, that they become multi-line very quickly.
IMO, multi-line decorators don't look right in python. This is rather a personal preference / developer ergonomics related issue.
I am well aware that the core of strawberry has been built around dataclasses. Keeping this in mind, this is my alternative API suggestion:
the above API is inspired by Pydantic, which also uses dataclasses.
You could also see that interfaces are not implemented by inheritance. This is because in GraphQL, there is no concept of inheritance.
I think that this nicely lines up with that philosophy.
I believe with this approach we can also get rid of the dataclass hacks in the codebase.
Beta Was this translation helpful? Give feedback.
All reactions