首先，Next.js是个好学校，啊不，是个好框架；
其次，Next.js的文档也不算烂，但确实有点简陋，好多都是undocumented。
Next.js有个feature叫做file-system routing:
By default, Next will serve each file in/pagesunder a pathname matching the filename (eg,/pages/some-file.jsis served atsite.com/some-file.
你可以设置一个option来turn it off:
// next.config.js
module.exports = {
useFileSystemPublicRoutes: false,
}我今天谈论的重点是这个问题：当我在Components/SomeComponenet.jsx里使用router（不论是useRouter还是withRouter），都会报错，错误信息这样的：
useRouter用在functional component里；withRouter用在class component里。
React做的SPA，非常快，然而，对SEO很不友好，社交分享更是不行。
所以就必须考虑服务端渲染了，就是所谓的server side rendering。
最近在做这个迁移工作，很久了，都没搞定。一方面不太熟悉nextjs，一方面工作量也确实不小，代码复用性不是特别好，所以应该从一开始就考虑ssr，而不是做到一半再迁移过去。
其实在上一篇文章里说的开关，有一个更正式的名字：Orthogonality，翻译为中文是正交。
这个的细节以后再补充。
首先，编程本身是工程，不是科学。这就意味着条条大路通罗马，没有一个放之四海而皆准的东西。所以说，其实很多人争论的代码风格，哪个语言最好，哪个框架好，这都其实都是哲学问题，因为没有统一标准答案。
代码风格，纯粹是个人喜好，只要能通过编译，这些所谓的风格在编译后都会丢失。简单来说，编译器不在乎。当然，如果你非要抬杠说某种写法性能更好，那就是针对性能做优化。但如果无所谓性能，但着重考虑可读性和可维护性的时候，又是另一种看法了。
语言和框架更是，都是为了解决某个特定类型的问题而开发出来。你写个小博客，用不着C++，用又笨又重又慢的WordPress就挺好，杀鸡用不着牛刀。
尽管如此，在一般情况下，或者某些特定情况下，还是有最佳实践的。比如说，最近发现一个写代码的思路，就感觉很高明，非常高明，据说微软在用，而且也有v站网友提出来，感觉真的非常高明。
这个思维就是开关。
也就是说，你新增任何一个feature，都要同时提供一个switch，就是开关，而且必须做好充分的测试，确保你的软件在这个开关的两个状态下都能工作正常。而切换状态就用配置文档，最后的结果就是一套代码 + N 套配置文件的方式，让不同的人按需获得自己的feature。
这个高明的思维，首先是看知乎上有个问题，问的是为什么Office软件体积那么大，有人说Office要有开关的，而且做好了充分的测试，所以软件的体积大。当时我就觉得这个思路很牛逼，但是也仅限于感慨而已，因为这个是Office的开发模式，那我这小菜鸟能比吗？后来看到v站上有一个人提问，给一百多个医院写一套软件，但这么多医院，每个医院用不同的模块，而且对每个模块的具体功能的需求也不完全一样，怎么办？最傻的方式当然是复制N份代码，当然这后果肯定是灾难性的，无论是成本角度还是维护角度。然后就有不止一人提出用代码+配置的方式，也就是说，每个feature都是可关闭的。这样就完美解决这个难题。
其实这个思维方式，也应该用在很多其他软件上，比如有一个按理说应该很好的电商程序fecshop。这个fecshop或许真的很不错，但推广受阻，我自己也是勇敢的尝试了一次就再也没用过了。
不是这个电商程序不好，而且这个程序的定位出了问题。在第一次安装的时候，这个程序要装3个数据库，mysql， redis和mongodb。可怜我当年还不会用wsl，在Windows系统上装这三个数据库简直是不能更痛苦了。勉强跑起来了之后，感觉太强大了，不敢改代码。当然，也可以用docker来装，但到今天我还不会用docker。
所以问题出在哪里呢？定位。
第一，这是一个开源电商程序，必然会有各个层次的程序员来使用。考虑到95%的程序员都是CRUD Boy（我也是），这个电商程序的学习曲线未免太陡了。
第二， 还是定位。假如我就三个商品，比如Github这么大网站，也才3个商品，因为会员就三种，免费的，个人收费版，企业版。用得着这个吗？大量卖服务的小公司，就是5种以下的。
好，假如你是卖小商品的，比如，卖衣服的，就一个有点个性的小店，可能你的商品数量也就是一两百种，撑死三五百种，这样的一个小店，用得着三个数据库吗？
再次，就算用得着这么复杂的一套数据库，一开始用得着考虑性能问题吗？一开始MySQL一把梭，就可以解决问题，包括队列服务，都可以用MySQL。至于其他高级功能，就慢慢上呗，这个时候真的就需要开关这个思维方式了，每加一个新feature，就新增一个配置即可。如果一开始就是奔着大网站去的，注定是门槛太高，曲高和寡。
最后的最后，如果真的是大网站，为什么不用Java？MySQL够用吗？这些问题的答案是显然的。
好，说完了这个开关的思维，再复习一下UNIX哲学，其中一条是Do one thing and do one thing well。这个思维方式是第一个震撼到我的思维方式。