我开发了一个使用 React + redux + EJS(带有服务器端渲染(的应用程序，它在生产中运行良好。我已经使用 webpack 配置配置了 SSR + redux 和所有代码拆分内容。我还实现了自定义缓存中间件来缓存 SSR 渲染的 html 字符串(根据需要(。
现在，我被告知要重构代码以适应下一个框架.js并且想知道真正的需要。如果我已经找到了一种在没有 next.js 框架的情况下进行 SSR 的方法.js那么使用 next 的主要优势是什么？
我不只是在征求意见，而是在试图了解下一个.js(如果有的话(相对于CRA的真正利弊。
如果有人需要参考，我已经在这里上传了样板：https://github.com/bbest123/reactreduxssr
tl;博士
我能想到使用Next.js的唯一缺点(有点(是它是固执己见的。它需要您以某种方式构建事物，IMO 仍然非常可扩展。
使用Next的优势
- 简单的文件系统路由(加上具有
Link和预取功能的客户端路由( - 页面的自动代码拆分(使控制捆绑包大小变得简单( 开
- 箱即用的 SSR，具有更简单的 API(比自己实现(
- 将应用导出为静态网站(前提是您不需要动态服务器呈现页面(
- 更轻松地扩展您的 babel 和 webpack 配置(与未弹出的 CRA 应用程序相比(
综上所述，如果您已经在没有Next.js的情况下构建了解决方案，并且它适用于您的用例，那么IMO无需迁移到Next，除非您有兴趣抽象SSR的一些配置和工作原理(Next.js会处理(。
相关链接
- CRA讨论与Next比较的问题(有点过时了(
- CRA文档建议的CRA替代方案
Nextjs 最好的功能之一是 70+ 个实现示例列表的庞大列表，这些示例代表了 CSS 框架、存储(flux/redux/mobx/graphQL(框架、节点服务器等的几乎所有组合。
- https://github.com/zeit/next.js/tree/canary/examples
可以在没有 Next.js 的情况下构建一个反应 SSR 解决方案，但是服务器端逻辑(getInitialProps、pages/app.js等(的干净hooks使 Next.js 成为这里的首选。接下来.js通过允许您编写干净、可维护且高性能的 SSR Web 应用程序，在这里大放异彩。
最后，开发团队和社区非常棒！