乐趣区

关于sap:为什么我们会看到-SAP-Spartacus-服务器端渲染-rendering-in-process-的日志

问题:为什么咱们会看到形如下列格局的日志?

CSR fallback: rendering in progress

每次新的申请达到 SSR 时,都会调用文件 spartacus-setup-ssr.js 中的 renderResponse 函数。

在其中,this.shouldRender 被调用,以评估应如何解决此申请。

在 shouldRender 中:

step1:评估以后并发数是否达到下限。评估逻辑是通过将以后并发值(在 this.concurrency 中保护)与客户传递的选项(this.ssrOptions.concurrency)进行比拟来实现的:

源代码:

const concurrencyLimitExceed = ((_a = this.ssrOptions) === null || _a === void 0 ? void 0 : _a.concurrency) ? this.currentConcurrency >= this.ssrOptions.concurrency
            : false;

step2:评估同一页面是否曾经有渲染过程。

const isRendering = this.renderingCache.isRendering(this.getRenderingKey(request));

如何判断两个渲染申请是否代表同一个页面?

这是由第 97 行中的函数 this.getRenderingKey(request) 实现的。

默认的辨别逻辑是应用申请的 originalUrl 字段,即如果两个申请的 originalUrl 雷同,则 SSR 将它们视为同一个页面。

如何判断给定页面是否曾经有正在进行的渲染过程?

在 spartacus-setup-ssr.js 的 RenderingCache 类中,咱们应用 Map 通过键值构造来保护每个页面的渲染过程,参见上面的第 9 行。

默认状况下,key 是申请的 originalUrl,value 是一个蕴含布尔标记的对象:true 或 false。

如果能够从 RenderingCache 的 Map 中找到等于 true 的给定值,咱们认为给定页面正在渲染。同时,如果另一个申请带有完全相同的页面键(即雷同的 originalUrl),咱们将不会通过 SSR 提供第二个申请,而是触发 CSR 回退,并在上面的第 99 行打印日志。

留神:应用 RenderingCache 记录页面是否正在渲染的逻辑始终处于开启状态,无论选项“cache”的值如何。

更多 Jerry 的原创文章,尽在:” 汪子熙 ”:

退出移动版