问题:为什么咱们会看到形如下列格局的日志?
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 的原创文章,尽在:” 汪子熙 ”: