Image: modern API and implementation

[necolas]

Is your feature request related to a problem? Please describe.

Provider a high-performance Image implementation for web. This issue is to discuss how we should rewrite Image to support modern web features.

Describe a solution you'd like

The new Image should implement the following feature requests…

1. Support browser ML-generated alt text.
   • Allow Image to not set alt property so browsers can provide enhanced functionality #1636
2. Support browser lazy loading.
   • Support <img loading="lazy" /> attribute #1542
3. Support browser crossOrigin configuration.
   • Image doesn't work when cross-origin. #2171
   • Image updates: remove BG-style, add crossOrigin functionality, allow nullable alt text #2207
4. Display image in Windows High Contrast mode.
   • Image disappears in high contrast mode. #1298
5. Support image DPI switching.
   • prefer to load @2x image by default for import local images #2153
6. Support for CSS like backgroundBlendMode.
   • Setting background-blend-mode on <Image /> #2091
   • [Feature request] Add a way to add style to <img /> #2139
7. Available for SSR.

The new Image will not support the following APIs…

1. No tintColor, resizeMode, and shadow* styles.
2. No repeat value for resizeMode.

The proposed Image API looks like this…

<Image
  alternativeText=''
  crossOrigin='anonymous'
  decoding='async'
  draggable='false'
  focusable='false'
  loading='lazy'
  nativeID=''
  onError={() => {}}
  onLoad={() => {}}
  source={[ {uri, scale}, {uri, scale} ]}
  style={{}}
  testID=''
/>

Any dynamic loading via XHR/fetch would have to be layered upon that.

Additional context

Please comment with addition context and use cases.

[comp615]

We have two uses for the image queryCache I wanted to share here

1. When dataSaver is on, we try and get the largest cached variant already loaded (and use that instead) to save data.

// If data saver is on, then attempt to use the highest quality image we've already loaded to save data,
  // Exclude tiny variant (pre-data) saver images, so that we have a minimum quality
  const dataSaverCachedSource =
    dataSaver &&
    loadingVariant &&
    Math.max(loadingVariant.width, loadingVariant.height) >= MIN_RESOLUTION_CACHED_DATA_SAVER_THRESHOLD
      ? loadingVariant.uri
      : null;
  const src = dataSaverCachedSource || _selectSource(photo);

2. We use defaultSource to show the largest loaded image while the full-size variant loads:

<Image
        defaultSource={loadingVariant && loadingVariant.uri}
        draggable
        onContextMenu={onContextMenu}
        // If there's a fallback image showing, that's good enough and we can swallow the error
        onError={loadingVariant ? undefined : onError}
        onLoad={onLoad}
       // These just set internal state and shows a little loading spinner so people know we are upscaling the image
        onLoadEnd={this._handleLoadEnd}
        onLoadStart={this._handleLoadStart}
        source={src}
      />

[RichardLindhout]

Looking forward to this change!

Some possible solutions for implementing some of the props with CSS:

• object-fit to implement resizeMode

It would be cool if React Native could add something similar to object-position otherwise it would be nice if we could use it in React Native Web somehow.

• object-position

[viggyfresh]

@necolas just to make sure I'm understanding correctly - the proposed new API will be in tension with the React Native API such that it won't have built-in support for HTTP verbs like headers, for example, in the source property?

as this is already not present in the react-native-web Image implementation, this would be fine by our team 😄 i was hopeful that #1470 (or what looks to be a rebased version in #1843) would land, but I'm of course mindful of the fact that the React Native Image component API isn't aligned with the direction you'd like to go!

our use case, FWIW, is secure images served behind an authentication layer in our API server; i'm not sure how common of a use case this is. if there is a way to somehow shoehorn this in, I would love to see that or help make that happen. If not, our web-specific workarounds will live to see another day 😸

[jamesisaac]

I'd give a +1 to @viggyfresh's use-case of wanting to serve images behind auth.

For example, Expo (which wraps RNWeb) doesn't really have cookie support, so instead suggests using token-based auth: expo/expo#6756 (comment) . (Even if cookies were supported, I believe having all client-side data stored together in LocalStorage, and communicated via http headers, is a more modern approach).

So without support for cookies or http headers when serving images, I think the only option remaining becomes to stick the auth token in the querystring. I suppose there's not really anything wrong with that, but for consistency it would be nice if the same auth mechanism could be used everywhere.

[petrbela]

@jamesisaac

I think the only option remaining becomes to stick the auth token in the querystring. I suppose there's not really anything wrong with that

Sending private tokens in the query string is not recommended because unlike headers, they often show up in logs.