Get Page --> Nodes Dependency

[tusharf5]

Summary

Is there a way to access page ---> node dependency in the node api file? Based on what I read in the documentation gatsby does track a dependency similar to that internally to know when to rebuild pages i.e when there is a change in the nodes used by a page only then rebuild that page.

Can we get access to that information as a plugin developer?

We are working on a plugin that will use that information (what nodes/data is being used by a page).

Thank you.

[pieh]

We don't have public APIs for this right now, because for the most part this is considered implementation detail to enable query result caching for now. Can you describe what kind of plugin are you working on? It might warrant public adding some public APIs

[tusharf5]

Thank you for the response.

Can you describe what kind of plugin are you working on?

We are planning to work a plugin which would take in page data dependencies (for eg. if it is a blog post page, our plugin would access the blog post's content, category, tags, etc) for ever page of our website and send it to our backend. The backend will analyze the data (for eg. it would run it against our AI models) and send back some insights which would then be made available to the pages. Let me know if you need more information.

We don't have public APIs for this right now.

If there's not a public API, is there a way we could access it using some internal APIs for eg. if we get access to the store? The problem that I am facing while exploring this is that the page dependencies are computed at the end of the build lifecycle so I can't seem to find a way to access those dependencies in the early lifecycle methods. Is there something we could do to access it in early stages?

[pieh]

If there's not a public API, is there a way we could access it using some internal APIs for eg. if we get access to the store?

You can. store is actually passed to gatsby-node API hooks which was done in early days as escape hatch for lack of APIs, but this historically prove to cause a lot of problems, because things were often breaking due to internal changes so we strongly discourage use of it because it's quite brittle (this is most important for plugins that would get published on npm and users of those would then have troubles - if this would be for internal use, then this would probably be fine). Here's example of getting access to store instance -

gatsby/packages/gatsby-source-contentful/src/gatsby-node.js

Lines 37 to 50 in d8ed76c

	exports.sourceNodes = async (
	{
	actions,
	getNode,
	getNodes,
	getNodesByType,
	createNodeId,
	store,
	cache,
	getCache,
	reporter,
	},
	pluginOptions
	) => {

The problem that I am facing while exploring this is that the page dependencies are computed at the end of the build lifecycle so I can't seem to find a way to access those dependencies in the early lifecycle methods. Is there something we could do to access it in early stages?

The data dependencies are populated as queries get executed (because it gets list of all linked nodes which are not known ahead of time, it's not just query "entry points" that with some effort could be figured out). The earliest you can make use of it is after query running step currently, which might be already too late for your use case (depending on how would you like to make those insights available to the page)

[tusharf5]

That makes sense. Although it's an internal project we still wouldn't want it to be that brittle so I agree with you that accessing the store approach wouldn't be a good choice. Is there any way we could know early on what Node is creating a page?

For eg. in a blog, we would have multiple blog posts pages sourced from Markdown files. Let's say we are not interested in specific field values excerpt, tags, category and we just want to know that this page with an id is created by this Node from this plugin. That means we wouldn't need Query dependencies of a page. All we would want to know would be Page --> Node (Source or Transform) relation.

Is that possible?

The earliest you can make use of it is after query running step currently.

I tried a bunch of lifecycle methods to check for the pageData property of store but it always was showing it as empty {}.