Skip to content
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

Custom global deserializer OR onDeserialization hook #2436

Closed
kotlinlukas opened this issue Sep 11, 2023 · 2 comments
Closed

Custom global deserializer OR onDeserialization hook #2436

kotlinlukas opened this issue Sep 11, 2023 · 2 comments

Comments

@kotlinlukas
Copy link

What is your use-case and why do you need this feature?

I want all strings during any deserialization to be trimmed to null, so calling .trim() on the string and then setting it to null if the string is blank. But the second part is technically optional, so if I can just automatically trim all surrounding whitespace from my strings I would be happy.

Currently this is possible, but very ugly - I could mark every single field/file in my entire library with an annotation for a custom deserializer, or use a typealias like TrimmedString to shorten this, but that is prone to errors and inconsistencies (by forgetting) and also just pretty ugly.

Describe the solution you'd like

Option 1 - Allow me to specify a global default deserializer for a class, like other libraries do - so that I can create a custom StringDeserializer, configure deserialization globally (once!) so that if it's a String, it will use that deserializer, and then I can implement my custom functionality

Option 2 - (second preference), add a hook/callback to deserialization and allow me to provide a custom function ( String -> String, or more generically, T -> T) that I can use to operate on the freshly deserialized entity before the value is stored in its destination

@sandwwraith
Copy link
Member

It was discussed in #507 and #2279 (comment). In short, we do not have currently plans for such a feature, as it contradicts framework design. However, it may be implemented in future.

@pdvrieze
Copy link
Contributor

I would say this is a good case for a custom format (that perhaps mostly delegates to the standard json format). Then your custom format can intercept nullable string (de)serialization and implement your desired behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants