Replies: 2 comments 1 reply
-
Huh I can't believe this is actually a thing. Too bad you didn't get any answers. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I have the same issue. I'm struggling to pass multiple context variables to a template which would make everything so much simpler bit seems like Gatsby can only handle one |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We're struggling with a recurring pattern using Gatsby, and we would like to know how others have get around similar use cases.
Consider an ecommerce product page. In that page, suppose that we have snippets for some "related" products (let's say compatible accessories). Conceptually, what we would like is this:
gatsby-node.js
, a GraphQL query fetches all products, and callcreatePage(sku, ProductPageTemplate)
for each one.ProductPageTemplate
, a page level query fetches details about the product with the given sku, then eventually render componentProductCompatibleAccessories
, providing it the sku of the source product.ProductCompatibleAccessories
, a component level queries an external system to obtain the list of compatible accessories for the source product, then renders componentProductSnipet
for each one, passing in only the sku of each product (that is, no description, no price…).ProductSnippet
, a component level query obtains description, image, price and other informations for the the product specified by input propertysku
.This is just an example of situations we really have. The general approach to this problem in Gatsby is to fetch all data from the page level query, which is much more efficient, at the cost of some extra complexity, since page-level queries must now be aware of all informations required by all components down the way (fragments may help with this…), and these information must passed down to every components along the way (... but you're on your own on this one).
However, in some situations, obtaining these informations from the page level query is simply not possible, or least, not without introducing custom sources, node transformations, or complex schema gymnastic. For example, suppose that product listing and descriptions comes from a general CMS system, product compatibilities comes from some business intelligence software, and prices comes from the ERP. Now we have three distinct systems, each with its own Gatsby source that needs to be queried recursively...
This would be easily implemented if it was possible to have variables in component-level queries, but this is not yet supported, and though this has been discussed previously, I don't have the feeling that adding this feature is actually on the official roadmap.
So… How can these patterns can be resolved using Gatsby's current feature set? Anyone cares to share their experience on how they worked around similar use cases?
Thanks,
James
Context
In case this might be on interest to anyone, here are some contextual details on the project I'm working on.
My team and I are developing an ecommerce website, based on Gatsby. We're talking here of a full-featured ecommerce frontend, comparable to those offered by the Magento platform, WooCommerce, Prestashop and others, though highly customized to our client's specific needs.
At runtime, ecommerce business logic will be backed by a Magento 2 server. However, at SSR time, most content comes from multiple other systems: a CMS, a CRM, some client's internal databases. Actually, only prices are fetched from Magento during SSR build.
The scale for this specific project is a few hundreds of products, with 8 distinctly branded facade, each with three to five locales (that is: language+country/currency pairs). However, we hope that, given some adjustments, this architecture could scale up to a few thousand of products. Content (products, prices, blog articles, documents, and other) changes very slowly; we plan to have the site be automatically rebuilt every night, then pushed to S3 style storage, and served statically by a CDN.
Product inventories, specials and any customer specific information will be fetched dynamically from client's side, using GraphQL based API (mostly based on Magento 2.4's GraphQL API).
Beta Was this translation helpful? Give feedback.
All reactions