You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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
Usage
As Object
As Scalar
The text was updated successfully, but these errors were encountered: