result transformer

[nevir]

Please note that this PR depends on, and includes #377. For a standalone diff, see convoyinc/apollo-client@store-context...store-result-transformer

---

This adds a resultTransformer callback that can be used to modify the results of a query just before they are handed off to the caller.

For example, we're crazy and like to attach a prototype to response objects, as a convenient place to hang read only helpers.

[nevir]

Is this a PR you guys would accept, or should I try a different approach?

[stubailo]

Hey sorry, I've been totally swamped with PRs, trying to get through them all as fast as possible. Started out with 17 this morning and down to 12 now...

[stubailo]

I think this could be a good hook to have, so definitely in favor of it. But I'm not sure about the implementation. Why not just transform the whole result blob right before it's returned from watchQuery? Doesn't seem worth it to thread it all the way through to diffQueryAgainstStore etc.

[nevir]

Hey sorry, I've been totally swamped with PRs, trying to get through them all as fast as possible. Started out with 17 this morning and down to 12 now...

No rush, mostly just wanted to make sure it's worth maintaining & rebasing :)

I think this could be a good hook to have, so definitely in favor of it. But I'm not sure about the implementation. Why not just transform the whole result blob right before it's returned from watchQuery? Doesn't seem worth it to thread it all the way through to diffQueryAgainstStore etc.

Hmm, that I don't have a great answer for. I initially went down that road because I already had the context machinery (to support #376).

However, it does have the nice property that the callback fires for every returned node. If I got only a single call (right before watchQuery returns), I would have to turn around and walk the entire result to find those nodes again (for example, to look for anything with __typename).

But, the single callback approach allows for transformations that need to look at more than just a node at a time. I think your approach makes more sense, unless I've inadvertently convinced you otherwise

[stubailo]

Yeah I just like the approach that has the least internal machinery. Just having a callback that runs on every result seems the most sense, and if we have a concrete reason to add something more complicated later we can do it then.

[stubailo]

Gonna close this since the other approach will probably have totally different code!

[nevir]

Yup, SGTM