Set defaults for Json options #10057
Conversation
BrennanConroy
requested review from
analogrelay,
halter73 and
mikaelm12
as code owners
| options.PropertyNamingPolicy = JsonNamingPolicy.CamelCase; | ||
| options.PropertyNameCaseInsensitive = true; | ||
| options.MaxDepth = 64; | ||
| options.DictionaryKeyPolicy = null; |
There was a problem hiding this comment.
This is the default, but if you want to be explicit then that's ok too
| options.IgnoreNullValues = false; | ||
| options.IgnoreReadOnlyProperties = false; | ||
| options.PropertyNamingPolicy = JsonNamingPolicy.CamelCase; | ||
| options.PropertyNameCaseInsensitive = true; |
There was a problem hiding this comment.
I believe MVC is leaving this as false. Should there be consistency between ASP.NET Core frameworks?
// @rynowak
There was a problem hiding this comment.
yeah, we were leaving this as false. I'm interested to know why folks think case-insensitive is a better option 😆
There was a problem hiding this comment.
I believe it's because Json.NET is true by default.
There was a problem hiding this comment.
Ryan is making a stand that Json.NET has the wrong default. I don't feel strongly either way other than SignalR and MVC should be consistent
#TeamConsistency
There was a problem hiding this comment.
I don't feel incredibly strongly about SignalR and MVC being consistent. I do feel strongly that case-insensitive is the wrong choice for building a REST api.
I think it's a wierd idea to we would do case-insenstive because legacy.
There was a problem hiding this comment.
As long as JsonNamingPolicy.CamelCase affects reading (IIRC the equivalent didn't in Json.NET?) I'm OK with leaving this false.
There was a problem hiding this comment.
Looks like it affects reading. {"someName":"value"} will serialize into class C { public string SomeName { get; set; } with CamelCase set, and doesn't if it isn't.
There was a problem hiding this comment.
The policy effects serializing and deserializing.
|
This comment was made automatically. If there is a problem contact aspnetcore-build@microsoft.com. I've triaged the above build. I've created/commented on the following issue(s) |
|
I am unable to merge this change because the blazor tests are too flaky... @SteveSandersonMS I think your recent change to make tests more reliable might have made them more unreliable? e0007f4 |
|
@BrennanConroy Sorry for the inconvenience. Something has changed to make the components E2E tests start being flaky since yesterday, but I don't know what. It started before I made the change you mention (my change was an attempt to address it, but didn't). I've been investigating extensively and have got as far as this, which might fix it. |
ghost
deleted the
8 participants
Fixes #9519