-
Notifications
You must be signed in to change notification settings - Fork 9
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
"expandable" fields #24
Comments
Can you expand a little on the idea? Is |
Yeah exactly |
This is basically a The idea can be expanded to allow custom ways to distinguish the types. For example, some rest api returns errors within the body. So the response type is enum Response {
@:json(String) ClientId(id:String); // use this entry when a plain string is encountered
@:json({error:String}) Error(error:{error:String}) // use this entry when it is an object with 'error' key as a string
ClientObj(obj:ClientObject); // otherwise try to parse as client object
} |
Well, As for the error, I know what you mean. I work with an APIs where you can get away with this: enum Result<Data> {
@:json({ success: true }) Success(data:Data);
@:json({ success: false }) Failure(error:String);
} |
will |
No, but I think that would actually be a good interpretation ;) |
Some API allow populating/expanding a particular field:
And it could possible be represented by introducing
tink.json.Expandable
The text was updated successfully, but these errors were encountered: