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
While it's possible to do some automatic merging of partial-result into the return value of transform I fear that this might create some surprises if done implicitly. Although, if we limit PartialResult to map values (which might be a reasonable thing to do) we can derive some very simple semantics à la: "If transform return a non-nil value, merge the partial result into it."
Another point of note is the fact that, if a Person does not exist, just using the partial result will not expose that fact (although the friend list will be empty). But I guess that if users are made aware of this caveat it shouldn't be a significant problem.
The text was updated successfully, but these errors were encountered:
Sometimes, we already know part of the resolution result without doing any work, e.g. IDs or some child resolvables:
Since
:friends
only depends on the already knownid
we don't really need to do anyPerson
I/O if we want to apply the following projection:We could introduce a
PartialResult
protocol, allowing to expose such data:While it's possible to do some automatic merging of
partial-result
into the return value oftransform
I fear that this might create some surprises if done implicitly. Although, if we limitPartialResult
to map values (which might be a reasonable thing to do) we can derive some very simple semantics à la: "Iftransform
return a non-nil value,merge
the partial result into it."Another point of note is the fact that, if a
Person
does not exist, just using the partial result will not expose that fact (although the friend list will be empty). But I guess that if users are made aware of this caveat it shouldn't be a significant problem.The text was updated successfully, but these errors were encountered: