@parataxic/gatsby-lazy-pagedata
v0.4.0-alpha.47
Published
Fetch gatsby page data asynchrononously via URL from clientside
Downloads
67
Readme
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 themdx
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.