Self-professed graphql-noob here.
That said, let us suppose the following page-level graphql query in a Mongo/Express/React/Node/Gatsby JS project:
import React from 'react';
import Layout from '../components/Layout';
import { graphql } from 'gatsby';
import { Link } from 'gatsby';
import ItemImg from '../components/ItemImg';
const IndexPage = (props) => {
const arrayItems = props.data.allMongoDBDomainDataArraySource.edges;
return (
<Layout>
<div id="main">
<div className="inner">
<header>
<h1>
Site Title
<br />
</h1>
<p>
Generic site text.
</p>
</header>
<section className="tiles">
{arrayItems.map(item =>
<article>
<span className="image">
<ItemImg></ItemImg>
</span>
<Link to="/Generic">
<h2>{item.node.propertyToBeUsed1 + ': ' + item.node.propertyToBeUsed2}</h2>
<div className="content">
<p>{'Info1: ' + item.node.propertyToBeUsed3}</p>
<p>{'Info2: ' + item.node.propertyToBeUsed4}</p>
</div>
</Link>
</article>,
)}
</section>
</div>
</div>
</Layout>
);
};
export default IndexPage;
export const pageQuery = graphql`
query DomainDataArrayAndSourceFilesystemImage{
allMongoDBDomainDataArraySource{
edges {
node {
uniqueId
imgFilename
metadata
}
}
}
allFile(
filter: {
extension: { regex: "/(jpg)|(png)|(tif)|(tiff)|(webp)|(jpeg)/" }
absolutePath: { regex: "/assets/images/" }
}
) {
edges {
node {
name
ext
childImageSharp {
fluid(maxWidth: 915, quality: 70) {
aspectRatio
...GatsbyImageSharpFluid
}
}
}
}
}
}
`
I'm hoping the above snippet is enough to get someone familiar with the underlying technologies acquainted with the context of how this query is trying to be used (for what it is worth: the above works in graphiql).
Conceptually, I've already successfully mapped the allMongoDBDomainDatayArraySource as a repeating <section> element on my index.js page.
Now, the task is: how to associate the images that have been loaded via the gatsby-source-filesystem resolver with each of the above mapped items in the <section> element as seen in the above code segment (whose each mapped item contains the filename of the image needed which can be obtained from gatsby-source-filesystem).
For clarity, allMongoDBDomainDataArraySource's imgFilename and a concatenation of allFile's edges.node.name and ext (with a '.' in between) would be the equivalent of a SQL JOIN condition that would be analogous to what I am trying to do.
I've experimented with trying to add variable arguments to the page query, but seeing as the multiple sources are combined into one query and are mapped at build time what I really would need is similar to what the JOIN operator would do in SQL.
I've also tried decomposing the <Img> Gatsby element from the index.js page and creating what is either referred to as a template or a component--which is what the ItemImg element is attempting to do.
Unfortunately, the ItemImg approach ultimately fails as page queries are incompatible with non-page components.
The only way I was able to query graphql in this context was with a StaticQuery (which works, but is not dynamic as it utilizes a hardcoded image path).
However, at least my page finally rendered appropriately (albeit, with the same image repeating 831 times).
I did find this graphql feature request regarding the ability to pass variables to StaticQuery.
Apparently, the above feature request was addressed in gatsby-plugin-image beta #27950 although it was a little unclear in the linked to discussion and my attempt at implementing ultimately failed as I ended up with the whole "the graphql query on your component will not be loaded as it attempts to use a non-page component" error again.
My goal there was to eventually pass the filename (which I have in the allMongoDBDomainDataArraySource) as a prop down to the component which would in turn query the image and return the <Img> element.
I know that some of my attempts may not be suitable for the paradigm of graphql, so I was curious if someone could help point me to at least the right concept or approach in solving this.
I've read about schema stitching, using the createPages API (which I think may be overkill for this, as I believe it is possible to combine the query in the way I am trying to achieve), and creating your own schema types (which may be what I need to do).
Let me know what you think I should research and/or implement (i.e. design patterns, etc).