-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JsonSerializer should support field as well as properties #876
Comments
Sounds good to me |
@ahsonkhan Should this be implemented via emitting IL or via reflection accessors? |
It would depend on which approach yields better performance. I believe IL emit is the way to go (with a fallback to a reflection-based code path if necessary). @steveharter can provide additional guidance, or correct me if I am mistaken. |
Context from a user's issue where fields not being supported causing a pain-point:
|
@steveharter Without dotnet/corefx#38233 I'm not able to implement this one. Later it would be possible to access fields without code emit, but it's work in progress by @GrabYourPitchforks. |
IL emit also has the advantage of letting us write to readonly fields, something I have not been able to achieve with expressions or, if memory serves, with reflection. In case anyone trips on the idea, note that, while writing to readonly fields may seem questionable at first glance, it actually makes perfect sense during deserialization. After all, deserialization is an alternate way to construct a fully populated object. It is comparable to using a specific constructor that takes a parameter for each field - a perfect using case for assigning our readonly fields. The fact that deserialization is often not implemented by using such a constructor does not change the fact that we are trying to constructor a fully populated object. In other words, being able to assign readonly fields during deserialization is valuable and makes sense. |
From @MarkStega in https://github.com/dotnet/corefx/issues/41374
|
From https://github.com/dotnet/corefx/issues/41420 by @codexguy:
|
From @kaamil1984 in #552:
|
Any progress here or what is the prefered workaround for this issue? |
Previously it was blocked by the team due to optimizations. Recently pinged @ahsonkhanon this, but have received no answer. Anyway I'm going to move the PR to dotnet/runtime in a few days. |
@YohDeadfall does this address named tuple serialization as well? I use Newtonsoft Json for now but it serialize this |
Don't think that named tuples worth support because names available only in very limited number of cases and in most of them it won't work well. Names provided by |
The issue was, ValueTuples aren't serialized properly. Here's the link dotnet/runtime#876. For now, we shouldn't use ValueTuples for DTOs at all, instead we need to create DTO classes for each part of the response. + Integration test.
The issue was, ValueTuples aren't serialized properly. Here's the link dotnet/runtime#876. For now, we shouldn't use ValueTuples for DTOs at all, instead we need to create DTO classes for each part of the response. + Integration test.
@YohDeadfall Ok, I see. Do I understand you correct if I could use public class Home {
public string Heading { get;set; }
public ArtDirection ArtDirection { get;set; }
}
public class ArtDirection {
public string Alt { get; set; }
public (string Landscape, string Portrait, string Fallback) Images { get; set; }
} |
Yes, it is only one possible way to get names of tuple members, but in other cases it isn't possible (when you pass a tuple directly to the serializer). Therefore, supporting It's better to have a class/struct for that kind of scenario. |
I mention a workaround for |
|
Any update on this? |
From @leung85 in #34001:
|
@YohDeadfall, are you still interested in implementing this feature? API & behavior spec approved in #34558: namespace System.Text.Json
{
public partial class JsonSerializerOptions
{
public bool IgnoreReadOnlyFields { get; set; }
public bool IncludeFields { get; set; }
}
}
namespace System.Text.Json.Serialization
{
[AttributeUsage(AttributeTargets.Property |
Attributes.Field, AllowMultiple = false)]
public sealed class JsonIncludeAttribute : JsonAttribute
{
public JsonIncludeAttribute();
}
} |
Will take a look and implement. Probably will resurrect the closed PR with the requested API above. |
Spent a lot of time understanding why I don't see the fields in my output. Anyway, using 3.1, still don't see this option. Any news? thanks |
It should be .NET 5 feature. |
@YohDeadfall, can you take another look soon? Field support is one of the top priorities for System.Text.Json in 5.0, and we'd like to get the feature in a preview for folks to try. |
Planned to reopen the PR on this weekend. Working on this won't be problematic, but the snake case naming policy will since there is a stuck discussion. |
Sounds good 👍
We should address snake case separately from this issue - #782 (comment). |
While it isn't too late, there are a few |
This was considered, but we chose |
Could we have the JsonInclude also apply at the struct level? |
What did you mean? It's not working for structs or something else? |
Updated by @layomia: I'm pasting the API approved in #34558. Please see that issue for review notes and further discussion.
Original proposal (click to view)
There is no way to serialize and deserialize fields using
JsonSerializer
.While public fields are generally not recommended, they are used in .NET itself (see value tuples) and by users.
This feature was scoped out of v1 (3.x) due to lack of time, as we prioritized supporting simple POCOs with public properties.
We elected to have an opt-in model for field support because it would be a breaking change to support them by default, and also because public fields are generally not recommended. Other serializers, including
Newtonsoft.Json
,Utf8Json
, andJil
, support this feature by default.The text was updated successfully, but these errors were encountered: