Image Block: Improve performance by only requesting image metadata if selected.

[epiqueras]

Fixes #17465

Description

This PR stops image blocks from preemptively requesting image metadata and delays it until the block is selected.

This fixes performance issues with posts that contain many images.

How to test?

Verify that the image block still works as expected and that the issue described in #17465 is no longer happening.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[jorgefilipecosta]

Hi @epiqueras, checking the code it seems that the image object is only needed to select an image size updateImage( sizeSlug ) {... and to select an image link destination getLinkDestinations() {... Can't we extract these small UI pieces into separate small components and request the image object user using useSelect?
This way if the sizes/link UI is not expanded the image is not request at all.

[epiqueras]

I don't think that's worth the extra complexity.

What if we need it in other places as well?

Making the request once selected is perfectly fine from a performance standpoint.

[gziolo]

Doesn't what @jorgefilipecosta proposes aligns closely with the principles we shared when building components? I didn't look inside the code, but I think it makes a lot of sense to use data in components which consume it rather than pass it down from the edit. It's usually less code to use big edit implementation, but it doesn't mean that it's the most efficient one in terms of maintainability.

[epiqueras]

Doesn't what @jorgefilipecosta proposes aligns closely with the principles we shared when building components? I didn't look inside the code, but I think it makes a lot of sense to use data in components which consume it rather than pass it down from the edit. It's usually less code to use big edit implementation, but it doesn't mean that it's the most efficient one in terms of maintainability.

Yeah, but this component is already implemented and the fix is 2 lines. Breaking it into components is almost a complete refactor and shouldn't be tied to this fix.

[jorgefilipecosta]

I verified this fix works well, I guess breaking the big edit in components would be positive but I agree with @epiqueras it is something we can look after and not as part of this fix.