首先，感谢您创造了如此出色的工具！ Next.js 对我来说似乎是构建 Web 应用程序的“梦想框架”，它“为我们带来了两全其美”（单页应用程序和服务器端渲染）。
对我来说，帮助 Next.js 实现其承诺的最重要的部分是能够预取所有组件标签指向页面。
根据文档，此功能是使用 Service Worker 实现的，Service Worker 是一个仅支持 Chrome 和 Firefox 的 API。 这意味着很大一部分网络用户无法利用这个强大的功能。 我不知道我是否错过了什么。
我们可以使用支持所有现代浏览器的其他技术来实现预取，而不是使用 Service Worker 吗？
irrigator
所有3条评论
这意味着很大一部分网络用户无法利用这个强大的功能
这有点不真实。 请参阅： http :
浏览器正在朝这个方向发展，很快就会迎头赶上。
无论如何，我们当前的重点是发布 2.0，并且当前的预取解决方案非常适合这一点。
如果有人可以解决这个建议，我认为我们没有理由拒绝。
（而且完全有可能在用户空间中做到这一点）
arunoda
于 2016-12-26
❤1
我在这里注意到了一些扩大支持的想法，即使用 AppCache： https :
sedubois
于 2016-12-26
多年来一直为我们服务的一个原则是为所有浏览器提供 _support_，但为现代浏览器提供 _optimizations_。
预取是一种优化。 将越来越多的代码投入到将被弃用的优化中（因为所有现代用户代理都支持ServiceWorker或计划这样做）似乎不是一个很好的关注领域。
如果您愿意，可以随意创建自己的用户空间预取模块，该模块公开与next/prefetch相同的 API。 整洁的事情是：如果你不使用next/prefetch ，它就不会进入构建。 没有膨胀:)
rauchg
于 2016-12-29
👍2
此页面是否有帮助？
0 / 5 - 0 等级
相关问题
ghost
·
3评论
YarivGilad
·
3评论
DvirSh
·
3评论
timneutkens
·
3评论
rauchg
·
3评论
最有用的评论
多年来一直为我们服务的一个原则是为所有浏览器提供 _support_，但为现代浏览器提供 _optimizations_。
预取是一种优化。 将越来越多的代码投入到将被弃用的优化中（因为所有现代用户代理都支持
ServiceWorker或计划这样做）似乎不是一个很好的关注领域。如果您愿意，可以随意创建自己的用户空间预取模块，该模块公开与
next/prefetch相同的 API。 整洁的事情是：如果你不使用next/prefetch，它就不会进入构建。 没有膨胀:)