用这解压神器竟能挖出这些东西

API 之间的无缝联动

通过前两篇文章，我们知道 Next.js 要解决的问题是预渲染，围绕预渲染探索出了 SSG、SSR 两种渲染模式，并在此基础上支持了包括 CSR 在内的不同渲染模式混用：

• ISR(Incremental Static Regeneration)：增量静态再生成，运行时定期重新生成静态 HTML
• SSG 降级 SSR：未命中预先生成的静态 HTML 时，立即进行 SSR
• SSR 带静态缓存：SSR 完成之后，将结果缓存起来，下次命中静态缓存直接返回(相当于 SSG)
• SSG 结合 CSR：编译时生成静态部分(页面外框)，CSR 填充动态部分(页面内容)
• SSR 联动 CSR：URL 直接访问走更快的 SSR，SPA 跳转过来走体验更优的 CSR

从 API 设计的角度乍一看，似乎需要给每种组合取个别致的名字，并暴露出专门的 API，就像 SSGwithFallback、SSRwithStaticCache、PartialSSG、SPAMode…

然而，Next.js 不仅支持了所有这些混用特性，而且没有增加任何顶层 API，它的做法是增加一些选项，例如：
 

将 Props、State、Lifecycle、Template 等框架能力整合成一个 Class，称之为组件。并且，在很长的一段时间里，React 中能称为组件的只有 Class

这段很长的时间有多长?

从 React 诞生之初一直到React Hooks推出并进化成完全形态。目前(2021/1/2)React Hooks 仍然不是完全形态，componentDidCatch、getSnapshotBeforeUpdate、getDerivedStateFromError等特性还不健全，具体见Do Hooks cover all use cases for classes?

也就是说，时至今日，React Components 仍等价于 Class Components，早期的函数式组件只能叫 Stateless Components，获得 Hooks 加持之后的函数式组件虽然摆脱了 Stateless，但与完全形态的 Class Components 还有一点点差距

将 Components 概念与 Class 强绑定在一起真是个糟糕的选择，被寄予厚望的 Hooks 充分说明了这一点。但 Props、State、Lifecycle、Template 这些框架能力又总要有东西来承载，那么，更好的选择是什么呢?

可能是 Module。强调可能，是因为仅在组织代码这一点上，Module 比 Class 更纯粹。Module 只组织代码，将变量、函数等语法元素圈在一起，而不像 Class 会强加实例状态、成员方法等额外概念

例如，Next.js 的 Page 定义就只是个文件模块：
 

本文记录了我从中发现的设计技巧，包括 API 设计、文档设计、框架设计等，也分享给你

定义基类，可能不如定义模块

首先，类(Class)和模块(Module)都是组织代码的可选方式，放到 API 设计的场景，都能用来约束写法，暴露框架能力。而在模块概念成为正统之前，前端框架大多提供基类来满足这种需要，因为没得选

典型的，React 通过React.Component基类暴露出各种生命周期 Hook，同时定义了组件写法：

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!