Not found 404 when using Cloudinary loader

[kwiat1990]

Hi, after update to 1.3.0 I'm having problems with loading images from Cloudinary. For starters I got rid of previous version of sharp transformer and replaced it with https://github.com/Josh-McFarlin/remix-image/tree/master/packages/remix-image-sharp. With that I could fix some errors which came up.

To be honest I find docs about loaders a bit confusing. Using cloudinary louder all images have wrong size as they get these inline styles by default (720 px comes from my value set in responsive prop):

    min-width: 720px;
    min-height: 720px;
    background-size: cover;
    background-position: center;
    background-image: url(...);

Examples from docs are a bit confusing to me. On the one hand: https://remix-image.mcfarl.in/docs/client-loader#cloudinary-loader, which is followed by this example https://remix-image.mcfarl.in/docs/client-loader#usage:

<Image
  loaderUrl="/api/image" // Required when using cloudinaryLoader or imgixLoader
  loader={remixImageLoader or cloudflareImagesLoader or cloudinaryLoader or imgixLoader}
/>

At the end I don't know what values should be put for loaderUrl: /api/image or https://res.cloudinary.com/<myCloud>?

URL for images from CMS looks following: https://res.cloudinary.com/<myCloud>/image/upload/v1650996204/proste-opowiesci-develop/demo_4_fbb3dc7519.jpg.

When I follow the docs, I get 404 for my images, e.g. https://res.cloudinary.com/<myCloud>/w_720,q_auto,f_auto/https://res.cloudinary.com/<myCloud>/image/upload/v1650996204/proste-opowiesci-develop/demo_4_fbb3dc7519.jpg. What a bit confusing, if I omit responsive prop, then all images can be found and properly loaded. With responsive URLs for images are broken and only placeholders will be loaded. On the other hand, when I use not those URLs from CMS, but Cloudinary ´public_id´ instead, then images are loaded but placeholder not.

Additionally, options and defaultOptions seem to be ignored.

[Josh-McFarlin]

Hey @kwiat1990,

I'm in the process of typing out a large explanation, but in the meantime try these fixes:

1. Set loaderUrl to: https://res.cloudinary.com/<cloud_name>/image/upload/
2. If that doesn't work, keep it, and try the following: For the src prop, only use the asset's id and extension on Cloudinary. For example, for the image https://res.cloudinary.com/<cloud_name>/images/upload/cooking.jpg you would just set src to be cooking.jpg

If you would like to use images from outside your Cloudinary assets, you might be able set your loaderUrl to https://res.cloudinary.com/<cloud_name>/image/fetch/ and then you might not even need to do #2, based on these docs: https://cloudinary.com/documentation/fetch_remote_images#remote_image_fetch_url

[kwiat1990]

Sadly, none of these both steps work in my case. For both, image (throws 404) and placeholder (throws 400), are no images loaded

[Josh-McFarlin]

Hey @kwiat1990,

Sorry the docs were unclear. Hopefully I can explain a little better here and then update the docs soon.

Loaders

Remix-Image allows you to optimize your images in two different ways.

1. Remix-Image will setup an API route that will optimize/transform any image you ask it to. When you use the Remix-Image component, it will make a request to your Remix API route asking it to transform the image. Therefore, Remix-Image is running on the frontend (Image component) and the backend (imageLoader)
2. Remix-Image will optimize your images for you using an external service like Cloudinary / Cloudflare Images / Imgix. It does this by using the Image component, so you can use the same props/syntax as option 1, but uses these options to create HTTP requests for your external image transformation service. In this case, you're only using Remix-Image on the frontend, and no special code is being run on Remix, it's purely a utility function (component) to help construct your calls.

Option 1

When your are using option 1, loaderUrl refers to the path to your API route on your Remix server that hosts Remix-Image’s imageLoader backend function.

When following the Remix-Image tutorial, it instructs users to place the API route in app/routes/api/image.js which would mean the loaderUrl would be "/api/image". Remix-Image uses this as the default value for loaderUrl, but you can place this API route anywhere and just set the loaderUrl prop.

In this case, you use remixImageLoader because it constructs the image’s SRCs to be your loaderUrl and call your API route. But the Image components use remixImageLoader as the default option, so you doing really need to set the prop or see it in the documentation unless you are doing option 2.

TLDR:

• loaderUrl: Not necessary unless your API route is in a different location than app/routes/api/image.js
• loader: Not necessary since the Image component uses remixImageLoader by default unless you want to explicitly state it for clarity

Option 2

When you are using option 2, you provide one of the ClientLoader functions to the Image component. In this case, you are using an external services’ API route to modify your images, so you need to set the loaderUrl to your what’s specified by your provider’s documentation:

• cloudinaryLoader: This should be a string similar to https://res.cloudinary.com/<cloud_name>/
• imgixLoader: This should be a string similar to https://<subdomain>.imgix.net/
• cloudflareImagesLoader: When using Cloudflare Images, you don’t need to set a loaderUrl because they setup a API route on your same domain

Yet as you’ve seen, I have yet to figure out the optimal URLs to provide for each service’s loader because I am using option 1. The provided loaders may have various bugs, so a PR would definitely be accepted if you are more knowledgeable about their particular API.

Also, since you are using a ClientLoader, you don’t need to setup a imageLoader API route (and therefore don’t need to install any transformers like remix-image-sharp)

TLDR:

• loaderUrl: Set it if using cloudinaryLoader or imgixLoader, not needed for cloudflareImagesLoader
• loader: Set it to cloudinaryLoader, imgixLoader, or cloudflareImagesLoader` depending on which service you are using

Styles

A goal of Remix-Image is to help your website load faster by optimizing images. One method Remix-Image uses to do this is setting image to lazy load by default. What this does is only make the HTTP request for an image once the browser has determined the img element is about to be shown on the screen (such as scrolling down the page).

However, a problem that occurs is that the browser doesn’t know how large an image is until the HTTP request has been made. This means that until the full image has been requested, the base img element is effectively a 0px by 0px square, causing all the content on your page to move upwards, meaning more Image components are within/nearby the viewport, causing the lazy HTTP request to be made even though the true image would be far enough down on the page to not be seen and the lazy HTTP request would not be called until you scrolled down enough to see it.

So how do you ensure a lazy img does not make its HTTP request until the user has scrolled enough for it to be seen? You provide a placeholder image (either a very small blurred version of your real image or an empty/transparent PNG) that estimates the real size of your image.

Nextjs/image handles this by applying the sizing styles for the placeholder image, and then removing them once the real image has been loaded. However, Remix has a greater focus on supporting clients that load the website without JavaScript enabled. The approach that Nextjs/image does not work because the JavaScript used to remove the placeholder styles once the real image has loaded is never run on clients with JS disabled. In order to have the same behavior on clients that do and do not support JavaScript, I made the decision to not remove the placeholder styles on image load.

If you know how big your image is going to be, you can always set the dimensions yourself and override the placeholder styles. You can do this by setting the Image component style prop or by overriding the package’s CSS.

/* my-styles.css */
.remix-image {
  min-width: initial !important;
  min-height: initial !important;
  width: 500px;
  height: 600px;
}

Alternatively, if you don’t know the images size ahead of time but still want to remove the styles on load, you can mimic the Nextjs/image behavior yourself by adding a callback function to the onLoadingComplete prop:

import { Image } from “remix-image”;

const MyImageComponent = () => {
  const [style, setStyle] = React.useState({});

  return (
    <Image
      style={style}
      onLoadingComplete={React.useCallback(() => setStyle({
        minWidth: “initial”,
        minHeight: “initial”
      }))}
    />
  );
}

If you don’t want this to happen at all, either use the BaseImage component, or set the prop unoptimized={true} for the Image component. There won’t be any styles set on your img element, but the downside is you will have layout shift and images may be loaded before they are needed.

TLDR: Image components are given sizes in their style prop as a performance optimization. If you don’t want this behavior, either override the style prop, use the BaseImage component, or set the prop unoptimized={true} for the Image component.

[kwiat1990]

@Josh-McFarlin thank you for such deep explanation 🙂.

I came up with the idea of using public_id of an asset and it did worked for images but at the same time it throws errors for placeholders (in the console and network tab) bit blur effect still works. I don’t quite get it.

I’ve also overridden CSS with my own styles. What seems odd is fact that setting aspectRatio prop helps but the image is not really responsive, so if it has 700 px then it takes this space and overflow parent component. That’s why I needed to set my own styles with !important.

The other issue Is that with above adjustments the routing in my app is broken. When I navigate to another route with images an error gets thrown due to classList of undefined. Thhis behavior is the same for both - default loader and cloudinary loader. After a hard page load it works:

react-dom.development.js:22839 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at clsx.m.js:39:9
    at safelyDetachRef (react-dom.development.js:22908:22)
    at commitDeletionEffectsOnFiber (react-dom.development.js:24003:11)
    at recursivelyTraverseDeletionEffects (react-dom.development.js:23989:5)
    at commitDeletionEffectsOnFiber (react-dom.development.js:24118:9)
    at recursivelyTraverseDeletionEffects (react-dom.development.js:23989:5)
    at commitDeletionEffectsOnFiber (react-dom.development.js:24118:9)
    at recursivelyTraverseDeletionEffects (react-dom.development.js:23989:5)
    at commitDeletionEffectsOnFiber (react-dom.development.js:24018:11)
    at recursivelyTraverseDeletionEffects (react-dom.development.js:23989:5)

[Josh-McFarlin]

Hey @kwiat1990,

I just released remix-image v1.3.2 that fixes a few of the bugs you encountered

• Placeholder images weren't using the loader prop, which is why they failed to load while your full-sized images did
• Verifying the internal img ref exists before working with classList, which was breaking your app and routing
• Moved transformer defaults to the useResponsiveImage hook, previously the defaults were only applied on the Remix server API route, so that's why using the Image component with a loader didn't apply the expected defaults

Beyond these fixes, I am considering changing the placeholder sizing behavior. It definitely isn't ideal at the moment, so I'm just trying to think of a good way to preserve layout while images are loading only, while also not having too much of a difference on clients with and without JavaScript enabled. I'm hoping to have an update for this out within a week.

[kwiat1990]

Hi @Josh-McFarlin, I could finally test the latest version and it fixed the issue with classList. On the other hand, right know, I can't fetch images using cloudinaryLoader. I have tried all solutions but in the most successful one only placeholders were loaded. For images I get either 400 or 404.