没有 SSR 的 Vuestorefront - asyncData 未触发

如何解决没有 SSR 的 Vuestorefront - asyncData 未触发

我对 Vuestorefront 重建的体验非常糟糕，因为代码的每次更改都需要大约 25 秒。所以我决定关闭 SSR（用于开发），现在大约需要 3-4 秒！ ...但现在 VueJs 生命周期存在问题。

我用什么

1. 官方 Vuestorefront 存储库：https://github.com/vuestorefront/vue-storefront

Storefront 安装有：yarn、演示 API、SSR 端点和默认主题。一切正常，但开发速度缓慢。

2. 优化的 Webpack 配置：https://github.com/yireo-training/vsf1-local-webpack

按照自述文件中的教程一切正常，代码中的每个更改都在 4 秒内构建。成功构建会自动刷新网站，并使用热重载。

---

有什么问题？

• 我无法直接打开任何链接（链接到产品、类别等...），也无法刷新/重新加载任何页面

我发现在这些情况下会跳过预加载数据的函数 asyncData。例如产品页面：https://github.com/vuestorefront/vsf-default/blob/master/pages/Product.vue#L334 当我从主页点击产品详细信息时，函数 asyncData 被触发，产品页面正确加载，但刷新 (F5) 被跳过 asyncData。

重新加载后的产品页面：

我尝试将代码从 asyncData 重新实现到方法 beforeCreated，但它仍然不起作用。

---

我的问题

如何强制调用函数asyncData？

...或者有没有办法重新配置 Webpack 使其工作？

...或者有没有其他方法可以更快地重建 vuestorefront？

解决方法

感谢您试用我的 Webpack 配置。请注意，它远非完美，它需要思想的协作才能使其在所有情况下都能发挥作用。

正如您在代码中已经看到的：Vue 元插件使用 metaInfo 方法来提供标签。 Product 组件再次调用可计算的 getCurrentProduct 可计算，后者再次调用 Vuex getter product/getCurrentProduct。同样，这需要执行 asyncData() 方法，以便从 ElasticSearch 或 GraphQL 加载数据。

asyncData() 通常要么在浏览器中异步执行（废话！），要么在 SSR 工作时在服务器上同步执行。这意味着在默认的 VSF1 情况下，调用 this.getCurrentProduct.meta_title（在 metaInfo 方法中）永远不会失败，因为它将依赖于之前已经同步加载的 Vuex 中的某些内容。但是，如果没有 SSR，这会导致代码问题，因为在执行 metaInfo 标记后 将填充 Vuex 存储。因此，将 metaInfo 方法重写为如下所示可能更有意义：

metaInfo () {
    const storeView = currentStoreView()
    return {
      title: this.getCurrentProduct && htmlDecode(this.getCurrentProduct.meta_title || this.getCurrentProduct.name),meta: (this.getCurrentProduct && this.getCurrentProduct.meta_description) ? [{ vmid: 'description',name: 'description',content: htmlDecode(this.getCurrentProduct.meta_description) }] : []
    }

我自己还没有尝试过这段代码，但希望它有意义。这将证明在默认主题中提供的许多组件（无论如何你很可能会自定义，对吗？）只考虑了 SSR（这对我来说很有意义）。

如您所说，另一个尝试可能是对每个组件执行 asyncData。 core/client-entry.js 文件（也是我的 Webpack 配置的一部分）已经包含这方面的工作 - 只需扫描单词 asyncData 的代码。也许您可以切换配置选项 executeMixedinAsyncData 以查看这是否会改变？

,

找到了解决方法，热重载现在大约需要 2 秒。 你可以查看我的拉取请求。

https://github.com/vuestorefront/vue-storefront/pull/5560

它根本没有禁用 SSR，那么问题的根本原因是什么？ 在主 Webpack 进程中进行类型检查，因此基本上通过将其移动到另一个进程它会更快地编译。

本质上通过将 transpileOnly: true 传递给 ts-loader 它会禁用类型检查，并且通过使用 fork-ts-checker 它只会在您的开发环境中在一个单独的进程中工作，因此您可以获得最大的好处来自 TS。

对于那个实现，我基本上遵循了 Webpack docs and installed the fork-ts-checker plugin 的建议。

告诉我进展如何，就我而言，它大大提高了我的工作效率:)