Announcement

Collapse
No announcement yet.

Support for JSON Type Converters or alternative way to perform custom deserialisation

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support for JSON Type Converters or alternative way to perform custom deserialisation

    The Json.Serialize and Json.Deserialize method in Bridge 16 look really good and it's helpful having the JsonSettings options (so that things like "$type" can be injected by enabling "TypeNameHandling") but I have some types (in particular the "NonNullList") that serialise fine (because it implements IEnumerable) but need some custom code in order to be deserialised*.

    * (Update: Sorry, this wasn't very clear - with JSON.NET, because NonNullList<T> implements IEnumerable<T> then it will be serialised into a JSON array but would then require some special deserialisation logic.. however, Bridge won't serialise it because it doesn't implement [Reflectable])

    With JSON.NET, I can specify additional Converters for a JsonSerializer to use (where each converter can add special handling for particular types) or (iirc) I can implement ISerializable and add custom behaviour that way.

    Bridge doesn't appear to support either of these and I wondered if you had any plans to support either or both or something else that I could use. In an ideal world, I would use types like NonNullList on the server side (in .NET code) and use the same type in Bridge code (there would be different projects built for the server and client but classes such as NonNullList could be shared using a shared project, perhaps) and use JSON.NET and Bridge serialisation / deserialisation to pass data back and forth. In order to do this, though, I need a way to provide "hints" to the (de)serialisation logic one way or another.

    One alternative is to resort to translating to and from a set of "safe to serialise" types before sending information over the wire but this would likely lead me to having to write a lot of these types (and it would either have to be code gen'd or be written by hand; which would make it quite easy to make silly mistakes with).

    I wondered if you had any thoughts about this sort of use case?
    Last edited by ProductiveRage; 2017-05-17 @ 09:18 AM.

  • #2
    DanTup mentioned this article as being a nice summary of custom reading and writing:
    (though it concentrates more on using attributes to specify custom serialisation logic for types while examples that I had in mind configured JsonSerializer instances with any required custom serialiser).

    Comment

    Working...
    X