images not rendering until browser page refresh

[i001962]

When public folder is put into ipfs the images don't render on the first page load. Seems that they only appear after a browser/page refresh.

Here's a screencast of the behavior. Not sure how to better describe this behavior. Does this happen to you @satazor? Not sure if this is a local to my ipfs node or not. I haven't yet found a pinner that I can test this on.

https://screencast.com/t/Xhw7MZxsJ . <-- requires flash, I know. I know. Sorry

[satazor]

I’m on my phone so I can’t see the screencast now. I will check it out tomorrow but feel free to keep pinging me if I don’t answer.

[i001962]

This is the site with public pushed to netlify - working as expected
https://nostalgic-ardinghelli-37acd1.netlify.com/

This is the site with public uploaded to pinata (as of today they support folders) - images not loading without a browser refresh and at that the home page isn't getting past the blur effect

https://gateway.pinata.cloud/ipfs/QmTHu1eMe9shezggrdS8oqbSppYWfQ8jfSpVGzpkHk2Ktj/

Here's a fork of the starter that include the ipfs plugin
https://github.com/i001962/gatsby-starter-hero-blog

[yvt]

It seems that the problem lies in the handling of page data JSON files. Here's an excerpt from the top page's page data:

https://gateway.pinata.cloud/ipfs/QmTHu1eMe9shezggrdS8oqbSppYWfQ8jfSpVGzpkHk2Ktj/static/d/406/path---index-6a9-y77xJN2OfHJ2Ap8EhHf4n8vT9i8.json

"cover": {
    "children": [
        {
            "__typename": "ImageSharp",
            "fluid": {
                /* ... */
                "src": "../../../static/40d4f4de1973c24726e4ef65ef5fd03e/97e83/photo-1507915600431-5292809c5ab7.jpg",
                /* ... */
            }
        }
    ]
}

The value of src was presumably relativized with reference to this JSON file's URL. Web browsers resolve relative paths based on the current page's URL, so this resolves to an incorrect location.

However, afaik it's not trivial to guess the base URL for each page data file. To make matters worse, there might not be a single consistent URL. For example, if a user is navigating between pages quickly, relative URLs could be resolved with an incorrect base URL unless the updates of the current URL are perfectly synchronized with the initiation of requests for page assets.

A possible solution is to not patch the page data during build, but instead to patch it on a client-side where the actual value of __GATSBY_IPFS_PATH_PREFIX__ is known. Intercepting the loading process of page data is the tricky part. GatsbyJS doesn't provide an API hook for doing that, so you'd have to provide a custom version of loader.js to do that. If you don't mind dirty hacks, you could replace the global XMLHttpRequest object to intercept HTTP requests. Or, assuming the site developers have a full control of page components (i.e., none of them come from external packages), you could ask them to patch data in page components like this:

// hypothetical utility function
import {resolveUrls} from 'gatsby-plugin-ipfs'

export default function Template({ data }) {
  const dataPatched = React.useMemo(() => resolveUrls(data), [data]);
  /* ... */
}

[kevin-chau]

I'm also having this issue! I was so close to getting my gatsby blog working with IPFS