strawberry
strawberry copied to clipboard
strawberry-graphql
Move StrawberryConfig to a typed dict
as suggested in https://github.com/strawberry-graphql/strawberry/pull/2698#issuecomment-1631030171
we should change strawberry's schema config to be a type dictionary, I think this will make the dx a bit nicer, since you can do this:
import strawberry
...
schema = strawberry.Schema(..., config={"auto_camel_case": False})
which is a reduction of one import (and bit less characters) 😊
The main disadvantage for users it that they might not get autocompletion if their editor is not setup well.
The main disadvantage for us is that it might get a bit cumbersome to get values (or fallback to default values).
In any case if we do this, we should deprecate the old config, and write a codemod, which should be easy to do 😊
Upvote & Fund
- We're using Polar.sh so you can upvote and help fund this issue.
- We receive the funding once the issue is completed & confirmed by you.
- Thank you in advance for helping prioritize & fund our backlog.
@patrick91 https://peps.python.org/pep-0705/ might be useful if it allows us to inherit from a base class that specifies the defaults
As an alternative to TypedDict, which is pretty basic - the pydantic_settings module has an excellent configuration interface: https://docs.pydantic.dev/latest/usage/pydantic_settings/
It allows setting default values, enforces type/value validation, can take overrides from env vars by default, and be extended to read settings from a variety of different sources (config files, etc).
@jgadling thanks for the suggestion! I think that would be neat, but I'd prefer to keep the base dependencies at a minimum if possible 😊
Hi @patrick91 , I'd like to contribute on this one. If you're Ok I'll create a MR with a proposal.
Changing straweery.Schema to expect a dict instead of a dataclass, would change the signature of the constructor in an incompatible manner. Have I understood this properly? Would this be a major change in RELEASE.md then?
