feat(gatsby-image): Add support for native lazy loading#13217
feat(gatsby-image): Add support for native lazy loading#13217KyleAMathews merged 15 commits intomasterfrom
Conversation
| `loading` in HTMLImageElement.prototype | ||
| ) { | ||
| // Setting isVisible to true to short circuit our IO code and let the browser do its magic | ||
| isVisible = true |
There was a problem hiding this comment.
maybe to make it clear this is now representing two different states it could be changed to isVisibleOrNativeLazyLoadingSupported — verbose is effective :-D
There was a problem hiding this comment.
@KyleAMathews isn't the isVisible state here linked to the image components visibility state for it's picture element? I suggested a refactor here, but perhaps that's the wrong approach.
polarathene
left a comment
There was a problem hiding this comment.
I see you got onto while I was asleep :P All good, I think you did a better job than if I had attempted it!
Provided a review as requested :)
| } = props | ||
|
|
||
| const loadingAttribute = { | ||
| ...(nativeLazyLoadSupported && loading), |
There was a problem hiding this comment.
Is nativeLazyLoadSupported boolean actually useful here?
This doesn't seem like the right approach for handling this single attribute. You're defining a const obj with a potential single prop that if the boolean prop is true, adopts the loading var as a key/prop to it's contained string value?
The destructuring approach here and below for this seems to harm readability. Why not instead go with:
loading={loading || `auto`}
// or conditionally, if the prop isn't specified, the attribute won't be assigned
loading={loading}If the browser supports this attribute, auto is applied by default implicitly, there isn't a need to check for native support to assign it, makes no difference.
|
Fixes #13201 |
|
Any feedback to what I gave? If there's nothing wrong with it, I could perhaps make the changes as it seems @sidharthachatterjee is busy/away for a couple weeks now? If so, how do I contribute to this PR? Or do I need to fork it and send another PR in? Or does @sidharthachatterjee still want to finish this PR? |
Co-Authored-By: Dustin Schau <DSchau@users.noreply.github.com>
KyleAMathews
left a comment
There was a problem hiding this comment.
Awesome work @sidharthachatterjee!
|
@pieh You mean a glitch in the Matrix |
|
Published in |
* Add support for new native lazy loading to gatsby-image * Add loading prop to typings * Fix feature check * Fix optional prop * Update snapshots * Deprecate critical and map its value to loading * Document new loading attribute * Update comment * Apply suggestions from code review Co-Authored-By: Dustin Schau <DSchau@users.noreply.github.com> * chore: format * Do not show deprecation message in production * Clean up markdown table * Clean up markdown table again * Fix test
So... Chrome just added support for native lazy loading for images and iframes (https://twitter.com/addyosmani/status/1114777583302799360)
This PR adds support in
gatsby-imageso that we use native lazy loading when available and fall back to our IntersectionObserver code when not.Test
yarn add gatsby-image@loading-attributeNotes
I've exposed the
loadingattribute as a prop but just realised that we'll want to set that based on ourcriticalprop as @KyleAMathews noted in #13201Another thing to note is that we always set this for the no script Img tag (rendered during SSR and no js) since it's a progressive enhancement and setting it does not break anything in browsers that are yet to support it
Todo
criticalprop and setloadingbased on itRelated