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

Digging Deeper into properties with objects as values #61

Open
jordanjones98 opened this issue Mar 27, 2018 · 8 comments
Open

Digging Deeper into properties with objects as values #61

jordanjones98 opened this issue Mar 27, 2018 · 8 comments
Labels
enhancement New feature or request

Comments

@jordanjones98
Copy link

Is there a way to dig down into JSON objects where the value is another object?

With the following JSON I would want to get the storeName property. I would think it would be something like this.

@JsonProperty("store.storeName", String) storeName: string = undefined;

{ 'store': { 'storeName':'My Store', 'storeId': 1 }

Is it possible to do anything like this?

@andreas-aeschlimann
Copy link
Member

Of course it's possible, that's the purpose of this library.

Please see the examples in the ReadMe, it explains exactly how to nest objects (example with Country and City).

@jordanjones98
Copy link
Author

I do not want to create a new object for this, I simply want to get the string value "My Store" and save it to a variable. I know you can do stuff like [City] if you send it an array of JSON.

@andreas-aeschlimann
Copy link
Member

Sure, but then you have no type checking, which is kind against the idea of this library.

But in some cases, it might be helpful to save dynamic objects in a property. Use the Any type derived from the json2typescript package. I think there is an example on the ReadMe as well!

@jordanjones98
Copy link
Author

Thanks for the help.

@andreas-aeschlimann
Copy link
Member

No problem. Just to clear things up:

The notation store.storeName makes no sense in the JsonProperty decorator, there should be only plain properties. You can use store instead and then access the store name with store.storeName later.

@osotnikov
Copy link

I would still argue for that feature to be added.
In my case I am simply trying to parse a very convoluted JSON into my simple typescript interface for my service layer model.
The data may come from different sources each of which will have its own convoluted way of representing it as JSON.
What I want is a tool that will allow me to annotate the implementation classes of my model interface, and thus declaratively map the data without the need of a custom mapper function for each one of my sources. I don't have a need to typecheck the JSON I receive.
If that feature is not provided I will have to create separate typescript models for each one of my sources which will end up mimicking the convoluted nature of the source's JSON.
After that I will have to create separate mappers from those models to my simple service layer model interface.
In essence instead of just declaratively mapping into my service layer model by using annotations on different implementations of my interface I will have to create different models for each source plus a mapper for each one of them.

@andreas-aeschlimann
Copy link
Member

It would be an interesting feature. Right now it is achievable, but only with a custom mapper.

One problem is that this mapping is not bijective. You lose data by deserializing, so I am not sure how to define serialization in that case.

@andreas-aeschlimann andreas-aeschlimann added the enhancement New feature or request label Feb 10, 2020
@osotnikov
Copy link

Seems like supporting serialization would complicate the implementation of this feature by a lot. Why not just throw an exception in case serialization is attemped, or simply just ignore the fields that are annotated as nested? A more elaborate solution could be investigated at a second phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants