Is @proxy intended as a source-node or GraphQL alias?

[coreylionis]

I've added a custom field to the Mdx nodes in my personal blog and noticed some unusual behaviour when adding a custom resolver.
The relevant part of the schema shape is
{ Mdx: { extract, fields: {extract}},
with extract proxying fields.extract. When the data is created statically, proxy behaves as expected and extract mirrors fields.extract. However, when I add a custom resolver for fields.extract querying extract returns the unresolved form. Similarly, resolving the extract field leaves fields.extract invariant.

The docs are a bit ambiguous here... if @proxy is mostly intended for flattening queries this would be unexpected behaviour, but if it's intended for segmenting references to the source node the behaviour I'm seeing makes sense. Clarification would be much appreciated!

[sueun-dev]

It's an alias for the stored value, not for the resolved field. In gatsby@5.16.1 the proxy extension passes from to the default field resolver, which reads getValueAt(source, "fields.extract") off the node object. That lookup reads the raw property, so a resolver you attach to fields.extract has no effect on extract.

I checked this with gatsby 5.16.1 and a Post node using extract: String @proxy(from: "fields.extract"):

• no custom resolvers: both return the stored value
• createResolvers on PostFields.extract: fields.extract is resolved, extract still returns the stored value
• createResolvers on Post.extract: extract is resolved, fields.extract still returns the stored value

That was a synthetic node built with createNodeField, not an Mdx node, but the proxy code has nothing type-specific in it. To get the computed value in both places, have both resolvers call one function. In my test that was a resolver on Post.extract plus one on Post.fields returning { ...source.fields, extract: fn(source) }. If the value can be computed in onCreateNode, storing it with createNodeField also works, since the proxy then has it to read.

[coreylionis]

Thanks for validating Sueun!
It would still be good to know if this is intentional, I could definitely see it being useful for loading multiple resolvers on the same data but I'd probably expect this to work in dependency order, ie resolve the root first and then apply secondary resolvers to proxies. Either way it's a bit subtle.