Favored way of making JToken?
See original GitHub issueHi!
I have to do a lot of back and forth to convert my events to the JToken type. Since Newtonsoft’s JsonConvert’s default converter serializes fsharp types in a very bloated and unnatural way, I have to use FSharpLu.Json’s serializer (see the difference here: https://github.com/Microsoft/fsharplu/wiki/fsharplu.json#option-type).
However, FSharpLu.Json convert object directly to string – which means I have to take the result of that and parse it with JToken.Parse
to get the desired JToken type. That seems like a lot of unnecessary conversion back and forth. Probably not a huge deal for a modern CPU, but still creates a little unnecessary load – especially considering that our app will grow and eventual have a lot of events that needs processing.
So… Is there a way to pass it a string directly without parsing it first with JToken.Parse? Also, when I read the event, I have to do a .ToString() to convert it back to raw json, so that FSharpLu.Json can convert it to an object again.
Also, I’m really curious: How do you guys create Json? Do you use JsonConvert from Newtonsoft? How do you deal with the awkward json it makes for SumTypes & Options types etc.? Is there a better library than FSharpLu.Json? Chiron has zero documentation it seems, and all other json projects look pretty dead 😦 It seems that Json + F# is almost a little unsolved…?
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (2 by maintainers)
Top GitHub Comments
Assorted asides and red herrings:
Re F# Json.NET converters: https://github.com/jet/Jet.JsonNet.Converters is in active use and works - some people seem to want things more complex by adding tuple converters and things. The only major hole I see is https://github.com/JamesNK/Newtonsoft.Json/issues/1827.
Re what to use as a common form in a store lib:- In Equinox, the way we resolved the forces at play (EventStore wants UTF-8 arrays, Cosmos wants json.net rendering is to take inputs as
byte[]
, and then bridging with this converter.@drhumlen I guess that issue is solved. As of now it is very much store specific. Like liteDB is having bson value and Servicestack (dapper in future) is having long string (blob) value. While inmemory database is having object.
So, have a look and if there is question to any specific store I guess than we can always continue with that. 😃