1.6.0 null width in rendered <img /> tag

[matfisch]

I noticed after bumping to version 1.6 that if the <Image /> component is passed both width and the responsive prop that the returned <img /> tag width property is null. The outcome was all of our images grew significantly in size.

.cld-responsive{
    max-width:100%;
    max-height: 100%;
}

Given the rules for cld-responsive I wouldn't be surprised if we are misusing the responsive prop (it is defaulted to true in our of our components that wraps <Image />) but this hasn't been an issue until version 1.6.0.

I could use some more clarity on the intent of the changes if this is expected behavior.

Steps to reproduce

<Image
   responsive
   publicId={publicId}
   width={width}
   height={height}
/>

1.6.0 <img width="null" height="68" data-src="..." src="..." class="cld-responsive">

1.5.1 <img width="68" height="68" src="...">

[ghost]

Hi @matfisch, thanks for letting us know, we're looking into this.

[ghost]

Hi @matfisch, Until a fix for this is released, here's a workaround, please let me know if this solves the issue for you: If you'd like the fetched image width to be determined by it's container's width, then you should pass <Image ... width='auto' responsive/> If you'd also like the resulting element width to be some specific value, you can also pass: <Image ... width='auto' responsive style={{width:'68px'}}/> Or not pass 'responsive' at all, this will affect the actual fetched image width, and the width of the element: <Image ... width={68}/>

Reason for this: In version 1.6.0 the react SDK's responsive prop handling was aligned with cloudinary-core, and all other js SDKs. The responsive prop adds a data-src attribute and a cld-responsive class to the underlying element, and also, if width='auto', will update the image transformation's width param to match it's container width. So passing the 'responsive' prop when width !== 'auto', will add a cld-responsive class, but will not affect the size of the fetched image.

[ghost]

@matfisch We've published a new version (1.6.1) with a fix for this. Please let me know if this solves the issue for you.

[matfisch]

@maoznir It does. I appreciate the quick turnaround and the support for this odd use case.