How come FORMAT_FIELD_NAMES isn't recursive on dictionaries?

[jimbofreedman]

(I saw some other discussions that seem tangentially related to this but regarding OpenAPI)

Looking at the tests around JSON_API_FORMAT_FIELD_NAMES, the test cases are:

@pytest.mark.parametrize(
    "format_type,output",
    [
        (False, {"full_name": {"last_name": "a", "first_name": "b"}}),
        ("camelize", {"fullName": {"lastName": "a", "firstName": "b"}}),
        ("capitalize", {"FullName": {"LastName": "a", "FirstName": "b"}}),
        ("dasherize", {"full-name": {"last-name": "a", "first-name": "b"}}),
        ("underscore", {"full_name": {"last_name": "a", "first_name": "b"}}),
    ],
)

With the subobject included in the test but not formatted, it looks to me like it's a conscious choice not to format subobject field names in the same way. May I ask why that is?

[edit] test_parse_preserves_json_value_field_names has given me a hint - wouldn't want to taint any third-party objects being included. Do you think some configuration flexibility might be possible here? e.g. JSON_API_FORMAT_FIELD_NAMES_RECURSIVE or something?

[sliverc]

You can find a detailed explanation in PR #420. In short only the field name is part of the JSON:API specification but the value (a value might be nested json) should remain untouched.

For me an option JSON_API_FORMAT_FIELD_NAMES_RECURSIVE does not make sense in the context of DJA as the value is not specified how it needs to be formatted and therefore needs to be kept untouched by the DJA framework.

What you can do is though to overwrite to_internal_value and to_representation either of a nested serializer, a DictField or JSONField. where you then call utils.format_field_names recursively.

[jimbofreedman]

Thanks for the pointer. I guess I got confused because the behaviour differs from stock DRF, but it definitely makes sense within the bounds of the JSPON:API spec. I'll find another way!