feat(gatsby-image): add nativeLazyLoading prop to allow users decide which lazy loading strategy to use

[damianstasik]

Description

The native lazy loading is supported only by Chrome 75+ and even though I am currently using 77, I was not getting the results I was looking for. All the images were loading regardless of the setting, on both fast and slow network.

This PR adds a prop called nativeLazyLoading which allow users decide which strategy should be used: native loading or IO.

[sidharthachatterjee]

Honestly, I'm not sure if adding an option for this is a great idea because

• It'll be another option we'll have to maintain
• We'd definitely prefer to default to Chrome's native lazy loading (which we expect to get better in due time)

Can you elaborate on what you mean by not getting the results I was looking for?

Perhaps using a fork of gatsby-image will solve your issue?

[damianstasik]

@sidharthachatterjee For now Chrome is still the only one supporting it, and doing so in their way, not as per spec.

It'll be another option we'll have to maintain

Yes, but you also have to maintain the magic behind detecting whether browser supports the native lazy loading. This prop would give people an option to decide which strategy to use.

Can you elaborate on what you mean by not getting the results I was looking for?

Lazy-loading was just not working for me, all the images were loading on the initial page load which should not happen. Disabling the native strategy was the only way to achieve true lazy-loading in Chrome.

[pvdz]

Hi @visualfanatic, thanks for opening this PR.

The bad news: I'm going to close this PR and I will explain why.
The good news: I like the PR so if you're still interested I hope you'll follow the suggestions outlined below and we can merge a change like you intended :)

• There is no attached issue / discussion around this problem. We haven't seen signal that this is a common problem. We prefer not to land options that are one-off or fix a very specific use case.
• There is no documentation as to how this new option is to be used
• There are irrelevant changes in the diff, like changing the test case name (I'll quickly merge that through chore(gatsby): drop the the #23295, thank you :) but also your change to how props is deconstructed seems irrelevant, you could have just added your props (and optionally refactored that deconstruction in a separate commit in this PR).
• There are tests. Nicely done!
• The PR is outdated. That's not a reason in itself and also not a good sign but it is what it is.

So, please, open an issue for discussion, see if other people want this option too. Then open a new PR which tries to be concise in the change and don't forget to document any new options.