介绍
由于产品需求，我决定不需要 SSR，所以我退出 next.js 并将其重新构建为 SPA。我经常看到关于next.js本身的know-how以及从SPA迁移到next.js的文章，但据我所知（我使用它是因为我没有很好地研究它）我不记得了，所以我认为它可能值得写。我想写一下决定的背景和实际迁移的程序。
我不会声称这是最佳实践，而是我在不完善地修复代码，所以如果你有任何诀窍可以更容易地做到这一点，如果你能教我，我会很高兴.
背景
参与已经具备简单功能的项目
当我被分配时，项目已经开始运行，并且已经创建了一些屏幕和功能。使用了 Next.js，后端配置为使用 firebase 身份验证和 firestore。
考虑使用 SDK
当我修改现有代码时，我开始感到不方便。在操作firebase资源时，我们有一个配置通过一个API来操作firestore，该API考虑到项目的需求和Web以外的其他渠道的需求。但是这个API是按照其他渠道的要求来实现的，网上有问题。另一方面，很明显，随着我们对 Web 渠道的改进，API 规范将变得越来越复杂。
因此，我们调查了Web客户端在使用SDK时是否能达到要求。结果，我们得出的结论是使用 sdk 就可以了，我们继续进行改造，将现有代码替换为 sdk。
尝试将firebase与SSR一起使用时非常麻烦
然而，我们面临挑战。顾名思义，SSR是在服务端渲染的，所以需要考虑初始化。例如，即使客户端通过了身份验证，服务器端也没有通过身份验证，因此会出现身份验证错误。这意味着它不能使用与 SPA 相同的胶水来实现。需要考虑在 SSR 时假设服务器使用 firebase-admin，并在 CSR 部分使用 firebase-sdk。
参考：
https://qiita.com/centerfield77/items/799f2840f48221c2f84d
如果您尝试将 firesbase 与 next.js 一起使用，您将不得不考虑这一领域。
当我考虑这个问题时，我认为 SSR 本身是没有必要的。在故事里
总的来说，SSR的优点是：
- 由于是在服务器端渲染的，所以初始显示速度快且稳定。
- 搜索引擎优化
我认为有这样的点。但是，我得出的结论是，就要求而言，这些优势并不是特别必要的。
由于我们会继续使用SSR，预计可能会有需要单独考虑的点，而且内置函数的数量有限，所以我们将其替换为SPA。我得出了结论。首先，我在 SSR 开发方面没有太多经验，所以我认为有更多经验的人可能会做出不同的决定。
移民
这是我在迁移期间所做的。
一次性全部清除
在从最新的主分支切出的工作分支中，项目的内容被删除了一次。我想如果我在保留它的同时更换它，我会很难，因为它会继续不完整。由于它是由git管理的，因此可以立即恢复。
用 vite 初始化
还有其他各种选择，例如 CRA 和 snowpack，但这次我选择了 vite。一旦知道vite的速度，就停不下来。
添加各种现有库
yarn addyarn addyarn add提供功能所需的库，不管 next.js。添加替换库
next.js 函数和库提供的替换函数假定在服务器端工作。例如：
路由
这是
react-router-dom。我以前从未使用过 v6，所以我想尝试一下。暂时舒服。解码jwt
应用有JWT解码过程，但是
jsonwebtoken应该是在node环境下工作的，在web上是不行的。替换为jwt-decode。我有一种感觉，这些考虑会随着功能数量的增加而增加。按顺序恢复和更换
首先恢复与反应无关的事物
github工作流和husky脚本基本可以原样使用（虽然里面的命令已经被替换），所以会恢复原样。其他可以按原样使用的东西都被恢复了。在查看情况时将恢复可以原样使用的组件。
修复需要修复的东西
另一方面，next.js 的 pages/ 下的文件使用相同的目录结构进行路由，因此需要对其进行修改。在不更改基本配置的情况下，我创建了一个类似
Router.tsx的文件并编写了路由的代码。这时候我在React.lazy做了代码拆分等最小的调整。操作检查
最后，检查一次操作就完成了。
在最后
这次恰恰相反，写的是退出next.js的故事以及背景和过渡。我在有限的时间内根据需求和研究范围得出了上述结论，但是如果我从构建之初就参与其中或者对NextJS开发有更多的经验和知识，我会做出不同的决定。也觉得有可能。在这方面，我想继续加深我在广泛领域的经验和知识，并能够选择当时最好的技术。
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308622566.html