Include the Imgix.js generated srcset within react-imgix library

[victorwhy]

Imgix.js is great at what it does, unfortunately due to the nature of the html being generated after the DOM is loaded, there is always a risk of a flicker for the user.

I was looking into using this library instead to create responsive images, but noticed that the fancy srcset generation that Imgix.js does isn't part of this library.

It'd be great if we can have it generate that srcset list here as well :)

[frederickfogerty]

Hey @victorwhy. Thanks for the suggestion. Unfortunately, I haven't used Imgix.js in a while, can you please provide some more details about what Imgix.js does (regarding the srcsets)?

AFAIK react-imgix does something right now with srcset. It would be good to see explicitly what the difference is between the current behaviour and how Imgix.js works. 👍 😄

[victorwhy]

@frederickfogerty hi Frederick! thanks for responding.

But yeah, i did notice it did a bit with srcset, but i'm looking for something a bit more granular.

for example, if you use imgix.js it generates a src for every 100px

@jayeb pointed me here: FYI https://github.com/imgix/imgix.js/blob/master/src/targetWidths.js

[frederickfogerty]

Just to be clear, the benefit from having all those srcsets, is that when the image is server rendered, it doesn't flicker for the user when the react-imgix calculates the width of the component and generates the relevant srcset attribute, because it already has every relevant srcset?

[victorwhy]

it's just much more granular and is able to grab a closer resolution sized image.

i think currently react-imgix only serves like a regular resolution, and a dpr 2 type IIRC.

This one will serve that, as well as an image that is ~100 pixels away from the actual size of the container, which could save a bunch of space.

Does that make sense?

[frederickfogerty]

I'm sorry, I still don't quite understand the benefit of the Imgix.js approach.

From the README of react-imgix:

generateSrcSet={bool}
generate 2x and 3x src sets when using an tag. Defaults to true

react-imgix will server dpr 2 and dpr 3 resolutions for the current dimensions of the image only. react-imgix will only generate the srcsets that it deems are necessary. This is different (as far as I can see) to Imgix.js, which has a blanket approach.

I'm not sure if the "~100 pixels away" is in reference to this library. If it was, the reason behind that was to try reduce the number of cache misses for images that are not in fixed containers, thus creating a better experience for the user.

You can disable/configure that behaviour by changing precision to a small number (or 0).

Maybe @paulstraw can weigh in here and try understand what I'm

[victorwhy]

@frederickfogerty so yes, sorry, maybe I didn't make that clear.

For us, a lot of the images we use we upload the full resolution. So a lot of the times they'll be like 2-3MB files, and even with compression theyre still big.

So what Imgix.js does, is if you pass it in a sizes, it'll automatically generate 100 pixel ranges, from the smallest it can go, up to the final range, plus any retina stuff, you can see generally here.

So not only will it generate the different retina resolutions for that current size (dpr 2, dpr 3, that react-imgx currently does), it will also provide all the srcsets so it's fully responsive. That is, even though the original size we passed in is say, 500px, it'll generate a srcset that includes a 300px wide size of that image, so that anyone with a mobile device will get the 300px wide image, versus the full 500px wide image. But it'll also include 1000px for dpr2, and the 100px range up to there as well.

Does that make sense? It's more for images being fully responsive than anything else

[frederickfogerty]

react-imgix currently achieves the same effect, but in a slightly different way. It measures the actual size of the DOM element, and will generate src sets for the actual size of the DOM element on the actual rendered page. Therefore, if the element resizes, or is displayed differently on different devices, it will generate the relevant src sets for that device.

Does this make sense? I can't see any reason why the Imgix.js approach would produce different results to react-imgix in practice.

[frederickfogerty]

Maybe we could change our approach to using the in-built browser mechanisms, but for now it should be working fine.

[victorwhy]

I don't see that responsiveness happening when I tested it out with the react-imgix, unless I'm missing something.

<Imgix
        alt={data.image_alt}
        className={imgClass}
        key={key}
        src={`https://casper.imgix.net/${data.image_path}`}
      />

yields

which doesn't change regardless of what the width of your viewport is. there is no width parameter getting passed into imgix URL, so there's no way it's being responsive.

and as a sanity check, you can see that the full img sizes are being downloaded.

For example, when I use our custom srcset generator (which behaves a lot likeImgix.js, however, you can see that it requests different width images at different viewport sizes:

This is all from a single url, with a base width and a max width passed in to generate the range.

Unless I'm missing something, this is not the same at all.

[wichert]

For what it's worth I ended up using imgix.js itself with React:

import React from 'react'
import ReactDOM from 'react-dom'


class ImgixImg extends React.Component {
  componentDidMount() {
    this.setSrc(this.props.src)
  }

  componentWillReceiveProps(props) {
    this.setSrc(props.src)
  }

  setSrc(src) {
    const node = ReactDOM.findDOMNode(this)
    node.setAttribute('ix-src', src)
    // eslint-disable-next-line no-undef
    imgix.init()
  }

  render() {
    const {src, ...props} = this.props
    return (<img alt="" {...props}/>)
  }
}

export default ImgixImg

[frederickfogerty]

This will be fixed in the next major version, v8.