Closed eggers closed 2 years ago
Also, PreserveReferencesHandling = None
I understand that this might break some backward compatibility as the nested objects in a projection wouldn't be referenced correctly, but it could be an opt-in setting that could be turned off to save on request size and de/serialization time.
The nested object treatment is so important that I'd be fearful of doing something subtle ... something you'll forget later ... that leads to a "WTF" support call.
$type on the array is great ... if you're SURE that the array contents are homogeneous. Frankly, we want to stay out of the serialization formatting game.
I admit those generated type names are ugly. But are they actually a problem? Have you measured ... after gzip has done its thing? Our instinct is that zipping minimizes the damage.
If you REALLY want to start trimming the bytes, you are welcome to do so for your app. Breeze client doesn't actually care. It is setup by default for the serialization practices that you find worrisome. But you can change the JsonResultsAdapter
to bend Breeze to whatever serialization format works for you. Don't see that Breeze itself has to change.
If you DO come up with a complete, documented package and want to share it as a plugin, we'd be happy to publicize it.
When you are doing a select projection, the serialized Json has a long
$type
property. For example:"$type":"_IB_w3cYOcY0lxw2mLrFH_pc88Gzr_dks[[System.Guid, mscorlib]], _IB_w3cYOcY0lxw2mLrFH_pc88Gzr_dks_IdeaBlade"
For large collections, this adds a large overhead to the call, especially when you are only pulling one or two properties off of the objects. It would be much nicer to use
TypeNameHandling = None
forDynamicTypes
. Even better would be to somehow put the$type
on the array if all items have the same type.