传入 originalEngine 到装饰器 decorateExpressEngine 里：

![](https://img-blog.csdnimg.cn/img_convert/36f8ddbaadec92b3379adc999c9d7fac.png)

传出的是一个 engine 函数，engine 函数包括了 original Engine 这个函数，然后调用 engine 函数，同时将 Engine 参数传入，得到第二个 engine instance 函数。

最后的服务器端渲染，就是该 engine instance 函数负责处理。

我们再来看看生产版本的 engine 实现原理：传入 decorator 的第一个 engine 实例，来自 Angular @nguniversal/express-engine:

![](https://img-blog.csdnimg.cn/img_convert/9dc9a7365f09b044d9ec5b22af368ac6.png)

这个装饰器返回一个新的函数。

(1) NgExpressEngine 的输入参数
(2) Spartacus 开发团队引入的优化参数，通过闭包传入
(3) Angular 标准的 NgExpressEngine 实例

![](https://img-blog.csdnimg.cn/img_convert/d37bc4f7104e013784b16be13321ba2b.png)

在实际的生产代码里，通过装饰器的 get 方法，传入 nguniversal/express-engine 标准的 engine，返回 ngExpressEngine：

![](https://img-blog.csdnimg.cn/img_convert/bbfb703d82f28d2e386796c1da9c599a.png)

然后这个 ngExpressEngine 被作为参数，传入 server.engine 处理参数：

![](https://img-blog.csdnimg.cn/img_convert/45f97d542d5a8bfae304a9988038369b.png)

再看单元测试里的代码：传入装饰器的第二个参数为 null，意思是不使用 optimization engine：

![](https://img-blog.csdnimg.cn/img_convert/5d93b01de9c708fa071fe0a918e75918.png)

第135行代码返回的是下图第47行的函数体本身：

![](https://img-blog.csdnimg.cn/img_convert/3446e2ead15eb2c59fb5c50ec51233d6.png)

如果我们观察返回的 engine 实例，就能发现它内部包含两个闭包，存储了装饰器调用时，传入的 originalEngine 和 optimization option 的值：

![](https://img-blog.csdnimg.cn/img_convert/6381742dfc58b1a755394cd8a0c087e9.png)

接下来执行第136行代码，即 135行装饰器返回的新函数的函数体：

![](https://img-blog.csdnimg.cn/img_convert/7304db25c98ae6dfbb1f83bd86e0e6a4.png)

当然，因为 ngExpressEngine 已经被 mock 过了，所以返回 callFake 指定的 mock 版本的实现：

![](https://img-blog.csdnimg.cn/img_convert/28dfe4c4fecc6e3b6c752947504dd475.png)

因为传入的 optimization option 为空，所以不使用 optimization engine，因此返回 original engine instance：
![](https://img-blog.csdnimg.cn/img_convert/8ba9ca030569b1e78f19b15af326fa5a.png)

ITPub博客

SAP 电商云 Spartacus UI SSR 里 engine 和 engine instance 的区别

最新文章