Gutenberg: 画廊块很慢

问题概述

由于它生成的请求数量，当前实现的 Gallery 块存在性能和扩展问题。 我不熟悉 React 中的最佳实践，但我会尝试解释我在使用画廊时看到的内容。

重现步骤（针对错误）

1. 插入一个新的图库块

2. 单击“从媒体库插入”按钮打开媒体模式
   
   这是标准行为，但只是为了解释会发生什么：当媒体模式第一次打开时，它会发送一个query-attachments AJAX 请求来获取 40 个最近的附件并将它们添加到可访问的全局集合中wp.media.model.Attachments.all 。滚动浏览库将一次延迟加载 40 个附件。

3. 选择 10 张图片，然后单击“创建新图库”按钮

4. 单击“插入图库”按钮
   
   __插入图库时，图库块会针对图库中的每个图像向 REST API 发出单独的请求。 在这种情况下，在预览画廊之前必须响应 10 个请求。
   
   除了向服务器发出请求之外，这还会造成不理想的渲染延迟。__

5. 单击工具栏中的编辑按钮以更新图库
   
   __块为图库中的每个图像发送一个get-attachment AJAX 请求。 每次打开媒体框架时都会发生这种情况。__

6. 关闭媒体框

7. 保存帖子

8. 刷新
   
   __当编辑器加载时，图像是从 REST API 单独获取的。__

预期行为

我希望画廊能够更快地呈现。 在我的本地机器上，一个包含 10 张图像的画廊可能需要 4-10 秒的时间来渲染。

可能的解决方案

理想情况下，如果帖子有图库，图像数据将被预加载以防止在初始加载期间出现任何额外请求。

打开媒体框架时，PR #2488 将有助于最小化请求。

从媒体框架插入图库时，渲染图库所需的所有数据都应在wp.media.model.Attachments.all集合中可用。 使用内存中已经存在的数据而不是为每个图像生成新请求会很好。 另一种选择是在单个请求中获取所有图像的数据。

我确实尝试为GalleryImage组件禁用withAPIData并且一切似乎都可以继续正常工作，但我没有进行彻底的测试。 如果将其删除，画廊将几乎立即呈现。

相关问题和/或 PR

PR #2488 在编辑图库时将媒体框架置于正确的状态，但也防止在打开模态时为每个图像生成单独的 AJAX 请求。