Skip to content

Proposal: Object serialization #431

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

Closed
SerafimArts opened this issue Apr 28, 2018 · 1 comment
Closed

Proposal: Object serialization #431

SerafimArts opened this issue Apr 28, 2018 · 1 comment

Comments

@SerafimArts
Copy link

SerafimArts commented Apr 28, 2018

I propose the possibility of serializing composite types (like Object) into scalar values. This functional will be useful in those cases when some object can be represented in a scalar value, but it provides (can) a functional (a set of fields).

We can use the name __toScalar field as the serializable value name. Double underline at the beginning is compatible with the standard adopted for system names.

For example:

Definition

type DateTimeObject {
    year: Int!
    month: Int!
    # ...
    ago: String!
    format(format: String!): String!
    __toScalar: DateTime!
}

Usage

As Object

{
    date {
        year
        month
    }
}
{
    "date": {
        "year": 2018,
        "month": 04
    }
}

As Scalar

{
    date # __toScalar field usage
}
{
    "date": "2018-04-28T04:53:23+03:00"
}
@SerafimArts SerafimArts changed the title [Proposal] Object serialization Proposal: Object serialization Apr 28, 2018
@leebyron
Copy link
Collaborator

leebyron commented Apr 30, 2018

I'd prefer to avoid the type of a field changing based on how its queried. That greatly limits the power available to tools, especially smart clients like Relay and Apollo which store normalized results, such that both types could be encountered in a single application at the same point.

I think this also introduces a serious foot-gun where a query that previously would clearly be a validation error now returns a value, however its not clear that the user intended on the new usage and may result in a hard-to-spot error in their software.

An alternative to this which should work today is simply to provide a field like this (maybe without the underscores, which are system-reserved) and explicitly query it:

type DateTimeObject {
    year: Int!
    month: Int!
    # ...
    ago: String!
    format(format: String!): String!
    toScalar: DateTime!
}

As Scalar

{
    date { 
      toScalar 
    }
}
{
    "date": {
      "toScalar": "2018-04-28T04:53:23+03:00"
    }
}

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