(There's probably a bug here but let me digress a bit with a general problem here. cc @a2)

When you have <Image source={a} /> and then render <Image source={b} />, while the new source is being loaded, what should we do.

• Blank: The "correct" response is to blank out the image, then when b is loaded and decoded update the image. The big issue with this solution is that your UI is going to flash all the time leading to a very ugly end user experience.
• Keep a: The better user experience is to keep a around for the few milliseconds and when b is ready then display b. This avoids the flash and is fine as long as it doesn't take too long.

What's interesting is that on the web, there's actually both behaviors implemented. <img> tag keeps a while background-image blanks out.

We haven't made a concrete decision on this one yet and I'm unsure what's the current behavior, but this behavior is worth thinking about.

Maybe keep a around to make a smooth transition to b, but with a timeout where it transitions to a loading / can't load indicator if it hangs around too long?

Good idea :)

The "keep a" experience is probably better at an infrastructural level because you can always get the "blank" way by adding a key to the Image equal to the src.

@vjeux I've tried using <Image defaultSource=... /> to show some kind of a loading placeholder image, but it shows the old image indefinitely. I'll get a minimal repro set up for you.

Meanwhile is there workaround we can use to blank the image and force loading the correct one?

workaround

/* @flow */
'use strict';

var React = require('react-native');
var { Image } = React;

// Hack to work around https://github.com/facebook/react-native/issues/89
//
// Render an <Image /> normally.
// When react reuses the component with a new url, force react to render a
// blank image once before rendering the correct url later.

var DelayedImage = React.createClass({
  propTypes: Image.propTypes,
  getInitialState(): { showImage: boolean } {
    return { showImage: true };
  },
  componentWillReceiveProps: function(nextProps: any) {
    if(this.props.source.uri != nextProps.source.uri) {
      this.setState({ showImage: false });
      setTimeout(() => this.setState({ showImage: true }), 0);
    }
  },
  render: function(): React.Component {
    return <Image {...this.props} source={{uri: this.state.showImage ? this.props.source.uri : null}} />
  },
});

module.exports = DelayedImage;

The issue here now is that the images change but the text does not

@vjeux - who is the owner of ListView?

Probably an Image issue; I can't imagine it being specific to ListView.

This is pretty busted - any updates, @nicklockwood?

This is a tough one to catch since the results are never consistent. I was still able to reproduce the issue, maybe 1 out of every 4-5 attempts, following @jchris explanation.

See demo below for steps...

I think the catch here is to make sure each <Image /> inside of a ListView row has a key property set.
In the case of the Movie Example, adding a key to each image inside of our MovieCell seems to resolve the issue.

I've noticed some other people having issues with Images rendering properly within ListView and this did the trick.

<Image
  source={getImageSource(this.props.movie, 'det')}
  style={styles.cellImage}
  key={this.props.movie.id}
/>

Not sure if having to add a key a bug or just a requirement to get the images to re-render properly.
Thoughts?

My thought is that a "loadingImage" property? would force the state machine to represent that the image isn't ready.

@jchris - we can do this now by leveraging the onLoad callbacks 😄

Quick observation on this. I've been seeing this bug for sometime now elsewhere. I've tried keying the image, setting it in state, then calling form there. I've dropped debug points and can see the url that was being assigned to the image wasn't what I was seeing. It only happened on one image in my render row though which got me thinking...

Through elimination the thing that got it working for me was to remove the <TouchableOpacity/> and replace with <TouchableWithoutFeedback />. I have no idea why this works and it may be a Red Herring (maybe something was cached?) but mine has worked consistently through 15 builds now, and I can trigger the bug again as soon as I swap back.

@christopherdro fixed this in the commit referenced above 😄