Data Loading Strategies

[thescientist13]

Type of Change

Feature

Summary

Along with #951 , I would like to review data loading strategies with Greenwood. Also want to revisit the GraphQL plugin now that SSR is in play to see if it makes a difference for prerender configuration, which it depends on.

Details

Take into consideration things like

• For example, having to Prerender data like when sharing templates for SSR - https://www.greenwoodjs.io/docs/configuration/#prerender
• Make graph an actual graph (edges + nodes). What's the best data structure for this? Otherwise should we not call it a graph.json?
• Menus - https://www.greenwoodjs.io/docs/menus/
• Data Sources - https://www.greenwoodjs.io/docs/data/
• rename imports field to resources in frontmatter?
• How to handle data from the client (eg website header + GraphQL - inline ??) vs SSR. Can SSR now just use "real" Apollo client?
• Deprecate Custom Elements flavor of Include Plugin?
• data loaders for SSR pages (e.g. getServerSideProps / getStaticProps) for SSR / SSG pages and APIs, export frontmatter
  • Observed in Feature/issue 1008 adapter plugin API #1122 , we don't currently have a way to pass request data into SSR pages, be it through an adapter or not. This would be required to do things like dynamic / slug routing.
  • Should Greenwood or WCC own getData() function?
• How to vanilla fetch the graph without GraphQL? Come in as compilation props?
• Can metadata about the build be passed into an SSR page, like the URL, so that you can dynamically render out static menus on a per page basis, a la - Feature/issue 81 contact page AnalogStudiosRI/www.tuesdaystunes.tv#107
• Change graph.json from path -> url (instance of URL)
• context plugins as part of SSR
• refactor context, move all things into manifest.json