Access the root element's context in gatsby-node.js

[yidongw]

I'm using mobx-state-tree for storing data, and it contains some product data that doesn't change very often, so I want to get those data ready in the build time.

I implemented wrapRootElement in gatsby-ssr.js and gatsby-browser.js. wrapRootElement is the same function that creates a store and wrapping the element with context provider

import { MainContext, MainModel } from "../stores/MainStore"

export default ({ element }) => {
  const store = MainModel.createStore({})
  return <MainContext.Provider value={store}>{element}</MainContext.Provider>
}

I also need to createPage in gatsby-node.js according to using-gatsby-without-graphql, but all the data fetching is currently done in the store, so in order to fetch the data, I need to somehow access the store that was created in the gatsby-ssr.js or gatsby-browser.js.

How am I supposed to do that? Or I should use a different approach?

[Js-Brecht]

@yidongw let me see if I am understanding correctly:

You have data fetching logic defined in your store, and you want to prefetch that data during build time so that it is available during runtime (without the FE needing to refetch it); and you want to do this without duplicating the data fetching logic in order to use it from node.

First of all, you cannot access a store instance that you've created in gatsby-ssr/gatsby-browser from within gatsby-node. They're running in different contexts / environments.

You can, however, use the same store logic in gatsby-node that you would use in runtime if you're okay with using something like the esm library. You just need make sure your store code doesn't use any special syntax (like jsx) or anything that has to be used in the browser; also need to make sure your store modules don't import any other modules that do this either. Another way is to use something like babel-register or ts-node (if you're using typescript) for transpiling modules during import, so that the code can be converted into something usable by node prior to being consumed. My plugin gatsby-plugin-ts-config does this (and your code doesn't need to be written in Typescript when using it, either).

By doing this, you can create a store instance in node and run the data fetching api. You will then be creating a new store instance inside of gatsby-ssr/gatsby-browser and using the data you fetched in gatsby-node to hydrate the new store instance. There's a few different ways to get make this data available.

You could:

• Use createPage to add the collected data to page context

  • Downside to this is if this data is used globally, you will wind up attaching it to the context of every single page so that it is available no matter which page the user lands on. This means that it will be included in every single page-data chunk, and will cause it to be redownloaded on every page change.

• Push your collected data into the GraphQL layer using sourceNodes.

  • Downside is that you now need to explicitly define the shape of your data in a GraphQL query in your react tree, much like the example in How to initialize redux store with data from Gatsby page query? #23239.
  • I'm assuming you don't want to do it this way because you've mentioned doing it without GraphQL.

• Store the data in a json file somewhere, and define that path in a webpack alias so that you can use something like this inside of gatsby-ssr & gatsby-browser:

  const data = require("__some_webpack_alias__");
  
  // With a webpack alias, you can even do a ES6 import:
  import data from "__some_webpack_alias__";

  • This will bundle the data into your javascript, which will make your initial download larger... but you will need to download the data during hydration anyway, even with the GraphQL method 🤷‍♂️

• You could even store the data in a json format inside of the html of each page (inside of a <script type="application/json> tag)

  • This increases the size of your client's initial html download, but it is only going to be done once.
  • This may also affect other metrics, like TTFP

Probably one of the best ways is to push the data into the GraphQL layer because using a static query means your data will be available during SSR and it will also be split into its own data chunk for consumption in the browser, reducing your initial bundle size. This can lead to more maintenance though due to the nature of GraphQL, so I understand if you want to avoid it.

IIRC, there's a way to do the webpack alias method that will let you load a json chunk synchronously during SSR but also load it in its own chunk (asynchronously) during runtime, much like the static query process does. It's been a while since I've tried to do that though, so I'd have to try to put together a POC to even remember how.

If any of these methods sounds appealing or if I've misunderstood what you're trying to accomplish, let me know. If you want to move forward with one of these, maybe you can share your project and we can make it work.

[Js-Brecht]

The following error will show up when I delete my .cache folder, and then do gatsby develop or gatsby build

That's because you've defined your own .babelrc. It generally works better if you use the onCreateBabelConfig api. More specifically (and in your case), the setBabelPlugin action inside of that api

cache doesn't have directory, so I'm using path.resolve(__dirname, "../.cache/data.json") instead

Where are you using cache from? It should definitely have .directory. I know it always has when I wanted to use it, including now (Gatsby v3.1.3)

I do stuff kind of like this to inspect the api sometimes. I don't actually use the debugger symbol, but it conveys the meaning pretty well. If you use a debug console and run gatsby build from it, it should break inside of sourceNodes and you can view parameters the api is provided.

exports.sourceNodes = async ({ cache }) => {
    console.log(cache.directory);
    debugger;
};

[Js-Brecht]

Btw, there's gatsby-plugin-styled-components if you wanted to use styled-components. It does a little extra work for you, too

[yidongw]

cache's type is defined in https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/index.d.ts but it doesn't have directory. I looked it up and did see directory inside the cache. Maybe the type is wrong?

export interface GatsbyCache {
  /**
   * Retrieve cached value
   * @param key Cache key
   * @returns Promise resolving to cached value
   * @example
   * const value = await cache.get(`unique-key`)
   */
  get(key: string): Promise<any>

  /**
   * Cache value
   * @param key Cache key
   * @param value Value to be cached
   * @returns Promise resolving to cached value
   * @example
   * await cache.set(`unique-key`, value)
   */
  set(key: string, value: any): Promise<any>
}

Babel error is now fixed. Thank you!

[Js-Brecht]

gatsby/packages/gatsby/index.d.ts

Lines 1261 to 1282 in 060f732

	export interface GatsbyCache {
	name: string
	directory: string
	/**
	* Retrieve cached value
	* @param key Cache key
	* @returns Promise resolving to cached value
	* @example
	* const value = await cache.get(`unique-key`)
	*/
	get(key: string): Promise<any>
	/**
	* Cache value
	* @param key Cache key
	* @param value Value to be cached
	* @returns Promise resolving to cached value
	* @example
	* await cache.set(`unique-key`, value)
	*/
	set(key: string, value: any): Promise<any>
	}

[yidongw]

oh. I need to update my gatsby then. Thanks