Skip to content
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

Request: System.Text.Json Serialization with Opt-In #30180

Closed
Symbai opened this issue Jul 8, 2019 · 8 comments
Closed

Request: System.Text.Json Serialization with Opt-In #30180

Symbai opened this issue Jul 8, 2019 · 8 comments

Comments

@Symbai
Copy link

Symbai commented Jul 8, 2019

Similar to https://www.newtonsoft.com/json/help/html/JsonObjectAttributeOptIn.htm an option to serialize only specific properties would be very useful. Especially if the amount of properties to include are less than the properties to exclude.

For example I have one base class Animal where lots of animal type classes inherits from: Cat, Dog, Horse, Monkey, ... (and imagine https://github.com/dotnet/corefx/issues/39031 gets addressed sometime). It's easier to just include the property by a custom attribute rather to exclude all unwanted for maintainability reasons. For the same reasons I also don't want to mess around with a sort of converter or something when there are many classes.

In Newtonsoft Json it was easy and worked very well by just adding a custom attribute on top of the class and skip >300 JsonIgnore attributes on every property.

@ahsonkhan
Copy link
Member

From @cedemax in https://github.com/dotnet/corefx/issues/41633

Newtonsoft.Json supports a convenient way to serialize certain types of classes using attributes only, by specifying the [JsonObject(MemberSerialization.OptIn)] attribute on the class, and then picking the desired properties to serialize using the [JsonProperty] attribute on the. This does not seem to be supported yet?

Is there a viable workaround other than writing custom converters for all those classes?

@layomia
Copy link
Contributor

layomia commented Nov 23, 2019

This can be achieved using DataContractAttribute and DataMemberAttribute, if we provide support for them: https://github.com/dotnet/corefx/issues/38758. We should be careful not to provide too many ways to do the same thing.

@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the Future milestone Feb 1, 2020
@AraHaan
Copy link
Member

AraHaan commented Jun 27, 2020

@layomia is this still in the works for 5.0?

A library I depend on uses Newtonsoft.Json because S.T.J is missing this and so then my project pulls in S.T.J for what it does itself, and then that also depends on Discord.Net (which is the library that uses Newtonsoft.Json for this opt-in stuff as a class level attribute itself).

It just would be nice to finally be able for someone like me to just pr that library with the updated S.T.J that has this feature so that way it can drop Newtonsoft and my pain would be gone.

@eiriktsarpalis
Copy link
Member

Duplicate of #593

@eiriktsarpalis eiriktsarpalis marked this as a duplicate of #593 Oct 19, 2021
@Symbai
Copy link
Author

Symbai commented Oct 20, 2021

@eiriktsarpalis Mine was posted on July, the duplicate was posted in December. So the others has duplicated mine actually.

@eiriktsarpalis
Copy link
Member

Sure, keep in mind this is all about keeping our backlog tidy not giving credit to the earliest feature request. The other issue happens to contain more recent activity and links to related issue we are planning, which is the only reason why I closed this one. I would recommend continuing to contribute to the other issue (either via upvoting or commenting on the design discussion).

@krwq
Copy link
Member

krwq commented Oct 20, 2021

It's all about which one will take less work to provide details from both - the other one seem to have more activity and details. What I'm curious is how the other issue has lower number even though yours was created earlier...

@svick
Copy link
Contributor

svick commented Oct 20, 2021

@krwq

What I'm curious is how the other issue has lower number even though yours was created earlier...

I think the explanation is here:

msftgits transferred this issue from dotnet/corefx on Feb 1, 2020

The other issue seems to have been already created in dotnet/runtime, it was never moved.

@ghost ghost locked as resolved and limited conversation to collaborators Nov 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants