-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Support Strongly Typed Serialization #211
Comments
Hi @SGStino, could you provide a sample project showing the issue you're describing. I'm struggling to understand the issue based on the description. |
When using trimming and serialization, you can't deserialize , you need to specify the type, and the type needs to be known in the source generated serialization context. |
I'll be honest, I'm not sure I understand what you're attempting to do. I haven't done any work whatsoever with source generators. I think, for now at least, this is something you would need to handle in your own code and just use the |
Well, the Ps: if you want to know more about the source generation in System.Text.Json: |
I think this is now supported thanks to some new APIs added to .NET 7/8. I've put the following in my
|
OK, so I was a bit premature there. There's a small code path that isn't happy about enabling source generators. I'm going to see if I can put together a PR to fix it |
The current serialization model assumes JsonSerializer.Deserialize() will always work: (here)
This means that as soon as you use a JsonTypeInfoResolver that doesn't know what to do with object, like a source generated JsonSerializerContext, you essentially can't use the library anymore.
I'm not certain one could get away of making RaiseOnChangingAsync Generic, in most cases where the old value and the new value are of the same generic type, AND haven't changed over time, that would work.
But if one were to put different types in the same key, then that would certainly break. Where the old value is of OldType, the new of NewType: that would invoke
RaiseOnChangingAsync<NewType>
, which on its turn would invokeGetItemInternalAsync<NewType>
instead ofGetItemInternalAsync<OldType>
, and you'd have a conflicting deserialization.One could skip the entire ILocalStorageService and use IStorageProvider directly with custom, fixed, serialization, but the accessibility of
internal interface IStorageProvider
sadly doesn't allow that.The alternative that remains is to use
GetItemAsStringAsync
, without aJsonSerializationContext
on the library, and use a Serialization Context to generate the string. Which seems to work, but with a fair amount of overhead.The text was updated successfully, but these errors were encountered: