thoughts on <picture> support?

[eleith]

great library. I've enjoyed using it.

your roadmap doesn't mention < picture > support.

what is your thought on that.

any suggested workarounds to support both lazy loading images with this library but using < picture > to load the right image supported by the browser?

[fpapado]

Hi, @eleith!

Thanks for getting in touch. <picture> support has been on my mind recently, and I think it should be possible to implement it. I will give it a shot over the weekend. The main thing I am considering is that the Picture API is different to just <img/>. Namely, it gets the sources from the children, as a "compound" element. Getting the source up-front is important for being able to preload the image, and avoid jumpiness when swapping. it also allows us to monitor the loading and error states (since we load the image programmatically), and render as specified.

Working around it now

If you need to use picture with this library atm, you can do so in a workaround fashion 🎉

The documentation and types declare src as required, but it is not "required" in its implementation. Such is the nature of props, for better or worse. Without a src, instead of breaking, the behaviour degrades to just swapping when in view, instead of preloading etc.

I put together a quick demo of this:
https://codesandbox.io/s/l48o7qk5pm

Reiterating the note in that link:

If you skip the src prop, then no preloading happens. Neither does any error/loading tracking.
The image swaps in once in view, and then the normal browser loading proceeds. Not ideal, but
you can lazy-load most things that way. A proper LazyPicture would offer a more ergonomic API,
and better loading behaviour. NOTE: You will get content jumping, unless you have a fixed
Placeholder / aspect ratio strategy. See the Codesandbox from the react-lazy-images docs
for an example of such a component.

(Aside: if you only care about changing the image dimensions, and not the source type or the source altogether, then img and srcSet are fully supported by the library as-is).

Note on versioning

This was actually documented in early versions (and src was optional), but I gave up on exposing it in favour of figuring out good APIs based on each element. If you do use this, know that you are relying on an implementation detail; I don't deprecate things without warning, but hey, semver.

Future API

I would like to have a LazyPicture, perhaps, that can accept the various sources and preload as appropriate. This hinges on the programmatic support for new Picture. If you know more on the topic, and better yet if you have concrete use cases, I would love to hear about it!

Hope this helps :)

[eleith]

awesome response. thank you.

my current use case is thinking about how i would support browsers that can view webp.

for now, i'm using srcset to support hdpi devices and that works very well with this library.

let me play around with some of the ideas you have above.

fyi, i am using helper components i've written to take advantage of common patterns i was using in adopting this library (https://gist.github.com/eleith/a1b78d2c869895f8079b0d66d171144c).

so definitely my first thought in terms of an API was around how the helper component i would write would look like =]

[MathieuDebit]

Hi,

<picture> support would be great! I also need it to support webp format with a fallback for browsers like Safari. With lazy-loading, it adds a huge performance improvement for big websites with a lot of images per-pages.