STJ and Frozen collections

[TonyValenti]

Will STJ be updated to support them?

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Will STJ be updated to support them?

Author:	TonyValenti
Assignees:	-
Labels:	area-System.Text.Json, untriaged
Milestone:	-

[eiriktsarpalis]

We could, other immutable collections are already supported by STJ. One small concern I have is that whatever baked-in converters we do ship need to make an explicit choice as to whether the optimizeForReading flag is enabled when deserializing; whatever we do end up picking won't be user-configurable. @stephentoub might have opinions about this.

Serialization for frozen collections should already be possible (since they all implement the right interfaces), it's deserialization support that needs to be added. One possible course of action is that we do nothing and simply expose support for parameterized constructors in the contract model: frozen collections are a prime example of where such functionality would be useful.

[stephentoub]

One small concern I have is that whatever baked-in converters we do ship need to make an explicit choice as to whether the optimizeForReading flag is enabled when deserializing; whatever we do end up picking won't be user-configurable. @stephentoub might have opinions about this.

I'd want to better understand the user scenario for serializing/deserializing these as json. The intent of optimizeForReading:true is for collections expected to be created once and then used repeatedly for a very long time, as creating them is more expensive, with the idea that spending more time at construction is a good tradeoff if there's going to be many, many subsequent reads. If these collections are being routinely serialized back and forth as part of some communication scheme, I'd venture it'd be rare for them to them stick around for a very long time. And if the odd one was, a new frozen collection could be created from it with the appropriate settings. It'd likely be cheaper to just deserialize these as a standard Dictionary<>.

[eiriktsarpalis]

Agreed. Generally speaking I'd expect collections on deserialized DTOs to be ephemeral in most cases so frozen collections aren't necessarily the ideal representation for doing that. At the same time users expect serialization to "just work" with the type at hand so perhaps having a default that optimizes for deserialization would be good enough for most use cases.

[TonyValenti]

In my organization, we use records and Immutable structures for all JSON-based communication. We often load JSON into an in-memory ImmutableDictionary cache and then access it from there.

From what I was reading, it seemed like FrozenDictionary would give us better performance which is why I asked.

[eiriktsarpalis]

Apropos, any new collection type that we support would also need to work in the source generator, currently this means adding new dedicated APIs in the JsonMetadataServices class. This suggests to me that tackling #71944 might let us kill two birds with one stone.

[terrajobst]

In my case I have an immutable data structure that acts like a cache. It's constructed once and sticks around as long as the process exists. However, I want to save it to disk and reload it the next time, which is why it would be convenient if I could use frozen collections as this means I can serialize the cache as-is.

[julealgon]

@stephentoub

If these collections are being routinely serialized back and forth as part of some communication scheme, I'd venture it'd be rare for them to them stick around for a very long time.

I do have an upcoming scenario (for a game) where I want to have parts of the game be data-driven and obtained via an API request during initial load. The results of this call will not be updated for the remainder of the session, which could be minutes, hours, or days: basically unbounded.

It's not a very common scenario I admit though.

And if the odd one was, a new frozen collection could be created from it with the appropriate settings. It'd likely be cheaper to just deserialize these as a standard Dictionary<>.

That's probably fair enough though, and likely what I would do in the scenario above if deserialization wasn't supported.

[stephentoub]

simply expose support for #71944 in the contract model: frozen collections are a prime example of where such functionality would be useful

@eiriktsarpalis, should we support collection expression builders? FrozenSet has one, and FrozenDictionary will once dictionary expressions are a thing.
cc: @CyrusNajmabadi

[TonyValenti]

I would love it if you did.

[eiriktsarpalis]

I think we should.

[eiriktsarpalis]

One potential concern is the serializer handling types differently depending on whether the target uses CollectionBuilderAttribute. We should make sure types using the attribute are already supported if they exist in ns2.0

[codymullins]

With regards to @eiriktsarpalis's comment:

I'd expect collections on deserialized DTOs to be ephemeral in most cases so frozen collections aren't necessarily the ideal representation

I am running into this when serializing state to persist on page reloads or sharing links. I don't really need a separate dto if not for this -- the code is already client side via wasm. So just fyi, DTO serialization may not be the only use case here.