@parataxic/gatsby-lazy-pagedata

What does it do

Allows lazy loading data in gatsby for client-side component loading

How?

In gatsby-node.js, during createPages, a you slip in a createJSON (included) before createPage, this will register the same path as the page, but prepended with .json, and include all the context data for the component.

e.g.

const pageData = {
  // @ts-ignore: Not sure waht this is
  path: `/who/${psychologist.id}`,
  // This component will wrap our MDX content
  component: `path/to/your/template.tsx`,
  // We can use the values in this context in
  // our page layout component
  context: { mdx, psychologist },
};

await createJSON(pageData); // data for your component (you can customize and tweak this if needed)
return createPage(pageData);

Usage case

You can use the created /normal/page.json file (assuming a page at /normal/page) however you'd like.

In my use case, it's used to fetch popover information based on other objects in the gatsby store.

Pros / Cons

Pros:

• Works with SSR

  Lets you have all the benefits of client side loading / lazy components

• Keeps pages lite and simpler

  No need to pull asset information for popups / popover / hover content or other stuff in your initial request.

• Creates a new JSON file with every page The json for the file can be customized to include:

  • Less data: Only pass the amount of data your components need to preview / do whatever it needs to do when working with createJSON. Don't want to include all the mdx stuff? Don't pass it.

  • Pass additional data: Add additional contextual information not necessary to include in your createPage

Cons

• Creates a redundant file. page-data.json has the data also. Future versions may give the option to fetch from page-data.json since those are often pre-cached.
• Not using page-data.json eliminates possibility of a lazy-loaded component also being able to preload the target page

Other methods

Utilize page-data.json. Future versions may try this.

This would prevent duplication, but the results for this wouldn't be adjustable.

Also, the location of page-data.json is consistent enough to pull via fetch without additional specialized logic.