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

"expandable" fields #24

Open
kevinresol opened this issue May 17, 2017 · 6 comments
Open

"expandable" fields #24

kevinresol opened this issue May 17, 2017 · 6 comments

Comments

@kevinresol
Copy link
Member

Some API allow populating/expanding a particular field:

// not expanded
{
  client: 'some_id'
}

// expanded
{
  client: {
    id: 'some_id',
    name: 'some name',
    // ... more fields
  }
}

And it could possible be represented by introducing tink.json.Expandable

enum Expandable<Id, Obj> {
  Collapsed(id:Id);
  Expanded(obj:Obj);
}

typedef Data = {
  client:Expandable<String, ClientObject>,
}
@back2dos
Copy link
Member

Can you expand a little on the idea? Is Collapsed always String | Int and Expanded always an object?

@kevinresol
Copy link
Member Author

Is Collapsed always String | Int and Expanded always an object?

Yeah exactly

@kevinresol
Copy link
Member Author

kevinresol commented May 17, 2017

This is basically a Either type. But we need some ways to distinguish the two types.
Say in the above example, the client field is actually Either<String, ClientObject>.
When the parser reads a " it parse the field as a string and produce a Left, otherwise try to parse an object and produce a Right

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 Either<{error:String}, ClientObject>. To make it more general, the @:json meta might be enhanced as follow:

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
}

@back2dos
Copy link
Member

back2dos commented May 17, 2017

Well, Either wouldn't actually be that hard. The generalization however is a bit tricky, in that you may have multiple branches for {, which you may have to back out of.

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);
}

@kevinresol
Copy link
Member Author

will @:json({error: null}) be equivalent to the non-existence of the error field?

@back2dos
Copy link
Member

No, but I think that would actually be a good interpretation ;)

@kevinresol kevinresol mentioned this issue May 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants