Fixing missing thumbnails

[ajolipa]

In this PR

Adds an optional thumbnails prop, which when set to false will instruct the viewer not to create a custom thumbnail image but rather to just get the full image and resize it in the viewer. This is useful in cases where the available sizes on the IIIF images are limited to a small set of options, which will lead to 404 errors when attempting to fetch thumbnail images at specific sizes.

For example, the Interviste Pescatori Storybook story now looks like this:

export const IntervistePescatori = () => (
  <EditionCrafter
    threePanel
    documentName='Interviste Pescatori 1r-35v'
    transcriptionTypes={{
      transcription: 'Transcription'
    }}
    iiifManifest='https://cu-mkp.github.io/venice-editioncrafter-data/data/interviste-pescatori_1r-35v/iiif/manifest.json'
    thumbnails={false}
  />
);

and the thumbnails render properly, albeit it a bit slowly.

Notes and further work

Ideally this feels like it should not need to rely on a prop; there should be a way to check at the point that the document loads whether or not the thumbnail images are working, and to default to the backup behavior when necessary. But my head started to hurt figuring out the timing of that, since it involves inserting an extra http request into the lifecycle somewhere, so this is a quick fix for right now.

[ajolipa]

UPDATE: I improved the workflow here to remove the need for passing the flag; the cost of that is that in cases where the normal thumbnail image fails to load, we're now making two separate image requests at the stage of loading the grid view rather than just assigning the correct thumbnail URL from the start, but I think that's preferable to having to remember to pass a prop.

This is still not optimized, since the fallback if the thumbnail doesn't load right now is just loading the full image and scaling with CSS. I think ideally we'd do something smarter where we fetch data from /info.json to figure out the allowed size closest to the desired thumbnail size and then fetch that instead. But that would involve restructuring when the error is handled I think, since as best I can tell the onError callback can't be async. (Although I could be wrong about that.)