Move StrawberryConfig to a typed dict

[patrick91]

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.

[skilkis]

@patrick91 https://peps.python.org/pep-0705/ might be useful if it allows us to inherit from a base class that specifies the defaults

[jgadling]

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).

[patrick91]

@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 😊

[Checho3388]

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?