AFAIK, the only way to feed JsonSerializerOptions to JsonPatchDocument is to pass them through constructor. However, when running methods of this object, e.g. Replace, the resulting Path property is written as it was passed, not converting it's string to a needed NamingPolicy:
var serializerOptions = new JsonSerializerOptions
{
// this requires targeting net8.0
PropertyNamingPolicy = JsonNamingPolicy.KebabCaseLower
};
var patch = new JsonPatchDocument<User>(new(), serializerOptions);
patch.Replace((v) => v.Name, "Bob");
var patchStr = JsonSerializer.Serialize(patch, options: serializerOptions);
Console.WriteLine($"patch: {patchStr}");
The patch.Operations[0].Paths value is going to be /Name in this example, as a property name, while expected to be /name , as should be forced by JsonSerializerOptions. The patch is applied anyways (due to #10 I guess?), but still would be nice to see appropriate values in requests
I understand, that json values usually don't need to be affected by PropertyNamingPolicy, but I think it should be respected in this case, since Path values are related to property names, when it comes to original json
AFAIK, the only way to feed
JsonSerializerOptions
toJsonPatchDocument
is to pass them through constructor. However, when running methods of this object, e.g.Replace
, the resultingPath
property is written as it was passed, not converting it's string to a neededNamingPolicy
:The
patch.Operations[0].Path
s value is going to be/Name
in this example, as a property name, while expected to be/name
, as should be forced byJsonSerializerOptions
. The patch is applied anyways (due to #10 I guess?), but still would be nice to see appropriate values in requestsI understand, that json values usually don't need to be affected by
PropertyNamingPolicy
, but I think it should be respected in this case, sincePath
values are related to property names, when it comes to original json