Feat/local image (WIP)

[d4rekanguok]

Close #5

Hi @jperasmus, sorry for hogging this issue for so long! Shortly after our first discussion my deadline & priorities were all changed, so I ended up creating an ad-hoc solution on userland & rolled with it.

Recently @PatrickResponsive contacted me & show interested in working on this issue, so I quickly (& shamelessly) copied my dirty code over & create this PR to have something to discuss. I tried to at least finish the image locator function, so this PR is not so half-baked. I think my solution is not so great though, would love feedback from you guys.

Here's a rundown:

• Instead of downloading the whole media folders, I'm only downloading the image users use. For example, if users defined a 'hero' image field in their schema, only the images for that field of each post will be downloaded.

• I couldn't figure out a smart way to find the image field, so I recursively search each entry for a field of this shape:

  {
  contentType: 'image/****',
  url: 'https://....'
  }

• Then download & cache the image. I'm pretty much lifting the code from gatsby-source-wordpress here, except for one difference:

  • We don't seem to keep different versions of the same image, so I don't check for last modified or created date to invalidate the cache.

• The downloaded image will be given a file node id, thanks to gatsby-source-filesystem. Then, I add this file node id as a localFile___NODE field to the image field (directly mutating it). Gatsby will recognizes the suffix ___NODE & resolve the field localFile to its fileNode in graphql.

Then, users with a media field in their schema can query their images like so:

query Blog {
  flamelinkBlogContent {
    hero {
      localFile {
        name
        childImageSharp {
          id
        }
      }
    }
  }
}

and get this data:

{
  "data": {
    "flamelinkBlogContent": {
      "hero": [
        {
          "localFile": {
            "name": "flamelink%2Fmedia%2F1555643636571_01",
            "childImageSharp": {
              "id": "b6e23db4-b292-50ee-bd8f-8173ba6b4ff5"
            }
          }
        }
      ]
    }
  }
}

Things that I think should be worked on:

• Remove the recursive functions with something smarter, perhaps like looking for images based on the schema?
• Test with more use cases -- I've only test it with a file upload field in Flamelink's schema
• Make it so that the plugin can locate images in post body as well

I set up a Flamelink project to try it out. Perhaps I can share the test site & credential for it in Slack?

I also set up Jest to quickly test the image locator function, but I'm by no mean married to it, we can remove it / set up a different test method / whatever.

Sorry again about the delay!

[d4rekanguok]

@PatrickResponsive also I've just invited you to my fork so you can push stuff here if it makes sense to you!

[PatrickResponsive]

Awesome work thanks @d4rekanguok , Im gonna clone this and try get it working locally, Yeah, Ill try tackle refactoring this recursion function 👍

[jperasmus]

What we could do is use the schemas data and find all fields for each specific schema where the type is media and only use those.

[d4rekanguok]

@jp @PatrickResponsive Extending on JP's comment earlier, I tried to include images in a bunch of different places in a flamelink schema & got these 3 so far:

• a media field (media)
• a repeater field with nested media field (repeater)
• a relational select field (select-relational), that link to another schema with media field

We can check on these 3 types of fields in any schema to see if they includes images & go from there. (I've added a schema data in the test folder in prepare for this.) I think we might run into image duplication problem though. For example, if I already have an image field in tag schema, then have a relational field in blog schema that points to tag, it may download the image in tag again.

[jperasmus]

Hi @d4rekanguok & @PatrickResponsive

Apologies for my radio silence, been a bit busy on other work. Derek, I have not probably said thanks for this PR, so here goes: "thanks 👍". I love that you took this on in your spare time and made this plugin better.

Regarding the conflicting image ID's, what about prepending the schema's key and the specific field's key in front of the image ID, and do this like a breadcrumb as deep into the nested relationships as possible?

[d4rekanguok]

@jperasmus I'm happy to contribute!

The image duplication I mentioned earlier turns out to be a non-issue. Since the flamelink ID for each image is already unique, gatsby already knows enough to store only 1 file per image.

What I was worrying about was that gatsby downloads the same image multiple times on first run, since the download operations happens asynchronously:

But it looks like createRemoteFileNode has already taken care of this. As you can see in the screenshot above, even though cat.png is listed 3 times with 5 other images to the total of 8 images, only 6 images is actually downloaded.

[jperasmus]

ah awesome, that is very interesting. Thanks for the info. I am happy for this to be merged then. We can address any other issues as they come up.

[jperasmus]

This is now available in v1.2.0. Well done @d4rekanguok

[d4rekanguok]

awesome, thank you @jperasmus!