Feature Request

The URL Loader was previously not applying a widthResize parameter if the widthResize parameter was larger than the width. this was to avoid creating useless URLs that didn't actually change beyond the URL.

this problem is that this logic shouldn't make that assumption in the URL Loader and should be on the caller to make that decision

This update was in v3.17.0

Upon updating, please update the width and width resize logic to correlate with the following:

  let widthResize;

  if ( typeof loaderOptions?.width === 'number' && typeof options.width === 'number' && loaderOptions.width !== options.width ) {
    widthResize = loaderOptions.width;
  } else if ( typeof loaderOptions?.width === 'number' && typeof options?.width !== 'number' ) {
    widthResize = loaderOptions.width;
    options.width = widthResize;
  }

  if ( options.width && widthResize && widthResize < options.width ) {
    options.widthResize = loaderOptions.width;
  }

This will essentially do the same thing, but now this logic is inside of the component to make that decision, along with anyone else who chooses to use the URL Loader library.

Source in Next Cloudinary with more comments for context: https://github.com/colbyfayock/next-cloudinary/blob/main/next-cloudinary/src/loaders/cloudinary-loader.ts#L35-L56

Future

The goal is to create a more reliable and simplified URL structure which may include more changes in the future, but for now, this will help avoid those assumptions being made for the caller without the ability to change how that works.

cloudinary-community / svelte-cloudinary

[Feature] Important - Update width logic #69

Feature Request

Future