[feat]: add ability to pass variables to StaticQuery

[KyleAMathews]

Update

You now can use gatsby-plugin-image that ships with a StaticImage component: https://www.gatsbyjs.com/plugins/gatsby-plugin-image/

---

Original

In order to run queries for Gatsby, we have to know at build-time what the query is and any arguments.

We can do this with page queries as pages can be created with "context" which can be used as arguments for the GraphQL query.

I didn't allow arguments with <StaticQuery> because there wasn't a clear way to allow people to specify build-time arguments that wouldn't confuse people into thinking that arguments would also work at runtime (explaining the distinction between build vs. run time is very hard IME).

There also wasn't need for arguments either as the query is only run once — arguments are of course for when you want to run something multiple times but vary in specified ways how the query runs.

But a recent tweet inspired a thought for how arguments could work: https://twitter.com/wesbos/status/1073338618897448960

The tweet's example was about how to create an image component that queries for image thumbnails for gatsby-image using <StaticQuery>. The idea is that you'd use it by passing a prop in for the image file you want to use e.g. <MyImage src="kyle-mathews.jpg" />.

my-image.jsx might look like:

import React from "react"
import Img from "gatsby-image"
import { StaticQuery } from "gatsby"

export default ({ src }) => {
  <StaticQuery
    query={graphql`
      query HeadingQuery($src: String!) {
         File(relativePath: { eq: $src }) {
           childImageSharp { ...etc }
         }
    `}
    render={data => (
       <Img fixed={data.path.to.query} />
    )}
  />
}

Now this by itself wouldn't work. At build time, we'd have no idea about how or where the component is used and what the arguments are and no way to know when and where to load in the results of the queries (how ever many there'd need to be).

But what could work is that we'd detect that a <StaticQuery> is taking arguments and then scan for every location that component is used. Then we'd rewrite each usage of <MyImage> to import a copy of my-image.jsx that has the arguments inserted e.g. <MyImage src="kyle-mathews.jpg" /> gets turned into <MyImage2344324 src="kyle-mathews.jpg" />

my-image-2344324.jsx looks like:

import React from "react"
import Img from "gatsby-image"
import { StaticQuery } from "gatsby"

export default ({ src }) => {
  <StaticQuery
    query={graphql`
      query HeadingQuery {
         File(relativePath: { eq: "kyle-mathews.jpg" }) {
           childImageSharp { ...etc }
         }
    `}
    render={data => (
       <Img fixed={data.path.to.query} />
    )}
  />
}

The problems with this are we'd still have to enforce that only static values would be supported as args (strings/numbers) and any run-time data would be ignored. Perhaps we could lint for this.

Dynamic runtime lookup of query results might be supportable by creating a lookup table and then running queries for all possible arguments but this obviously could lead to a crap ton of extra queries being run during builds.

We could use this to ship a nice wrapper to gatsby-image e.g. <FixedImage> and <FluidImage> that would work like: <FixedImage src="kyle-mathews.jpg" width={200} height={300} />

[alexluong]

The problems with this are we'd still have to enforce that only static values would be supported as args (strings/numbers) and any run-time data would be ignored

This mean that we cannot pass user input values as arguments for these types of components, right? I feel like it's going to be super confusing for users to be able to use variables but only static values are supported.

Is there any way we can emphasize that "although you can pass a variable, it needs to be predefined"? I'm thinking something along the line of a Gatsby plugin that accept an array of strings. When passing a variable, it needs to be an element in the array.

[ChristopherBiscardi]

This is a similar approach we take to generating wrappers in gatsby-mdx and I think it could be a fantastic approach not just for MDX content, but also potentially as a primitive for theming when the theme's image handling can be shadowed by the user without needing to write additional image queries themselves. Imagine a theme providing using an Image component that renders the result using a file in src/components/blog-post-header-image.js. The rendering logic for the image can be shadowed without the user having to worry about modifying the graphql query from whence it came.

As @alexluong mentions, this could be confusing if you're expecting dynamic values. We could also do something similar to webpack's require.context and if you pass in a glob, we find all of the images that match, get them processed, and you can choose between them at runtime. At which point it's sort of "your responsibility" as the user to make sure you only access images that exist (or fall back if they don't. require.context is reasonable inspiration for providing a json object of potential image values to choose from). In any case, that's "part two" or "sometime later" functionality IMO and we should focus on enabling this for static values to start.

[jgierer12]

I like this, with one suggestion: Let users explicitly pass the variables as an object like so:

<StaticQuery query={graphql`
  query HeadingQuery($src: String!) {
    File(relativePath: { eq: $src }) {
      childImageSharp { ...etc }
    }
  `
  }
  variables={{ src }}
  render={data => (
    <Img fixed={data.path.to.query} />
  )}
/>

That way you could remap variable names or use nested objects.

I first thought that the validation could be made as an eslint plugin, but that wouldn't work as we also need to check that the consumer of the component doesn't change the variable. I believe that would only be possible with something like TypeScript.

Another approach (that would also satisfy my first suggestion) is to require a certain name for the query variable prop, eg:

export default ({ queryVariables: { src } }) => {
  <StaticQuery query={graphql`
    query HeadingQuery($src: String!) {
      File(relativePath: { eq: $src }) {
        childImageSharp { ...etc } }
    `}
    render={data => (
      <Img fixed={data.path.to.query} />
    )}
  />
}

That would be easily checkable for an eslint plugin (simply require that everytime a queryVariables prop is passed, it has to be immutable).

[vermario]

Hello!
Just wanted to point out that this issue really would add a lot of value and would make Gatsby much more useful when (like in our current project) you are trying to give content editors the possibility of creating pages containing custom elements (For example: show here last 5 articles for a particular category etc).

I hope this gives you some feedback in terms of prioritising this feature in your internal development.

[pkarolyi]

I ran into this trying to create a very similar wrapper as the one @KyleAMathews uses in the demo, and would be very happy with this as well.

[nduc]

My use case is when I use gatsby-background-image and I need to load different file for mobile vs desktop. It would be nice to be able to pass in a file name to the static query, as @KyleAMathews mentioned above.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[lxibarra]

Plus one here im trying to optimize image loading bu at the same time dont want to write graphql queries for each image.

[guyinpv]

I have this use-case as well, for dynamically passing in an image name to the component.

I want to use StaticQuery for the obvious benefit of the image sharp stuff, src for different screens etc.

It seems to me that in a certain sense, the variables are already immutable, since those variables would start life as a prop on the component reference somewhere.

So Gatsby needs to be able to quickly connect the StaticQuery variables to the component props, and then find each reference where the props are set.

This definitely becomes difficult if the props are converted to other variable names before used within the query. So the first idea would be to force a direct correlation between the component props, and the variables being used in the query. This, at least, erases some chicken chasing with variable definitions and so on. I don't know how it could be done, given that a prop value might need some kind of mutation before use in the query, and mutation might necessitate using another variable name.
And then again, maybe somehow in code they have to generate a variable not even based on props at all! Like a calculation based on timestamp or random generation or something.

Anyway, if you can lock in the correlation of query variables to props, you then have the issue of finding everywhere the component is referenced. Or specifically everywhere it is referenced with the given props in use, cause that's all that matters really.

All I can suggest here is that Gatsby keep a kind of lookup table/cache that actually tracks all the components and where they are referenced. This data might be heavy to process, I don't know, but that data would also be useful for debugging, as it could then be used to generate an overview of your site with simple stats like "X component is used Y times across Z pages" and be able to list each page and component reference. That is handy data even if a little heavy to process!

Finally, Gatsby would have no choice, because there simply is no other way to do it, to render additional copies of the StaticQuery with each alternate variable used. This is a given, I don't see any other way to get through this part, it simply has to run through the query multiple times with each different variable set used. So temp copies of the query would have to be generated with each variable replacement.

All that said, I understand the normal way to do this would be query all the potential images from the page itself, and pass those into the component where used. The only reason I don't want to do this is that I'm trying to make the component more self-contained and not mess the page component with tons of queries for everything. If the component has everything it needs within itself, it's so much cleaner.

Anyway I hope you get it solved some day!

[mxmkhv]

UPDATE: Another day into this mess I got a way more elegant solution to share.

First off, putting the createPages api into onPreExtractQueries is super fragile and does not really work. Do not try it.

The goal:

1. fetch data from a headless CMS (custom build of my company, returns a plain JSON)
2. use the data to fetch the images (included as URLs in the JSON)
3. create pages dynamically, each page to display it's relevant image with the gatsby-image plugin

The problems:

1. dynamically creating nodes from image URLs
2. creating dynamic queries for each page OR pass image object via pageContext

The solution: to problem 1.

Create the image nodes with the createRemoteFileNode helper function, which I found out about here. Not sure if that is a proper use of it, but it works like a charm. Images are now available for querying.

exports.sourceNodes = async ({ actions, createNodeId, node, store, cache }) => {
  const { createNode } = actions;
  
  const fetchData = () => axios.get(myDataURL)
  const res = await fetchData();
  
  const myData = res.data;  //the JSON data from the CMS response

  const myDataNode = {  
    id: myData.id,
    parent: null,
    internal: {
      type: myData,
      contentDigest: crypto.createHash(`md5`).update(JSON.stringify(myData.id)).digest(`hex`),
    },
    children: [], 
    data: myData,   //insert my data
  }

  createNode(myDataNode); // create the node

  const allPosts = myData.posts //get all posts data

  const createImageNodes = async (allPosts ) => {     //create the nodes with an async function
    for (const post of allPosts) {
      await createRemoteFileNode({    //AWAIT creation of nodes!!
        url: post.image,
        store,
        cache,
        createNode,
        createNodeId: id => post.id, //id wanted a function, so I provided one :) 
        name: post.id,   // IMPORTANT - name each image as the post ID to match them later
      })  
  }

  await createImageNodes(allPosts)    //AWAIT the download of the images!!! 
  return
}

IMPORTANT: If I do not await the creation of nodes, the bootstrapping process does not wait for the images to be downloaded, so nodes are not available in createPages query!

In addition:
For the gatsby-image plugin to work, the gatsby-source-filesystem plugin has to have access to the /images folder (although my images are fetched and not stored locally), so the following config was required in gatsby-config.js

    `gatsby-transformer-sharp`,
    `gatsby-plugin-sharp`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`, //this is required for the gatsby-image plugin to work
      },
    },

So, now I have the images in my graphQL schema, but in order to render an image in my dynamically created pages, I have to query for all images and filter out the one I need, similar to what was discussed in the Wes Bos twitter post.

The solution works, but it's not really scalable, so the one true solution for me was to pass the "fixed" or the "fluid" object (returned by a graphQL query for an image), as context to the dynamically created pages, using the createPages API.

The solution: to problem 2.

Awaiting creation of nodes in sourceNodes, makes createPages trigger only after the images are fetched and nodes are created. Otherwise the image nodes are not available at build time, because they are not yet downloaded.

  exports.createPages = ({ graphql, actions }) => {
    const { createPage } = actions
    
    //make one query to fetch myData and one to fetch all images 
    return graphql(`
      {
        myData {
          ...allData
        },
        allImageSharp {  //access all images
          edges {
            node {
              id
              fluid {  // fragments did not work here, I don't know why
                ...GatsbyImageSharpFluid
              }
            }
          }
        }
      }
    `
  ).then(result => {
      const allPosts = result.myData.posts //get all posts
      const imgData = result.data.allImageSharp.edges //the array of all image nodes
      
      const fluidImageObjects = [] //create an empty array

      imgData.forEach((image) => { //push all the fluid objects to the empty array
        fluidImageObjects.push(image.node.fluid)
      })
      
      allPosts.forEach((post) => {  //iterate over each post object and create a page

        //match the relevant fluid image object, this is for jpg only, but you can slice('/').pop() the url and get the image name also
        const imageFluid= fluidImageObjects.find(image => image.originalName === `${post.id}.jpg`)
        
       createPage({
          path: `/pages/${post.title}`,
          component: path.resolve(`./src/templates/PostTemplate.js`),
          context: { 
            data: post, 
            image: imageFluid   //pass the fluid object as context
          }
        })
      })
    })
  }

Then simply add this to any page, created by createPages

<Img fluid={pageContext.imageFluid}/>

And you get the post image.

@KyleAMathews, what do you think about this approach? It there a better way to accomplish this?

[baba43]

It's really sad that optimizing images using Gatsby results in so much overhead and unreadable/unreusable code. We've been so happy after being able to simply import images from everywhere with Webpack and other bundlers and now we're stuck with a solution that is so much worse when building static pages.

While I totally understand that Gatsby has a specific way to handle data and stuff, we should not accept that the most basic things have to be done so complicated.

[KyleAMathews]

@baba43 — no one is accepting anything :-P that's why this issue exists.

We'd appreciate your help fixing it. Gatsby is a community built project so needs strong developers like yourself to help improve things.

[guyinpv]

It occurs to me that perhaps instead of having to duplicate and generate new queries for every possible variable used within , you could assemble all the possible variables into a list in the query itself. Kind of like WHERE something IN [array,of,all,vars,found]

Then the compiler just has to recognize the query as a set, and loop over it to generate each copy of the component. It only has to somehow know which component render belongs to which index of the returned set!

Just spitballing on that little idea.

[hiddentao]

For dynamically querying images, I'm currently simply fetching all nodes and then filtering within the results:

import safeGet from 'lodash.get'
import React, { useMemo } from "react"
import { graphql, useStaticQuery } from "gatsby"
import Img from "gatsby-image"

const Image = ({ src, ...props }) => {
  const data = useStaticQuery(graphql`
    query {
      allFile( filter: { internal: { mediaType: { regex: "/image/" } } } ) {
        nodes {
          relativePath
          childImageSharp {
            fluid(maxWidth: 300) {
              ...GatsbyImageSharpFluid_noBase64
            }
          }
        }
      }
    }
  `)

  const match = useMemo(() => (
    data.allFile.nodes.find(({ relativePath }) => src === relativePath)
  ), [ data, src ])

  const fluid = safeGet(match, 'childImageSharp.fluid')

  return fluid ? (
    <Img
      fluid={fluid}
      Tag='div'
      {...props}
    />
  ) : null
}

export default Image

[nextlevelshit]

Regarding the solution of @hiddentao I had to transform it to fit into my setup. I was to lazy to investigate what's exactly the point; might be the environment, versions etc. But heres an apadapted solution. Thanks for your input @hiddentao:

import React, { useMemo } from 'react'
import { graphql, useStaticQuery } from 'gatsby'
import Img from 'gatsby-image'

const Image = ({ src, ...props }) => {
  const data = useStaticQuery(graphql`
    query {
      allFile( filter: { internal: { mediaType: { regex: "images/" } } } ) {
        edges {
          node {
            relativePath
            childImageSharp {
              fluid(maxWidth: 300) {
                ...GatsbyImageSharpFluid
              }
            }
          }
        }
      }
    }
  `)

  const match = useMemo(() => (
    data.allFile.edges.find(({ node }) => src === node.relativePath)
  ), [ data, src ])

  return (
    <Img
      fluid={match.node.childImageSharp.fluid}
      {...props}
    />
  )
}

export default Image

[jnsrikanth]

hi ,
is this feature available yet? why is this still open?

[sidharthachatterjee]

We had an internal discussion around the useQuery prototype and this experiment brought to light reasons that led us to deciding not ship this in Gatsby

• Losing the ability to statically compile GraphQL queries (which we can do now)
• Negative implications on build times and query result invalidation
• An increase in overall complexity including a new mental model of what factors into query results as a result of allowing “runtime” variables at build time (and the ensuing confusion over what their values should be on the client side after hydration)

This issue is still open because we’re exploring alternative approaches to building an Img component that takes a url! Thank you for your positive comments, folks 🙂

[tony]

@sidharthachatterjee Thank you for giving this the attention! I wanted to comment and say thank you for being so courteous and conscientious in this thread!

If you have more details on the internal discussion and can expand upon it, that may be worth citing. If there was a blog post exploring the pros / cons / complexities of this.

This issue is still open because we’re exploring alternative approaches to building an Img component that takes a url! Thank you for your positive comments, folks 🙂

Looking forward to this! I made good timing as this was exactly what I was looking into :)

[Vacilando]

If there is a preference not to ship this with core, could it be packaged as a Gatsby plugin. Its usage will prove or disprove how much this functionality is needed, and people will undoubtedly contribute further improvements.

[jdahdah]

Please consider that this functionality is not only needed for an <Img /> component that takes a URL. Another example would be any reusable component that consumes multilingual content. Example: a dictionary of words used across the website, coming from Contentful, accessed through a generic <Snippet /> component. I'm currently using the same hack suggested for <Img />. There are many other examples scattered throughout my current projects. In general anything that requires I18n is leading to a lot of strange workarounds due to the lack of variables in non-page queries.

[Js-Brecht]

@sidharthachatterjee Out of curiosity: are you able to comment about whether this will be reevaluated when React's Suspense is stable, and SSR compatible?

[danilobuerger]

Maybe we could activate experimentalFragmentVariables in graphql to be able to use parameterized fragments at build time. That would at least lessen some of the pain in i18n.

[herecydev]

Similar views to @jdahdah the following seems quite common from my experiences but is currently impossible:

  const { labels } = useStaticQuery(graphql`
    {
      labels(locale: {eq: "<mylocalevariable>"}) {
        heading
        buttonText
      }
    }
  `);

The only working solution I have at the moment is to query all labels as a page query and prop drill them (or use context). It massively erodes the value of colocated static queries.

[danilobuerger]

@herecydev If your locale is known to the page (i.e. in the page context) you could use fragments instead. Fragments can access the arguments of the query they are in. Obviously not a pretty solution.

[LpmRaven]

@hiddentao @nextlevelshit An alternate for when trying to build a dynamic images component is to attach the imageFile to the object on the data level, rather than when trying to render. Doing the match in the image component starts to throw errors when working on a project with a lot of images.

src/gatsby-api/create-resolvers/index.js

const resolvers = {
    AWSAppSync_Product: {
        imageFile: {
            type: 'File',
            resolve: async (source, args, context, info) => {
                const node = await context.nodeModel.runQuery({
                    query: {
                        filter: {
                            Key: { eq: source.image1 }
                        }
                    },
                    type: 'S3Object',
                    firstOnly: true
                });

                if (node && node.imageFile) return node.imageFile;
            }
        },
    },
}

module.exports = {
    resolvers
}

gatsby-node.js

exports.createResolvers = async ({ createResolvers }) => {
    createResolvers(resolvers)
}

src/components/image/index.js

import React from 'react'
import Img from 'gatsby-image'

export const Image = props => {
  if (props.imageFile && props.imageFile.childImageSharp && props.imageFile.childImageSharp.fluid) {
    return <Img className={props.imgClassName} alt={props.alt} fluid={props.imageFile.childImageSharp.fluid} />;
  }
};

Then use it like:

<Image
  imageFile={product.imageFile}
  alt=""
/>

AWSAppSync_Product is the type of node I am attaching my File to. (which can be found in the graphql playground on localhost). The resolve will match the Key of the S3Object with image1 (which is a string) on the product. This allows me to directly use the product images without having to run a query inside the image component.

[mjameswh]

Similar issue here, though I tend to see it the other way around…

Our case is an ecommerce website, where product pages includes snippets for some related products (let's say recommandations…) Conceptually, what we would like to have is this:

• In gatsby-node.js, a GraphQL query fetches all products, and call createPage(sku, ProductPageTemplate) for each one.
• In ProductPageTemplate, a page level query fetches details about the product with the given sku, then renders component ProductRecommandations, providing it the sku of the source product.
• In ProductRecommandations, a component level query obtains the list of recommandations for the product with the given sku, then renders component ProductSnipet for each one, passing in only the sku of each product (that is, no description, no price…).
• In ProductSnippet, a component level query obtains description, image, price and other informations for the the product specified by input property sku.

This is just an example of situations we really have. The general approach to this problem in Gatsby is to fetch all data in 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.

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 recommendations 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 queries recursively... So simple conceptually, but right now, you must be a Gatsby power user to implements this...

Now, this might seems naive, but wouldn't it be possible for Gatsby to 1) run these component-level queries during SSR/build, then 2) append the result of that query inside the page-data of the page currently being rendered, and 3) finally, replace that query level component by an access to the corresponding result in the current page-data?

Note that this does not adds up to full dynamic component-level queries (which, anyway, requires either server-side support or that full data be available client-side, which is not scalable). Still, it seems to me that it would provide build-time resolution of component-level queries based on contextual variables.

Here's how I imagine this, based on my limited knowledge of Gatsby's internal.

• First, PageQueryStore becomes a context provider, making it possible to pull current page's page-data from leaf components without having to pass data over all along the way. Nothing impressive here, but required before for following steps, and arguably useful by itself.

• Then, during SSR builds, component level queries with variables are executed (ideally in an async way, though I see that this most likely complicates things...), after which the query/variables pair and its corresponding result are inserted into a structure in PageQueryStore that stores additions to the current page's page-data.

• At the end of the SSR build (or maybe after completing each page), additions to page-data (stored in PageQueryStore) are merged with the original page-data file for that page. Queries are replaced by some hash equivalent (ie. MD5 or SHA1).

• During production builds, component level queries with variables are replaced by calling a function on the PageQueryStore context, reading from current page's page-data for the corresponding query/variables pair.

• As for the question of identifying data dependencies (for efficient data rebuild)... Execution of component level queries with variables would fetch the internal redux node store, similar to how other queries are executed, thus marking dependencies on these nodes from the page being rendered.

Note that eventually, the community could take advantage of both the fact that PageQueryStore is a context and from the fact that page-data can be extended at SSR time...

As I said before, this is probably naive and I certainly miss a lot of details required to make it real, but it seems to me that it is possible to make progress in that direction, and that it would be highly benefical for lots of Gatsby users.

[LpmRaven]

• In gatsby-node.js, a GraphQL query fetches all products, and call createPage(sku, ProductPageTemplate) for each one.
• In ProductPageTemplate, a page level query fetches details about the product with the given sku, then renders component ProductRecommandations, providing it the sku of the source product.
• In ProductRecommandations, a component level query obtains the list of recommandations for the product with the given sku, then renders component ProductSnipet for each one, passing in only the sku of each product (that is, no description, no price…).
• In ProductSnippet, a component level query obtains description, image, price and other informations for the the product specified by input property sku.

@mjameswh I just built this over the past 6 months. After trying a few different ways, there are a lot of implementation differences due to some issues with performance, build time and preventing throttling of my APIs. We can make a new discussion if you want to go in-depth, as I don't believe it is relevant enough to hijack this thread.

[ascorbic]

The trouble with this approach is that it can't handle components that aren't rendered at build time, or where the props have changed. This is why I rejected it for the new StaticImage, and had to require that the props can be statically-analysed.

[LpmRaven]

@ascorbic I'm sorry but I disagree, It is possible to do. You handle it in the data layer with custom resolvers as I described above.

[mjameswh]

@LpmRaven Yes, I would be very interested to know more on how others have dealt with similar use cases, given Gatsby's current feature set. I feel that there is work that could be done to improve Gatsby in this regard, and I might consider working on this later on, but for now, I must focus on my current project.

I started a distinct discussion here for sharing experience on how to get around this type of use cases, at present. It would be great if you could explain how you did it and what didn't worked. You said that you tried different ways, and faced practical issues. That would certainly be of interest to others considering using Gatsby in larger projects.

[mjameswh]

The trouble with this approach is that it can't handle components that aren't rendered at build time, or where the props have changed.

@ascorbic I understand that this might not be a viable approach in all cases. But for my part, this is indeed what I need… and this seems to me like a very common use case. Given my previous example, the ProductSnippet that are displayed on a page is determined at build time, through rendering the cascade of components, starting with data obtained from the Gatsby source. All of this is static once it has been rendered by the server.

It is obvious that if I would need to display ProductSnippet for a sku that can be dynamically changed on client side, then I would also need that component to have a way to fetch details dynamically, from the client side (for example, using Apollo Client). But then, that is plain React and has nothing to do with Gatsby.

[ascorbic]

The images use case for this is now mostly solved by the new StaticImage component. Take a look at the RFC and give it a try: #27950

[dustinlacewell]

What about every other use case?

[ardiewen]

Similar issue here, though I tend to see it the other way around…

Our case is an ecommerce website, where product pages includes snippets for some related products (let's say recommandations…) Conceptually, what we would like to have is this:

Hi all, wanted to contribute another use case that was similar to what @mjameswh discussed, but only using one data source / cms:

Performing build time queries based on cms / user provided inputs.

Examples:

1. CMS has an Image field group that allows users to upload an image file, but also has an additional toggle for transformation options such as crop focus, duotone filters, etc.

2. CMS has a LatestPosts field group that allows users to display a list of latest posts via a static query on any page, but also has an additional select field for Categories (e.g. latest posts from the "News" category).

The additional options on both of these use cases doesn't fit nicely into the existing build-time data fetching methodology, since data at build time is only ever fetched once.

For this to work, we'd need to be able to run an initial query (e.g. existing page queries and fragments), then be able to trigger a second round of queries (possibly static queries at the component level?) based on the initial data that we receive back.

The key here, at least to me, is to be able to do all of this within the build step in order to preserve performance benefits.

[kevinsullivan]

My working conclusion is that what we want is inconsistent with foundational architectural decisions made in the design of Gatsby. I certainly don't plan to spend any more time pursuing it. --Kevin

…

On Fri, May 27, 2022 at 8:51 PM John Dunning ***@***.***> wrote: Alas, I am now among the broken-hearted. 2.5 years later, me, too. Hard to believe there isn't a solution for this yet, as I've run smack into it without doing anything complicated. I'm just trying to pull some static text from a headless CMS at build time, and wanted to create a simple parameterized component to avoid copying and pasting the same code over and over. It really feels like I'm either completely misunderstanding how to use Gatsby, or its popularity is massively unfounded. — Reply to this email directly, view it on GitHub <#10482 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVEX5MJM7ME7LMEJM3FZX3VMFUY5ANCNFSM4TP73BVQ> . You are receiving this because you commented.Message ID: ***@***.***>

[itsalysialynn]

For anyone looking for an implementation with gatsby-plugin-image:

import { graphql, useStaticQuery } from 'gatsby';
import { GatsbyImage } from 'gatsby-plugin-image';
import { useMemo } from 'react';
import React from 'react';

const Image = ({ alt, src }: ImageProps) => {
  const data = useStaticQuery(graphql`
    query getAllImages {
      allFile(filter: { internal: { mediaType: { regex: "/image/" } } }) {
        nodes {
          relativePath
          childImageSharp {
            gatsbyImageData
          }
        }
      }
    }
  `);

  const matchedImage = useMemo(
    () => data.allFile.nodes.find(({ relativePath }) => src === relativePath),
    [data, src],
  );

  const image = matchedImage?.childImageSharp?.gatsbyImageData;

  return !!image ? <GatsbyImage alt={alt} image={image} /> : null;
};

export default Image;