Trouble understanding srcSet usage with this library

[RickeyWard]

The docs explain you must using srcset instead of fullsize / thumbnail treatment. This is neat feature but it seems that zoom actually depends on width and height provided to decide how far to pan. That means I have to store and and transmit the size of the images.

What is the right way to handle showing whatever image is available and also a thumbnail version for save on loading if they don't scroll through all the thumbs? if I don't know the actual width and height when zoomed in, the pan doesn't work correctly.

I don't want to have to parse the image on the server side to send the size (cpu overhead), and I don't want to store the sizes in the database (network/stroage overhead), and I don't want to enforce a fixed size image (my server resizes very large images but leaves smaller images intact)

am I misunderstanding how this works? width and height seem to be required if using srcset and they need to be accurate.

[igordanchenko]

am I misunderstanding how this works? width and height seem to be required if using srcset and they need to be accurate.

That's right. To utilize the built-in responsive images with automatic resolution switching, you must populate srcSet attribute with accurate src, width, and height values. srcSet is not required, but it helps optimize network bandwidth and improve user experience.

What is the right way to handle showing whatever image is available and also a thumbnail version for save on loading if they don't scroll through all the thumbs?

You can provide whatever image URL is available in the src prop. In this case, the same image will be rendered as both main image and thumbnail. Please note that the lightbox preloads only (2 * carousel.preload + 1) slides. For example, if you provide 50 slides, the lightbox will load only 5 images when it opens.

[RickeyWard]

Thanks for the clarification. I don't like this aspect but its such a fantastic library I'll deal with it. Thank you!

[igordanchenko]

Can you clarify what issues or inefficiencies you are experiencing that make you dislike the current implementation? What would you like to see the library do differently?

[RickeyWard]

I struggle to see how to the srcset solves the specific problem I have.

situation:

• item has a list of associated images, thumbnails are already shown so they are already cached in the browser.
• the only way to see an image at full size is to click it to open the light box.

Since the lightbox requires you know the sizes of all the full-sized images in advance (info I don't have) in order to load thumbnails that aren't just the fullsized image auto scaled down those fullsized images have to load to see the thumbnails. but its possible the user just wanted to look at that one image and I'm loading more of them than requested. and the thumbnails are empty until the big images load but I already have thumbnails cached they should be immediate.

so I end up with 2 problems.

1. over-fetching -> loading more full-sized images than needed without control
2. delayed thumbnails -> waiting on full sized images to see thumbs that I technically already have cached

The ability to specify a URL for each thumbnail and full-sized without knowing the image size is a strength of the old model not a weakness in my opinion.

I tried tricking the srcset which would usually work by giving the full-sized image a fake size. this correctly gets the browser to the load the correct image but it breaks zoomed panning

since its a plugin model I think I can just modify the plugin to suit my needs.

[igordanchenko]

Thank you for providing the additional details.

I struggle to see how to the srcset solves the specific problem I have.

It absolutely doesn't, as it's incompatible with your use case. srcSet is only suitable for scenarios with known width and height attributes. It is a particularly good fit for projects utilizing automatic image optimization (e.g., Next.js or most modern CDN providers) as it allows browsers to download images of smaller resolution based on the viewport size (a win-win for UX and network utilization).

The ability to specify a URL for each thumbnail and full-sized without knowing the image size is a strength of the old model not a weakness in my opinion.

Well, unfortunately, this library was primarily designed for use cases with known width / height attributes and optional scrSet. Some features aren't even supported when slides specify just the src attribute, and the "old model" is supported on a best-effort basis. I'm sure some other libraries are a better fit for the "old model".

over-fetching -> loading more full-sized images than needed without control

You can decrease carousel.preload prop down to 1 or 0, but that'd affect the number of thumbnails as well.

delayed thumbnails -> waiting on full sized images to see thumbs that I technically already have cached

I see the issue now. I will look into adding a thumbnail slide prop for the Thumbnails plugin.

[RickeyWard]

....It is a particularly good fit for projects utilizing automatic image optimization (e.g., Next.js or most modern CDN providers) as it allows browsers to download images of smaller resolution based on the viewport size (a win-win for UX and network utilization).

There is a trade off on storage or cpu usage / processing that you pay for to use this feature. Easy to add if you want to pay those costs.

Well, unfortunately, this library was primarily designed for use cases with known width / height attributes and optional scrSet. Some features aren't even supported when slides specify just the src attribute, and the "old model" is supported on a best-effort basis. I'm sure some other libraries are a better fit for the "old model".

while I agree with that, other than this one thing, it seems like it works exactly how I want/expect in every way.

Thanks for taking the time to look into it.

[RickeyWard]

I just pulled 3.19.0 works perfectly! thanks!