Open mecampbellsoup opened 1 month ago
@mecampbellsoup I think adding support for (un)snake casing would be nice, but we would need to do via a schema configuration, since that depends on how the schema has been configured π
@mecampbellsoup I think adding support for (un)snake casing would be nice, but we would need to do via a schema configuration, since that depends on how the schema has been configured π
What API are you envisioning? (I know I opened the issue so it's rich for me to ask you that but, humor me! π)
Then at the object type level might it be configurable similarly to Pydantic's model_config
or something?
class StorageClassPyd(PydanticModel):
model_config = ConfigDict(alias_generator=to_camel, populate_by_name=True)
I was thinking something like this:
@strawberry.input
class Something:
name: str
something_else: str
data = Something(name="ABC", something_else="ABC")
strawberry.asdict(data, config={"auto_camel_case": True}) # this would be the same config passed to the schema
but while writing this I realised that asdict
wasn't really made for this use case, the camelcase behaviour is something that's done on the schema level most of the time, so maybe we should have something like schema.serialize(data)
, but I'm not convinced it's a good/useful feature to have.
What's your reasoning behind not passing a dict to your test? π
What's your reasoning behind not passing a dict to your test? π
Laziness!
I just thought that this type of camel case to snake case conversion was happening internally quite a bit, since the FE JSON is typically formatted w/ camelCase
keys, and all the Python BE types/code tends to assume snake_case
, so I was hoping to grok an easy way to replicate that observed behavior.
I like using the strawberry types as a starting point though because that's the "public facing API", so in integration tests passing form data to GQL resolvers, it feels like the right thing (as opposed to e.g. using the Pydantic types).
To your point though, we can pass dictionaries in tests.
I'm writing some integration tests that use an HTTP client to hit our GQL API like so:
In this example,
saml_configuration_form
is a strawberry input type:This gets me halfway there, but
strawberry.asdict
seems to be limited to snake-casing (or rather, limited to however the fields are cased on theSAMLConfigurationPyd
model in this example).Would it be possible to support something like:
That way I can easily inflect the serialized form's keys.
Upvote & Fund