没有 SSR 的 Vuestorefront - 未触发 asyncData

Vuestorefront without SSR - asyncData not triggered

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

我用什么

  1. 官方 Vuestorefront 回购:https://github.com/vuestorefront/vue-storefront

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

  1. 优化的 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() 通常要么在浏览器中异步执行(duh!),要么在 SSR 工作时在服务器上同步执行。这意味着在默认的 VSF1 情况下,调用 this.getCurrentProduct.meta_title(在 metaInfo 方法中)永远不会失败,因为它将依赖于 Vuex 中已经同步加载的内容。然而,如果没有 SSR,这会导致代码问题,因为 Vuex 存储将在 执行 metaInfo 标签后被填充。所以重写 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 的情况下编写的(这对我来说很有意义)。

正如您所说,另一种尝试可能是对每个组件执行 asyncDatacore/client-entry.js 文件(也是我的 Webpack 配置的一部分)已经包含了这方面的工作——只需扫描代码中的单词 asyncData。也许你可以切换配置选项 executeMixedinAsyncData 看看这是否改变了什么?

找到解决方法,热重载现在大约需要 2 秒。 你可以查看我的 pull request。

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 的建议。

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