docs(node-tracking): Updates source file links. #21657
Conversation
benrobertsonio
added
the
type: documentation
|
|
||
| Now, where do we use this information? In 2 places. | ||
|
|
||
| 1. In the `File` type resolver. It is used to lookup the node's root, which should be of type `File`. We can then use that root node's base directory attribute to create the full path of the resolved field's value, and therefore find the actual `File` node that the string value is describing. See [File GqlType inference](/docs/schema-gql-type/#file-types) for more info. | ||
| 1. To recursively look up node descriptions in [type-conflict-reporter.js](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/type-conflict-reporter.js) | ||
| 1. To recursively look up node descriptions in [type-conflict-reporter.js](https://github.com/gatsbyjs/gatsby/blob/80acb8d5d67f7e277ce44158b36da84d262e5b23/packages/gatsby/src/schema/infer/type-conflict-reporter.js) |
There was a problem hiding this comment.
This is no longer true -
gatsby/packages/gatsby/src/schema/infer/type-conflict-reporter.js
Lines 22 to 31 in 6979816
With some refactoring we had to remove usage of it there and it wasn't straight forward on how to put it back and value of using it there was questionable so we didn't spend time on trying to bring it back (so right now there is rough TODO to bring it back, but no plans to prioritize bringing it back)
So this item seems like would need to be removed (and then Line 58 also would need adjustment as we wouldn't have "2 places" anymore)
|
|
||
| In the above example, `nodeA` has parent `id1`. So `findRootNodeAncestor({ blog: "blog/my-blog.md", b: 2 })` would return the node for `id1` (the parent). | ||
|
|
||
| ## Why/Where? | ||
|
|
||
| Where is node-tracking used? First up, nodes are tracked in 2 places. Firstly, in [createNode](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/redux/actions.js#L539), every time a node is created, we link all its sub objects to the new NodeID. Nodes are also tracked whenever they are resolved in [run-sift](/docs/schema-sift/#3-resolve-inner-query-fields-on-all-nodes). This is necessary because [custom plugin fields](/docs/schema-input-gql/#inferring-input-filters-from-plugin-fields/) might return new objects that weren't created when the node was initially made. | ||
| Where is node-tracking used? First up, nodes are tracked in 2 places. Firstly, in [createNode](https://github.com/gatsbyjs/gatsby/blob/80acb8d5d67f7e277ce44158b36da84d262e5b23/packages/gatsby/src/redux/actions/public.js#L666-L858), every time a node is created, we link all its sub objects to the new NodeID. Nodes are also tracked whenever they are resolved in [run-sift](/docs/schema-sift/#3-resolve-inner-query-fields-on-all-nodes). This is necessary because [custom plugin fields](/docs/schema-input-gql/#inferring-input-filters-from-plugin-fields/) might return new objects that weren't created when the node was initially made. |
There was a problem hiding this comment.
We no longer track nodes in createNode (AFAIK). There was some major refactor done in #16091 , but I do lack a bit of context on how to explain the difference properly. I'll try either way:
The linked PR (materialization) creates a nodes "view" that include "computed values" (fields in graphql schema that are created via resolvers as opposed to from direct values being available on node objects) and we call trackInlineObjectsInRootNode on those "virtual nodes" instead of on "nodes" that user/plugins create via createNode call. @freiksenet might have nicer explanation than me tho for this ;)
Co-Authored-By: Michal Piechowiak <[email protected]>
|
Going to close this for now since realistically this page needs more attention than fixing the links. Am I correct @pieh that this requires input from the core team rather than a community member? |
Description
Updates outdated links to source files in the /docs/node-tracking/ article.
Related Issues
Mentioned in #14288