Force Newtonsoft to deserialize into certain formats
I've been using JsonFx for a bit now and am trying to migrate away to Newtonsoft, but the biggest problem I've faced is that when you deserialize into Dictionary<string,object>, and the object is another nested object, it'll become a JObject. Is there any easy way to force Newtonsoft to deserialize T or List<T> (depending on the data), instead of JObject for all nested objects?
24 Replies
I mention T and List<T> because I plan to use this code with code other people wrote, and I don't want to refactor giant swaths of code just so it can handle JObjects.
There is callbacks when deserializing or deserialized
https://www.newtonsoft.com/json/help/html/SerializationCallbacks.htm
Because it's generic object and doesn't carry a type in JSON, it will not able to find the right class for you automatically
@MagicJinn (ping me!)
Unknown User•2mo ago
Message Not Public
Sign In & Join Server To View
For performance reasons. I've tried my very, VERY best to use Swifter.Json, which doesn't have this problem and is faster, but it doesn't work at all. I'm modding a game that has a massive bottleneck in loading times because of JsonFx.
Because it's generic object and doesn't carry a type in JSONWell JsonFx and Newtonsoft have different behaviour in this case. JsonFx deserializes nested objects into T or List<T>, and Newtonsoft into JObject and List<JObject>. I'm not entirely sure how the wiki page you sent helps me with that.
Unknown User•2mo ago
Message Not Public
Sign In & Join Server To View
Nope. Net3.5, Unity 2018.
How would json.net know what
T it should deserialize as?
If you're only letting it deserialize into a Dictionary<string, object>, all it knows about each value is that it's an objectI think the only thing it could do would be to stick to a dictionary (all the way down)
I mean,
JObject implements IDictionary<string, JToken> anyway, so you can treat it as dictionaries all the way down alreadyYeah, would be nice if you got also get rid of
JToken tho
I think OP has two options:
- Don't serialize into a Dictionary<string, object>
- Work with the Newtonsoft types(unless you actually need a concrete
Dictionary)
In which case, a custom deserializer is probably the easiest way to go?
(But OP did say List<T>, not List<object>, so I do wonder whether we're missing some detail)Oh yeah, that's impossibru
Well here's the deal, I can adjust my code to work with newtonsoft types, but I can't adjust the code of the game I'm modding, or at least I can't majorly overhaul it.
The game I'm modding sadly relies on JsonFx's behaviour.
I guess I could recursively cast into the desired type, but I'm not sure what the performance cost of that will be.
I'll test it tho, unless anyone has a better idea.
How is the game serializing the JSON? Do they use classes which you can access?
Can you clarify what JsonFx's behaviour is? How does it deserialize into a
List<T> (where T is not object) without you giving it more type information?Yes.
Did you try to deserialize using the respective type?
Or are classes not compatible with Newtonsoft? (custom attributes, etc.)
Let's say the game is serializing an object of type
Banana.
You could also use that Banana type to deserialize the JSON instead of deserializing into a dictionaryWhen you specify Dictionary<string,object>, it'll convert nested objects to JObjects (or List<JObject>), that I know for sure. When I try to patch the existing methods in the game to deserialize into custom classes, I get non-descript errors, but I'm assuming that's what is happening as well. I can't be certain though, and I'd have to do more testing. I've temporarily given up on it though, since for some reason, when using Newtonsoft, seemingly unrelated methods fail spectacularly at random intervals.
Can you clarify what JsonFx's behaviour is here?
If I'm not wrong, when you deserialize with JsonFx, all nested objects will also deserialize into that type, and arrays will deserialize into lists of that type
Into what type?
The type specified. So new JsonReader.Read<Dictionary<string,object>> will have JsonFx attempt to deserialize every object into another Dictionary<string,object>.
That would be super-odd, and I don't see any mention of that in the readme!
Well perhaps Dictionary<string,object> is just the default for JsonFx, as JObject is for Newtonsoft