Add Image component

[oliviertassinari]

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

Implement an enhanced version of the native <img> element.

Examples 🌈

import { Image } from '@material-ui/core';

<Image src="" />

Motivation 🔦

A couple of features we could bring:

1. Use display: inline-block; to avoid layout jumps when the image is loading or broken.
2. Provide a custom fallback component when the image fails to load.
3. Support a loading indicator when the image takes too much time to load, e.g Skeleton.
4. Add a smooth animation for displaying the image once loaded.
5. Support a placeholder to display while image's loading. An image of lower resolution.
6. Lazy loading? Maybe not relevant considering https://caniuse.com/#feat=loading-lazy-attr and https://web.dev/native-lazy-loading/.
7. Support aspect ratio. For instance, it allows rendering an image with a width constraint without having to wait for the image to load over the networks to resolve its height (which might lead to a layout shift).

Benchmark

• https://github.com/imgix/react-imgix
• https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-image/src/index.js
• https://amp.dev/documentation/examples/components/amp-img/?format=websites
• https://vuetifyjs.com/en/components/images/#images
• https://bootstrap-vue.js.org/docs/components/image
• https://github.com/chakra-ui/chakra-ui/blob/master/packages/chakra-ui/src/Image/index.js
• https://github.com/jossmac/react-images
• https://backpack.github.io/components/image?platform=web
• https://ionicframework.com/docs/api/img
• https://github.com/FormidableLabs/react-progressive-image
• https://joshwcomeau.com/performance/embracing-modern-image-formats/
• https://github.com/konvajs/use-image/
• https://github.com/mbrevda/react-image
• https://github.com/gokcan/react-shimmer
• https://react-spectrum.adobe.com/react-spectrum/Image.html
• https://github.com/fpapado/react-lazy-images
• https://github.com/react-component/image

[michael-land]

<Image /> maybe not a good name for DX purpose if developers rely on editor autocomplete. because the Image class always be the first option.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/Image

[oliviertassinari]

<Image /> maybe not a good name for DX purpose if developers rely on editor autocomplete. because the Image class always be the first option.

@michael-land It reminds me of one of the reasons why we didn't call Typography: Text. In hindsight, it didn't seem to have stopped a lot of component libraries from using this name:

• https://theme-ui.com/components/text
• https://seek-oss.github.io/braid-design-system/components/Text
• https://evergreen.segment.com/components/typography#heading_text_component
• https://blueprintjs.com/docs/#core/components/text
• https://primer.style/components/Text
• https://gestalt.netlify.app/Text
• https://chakra-ui.com/text
• https://ant.design/components/typography/#Typography.Text
• https://developer.microsoft.com/en-us/fluentui/#/controls/web/text
• https://sancho-ui.com/components/text/

As long as you have eslint or TypeScript, it should be fine:

Otherwise, it's a nightmare:

---

The other reason we have kept Typography was to match the theme.typography structure. But we could also argue that using two different names would reduce confusion when searching on Google 🤔.

---

Next.js went with Image: https://nextjs.org/docs/app/api-reference/components/image

[eps1lon]

I don't think we can implement meaningful features since the most important ones rely on the build setup. A meta framework is far better suited to host such a component. There's a RFC in nextjs which has far better research and highlights why this component should leverage the build setup: vercel/next.js#16832

[eps1lon]

The only feature that we can meaningful implement is responsiveness considering we have breakpoints in the theme. All the other features are better suited for meta-frameworks.

[oliviertassinari]

other features are better suited for meta-frameworks

Which comes with a drawback: portability. What works in Next.js doesn't in Gatsby or CRA.

[vicasas]

Would this bring support for <picture /> and <figure /> ?

[AGDholo]

Can I use the element inside the component to have the image as a background image?

Such as:

<Image src="xxx">
  <div />
</Image>

[vicasas]

@oliviertassinari @eps1lon In my team we had the need to have an Image component to improve the user experience when browsing our e-commerce site. We saw many solutions and dared to create a Material UI based component from scratch.

Here is a Codesandbox with a POC that I built, maybe it can be used in something for the construction of this much desired component and start working on it (:

Features:

• Slow image loading
• Fallback loading
• Fallback error

https://codesandbox.io/s/material-ui-image-8icbi?file=/src/App.js

[siriwatknp]

I think the solution to this issue is to bring AspectRatio component to Material UI.

As a UI library, it makes more sense to provide a component that helps control the layout and leave img to the consumers. The AspectRatio works well with frameworks like NextJS, Imgix (we could add more to the list). cc @DiegoAndai

[DiegoAndai]

@siriwatknp, that makes sense. Which of the description's motivation features could we cover with the AspectRatio component, and which would need another approach?

[siriwatknp]

@DiegoAndai I should not have used the word solution in my previous comment. The AspectRatio component is not the solution to things like fallback, loading, and placeholder. In fact, those issues are already fixed by meta-framework as @eps1lon mentioned in #22470 (comment).

My point is that we should leave the Image component to meta frameworks and provide a layout component (AspectRatio) as a companion. So, I think this issue should be closed, and another one should be created for adding AspectRatio to Material UI.

[DiegoAndai]

@siriwatknp Agree. Would you open a new issue for adding the AspectRatio and close this one when that's done?