介绍 TypesScript 初学者经常会碰到的一些问题和技巧，了解 SFF 概念是什么以及演进历史
TypesScript
一些初学者使用 TypesScript 时容易犯的错误
TSX 和 JSX
用 JavaScript 写 React 时，对文件的扩展名没有什么特别的要求，.js 或者 .jsx 都行。
但在 TypeScript 中，如果你要使用 JSX 语法，就不能使用 .ts，必须使用 .tsx。
变量的 Type 怎么找
最直白的方法就是去看库的 Types Definition，也就是那些 .*d.ts 文件。
一般来说，这个操作可以直接把你带到你想要的地方，但考虑到类型是可以继承的，有时候一次跳转可能不太够，遇到这种情况，那就需要你随机应变一下，沿着继承关系多跳几次，直到找到你想要的内容。
多重 extends
Interface 是可以多继承的，extends 后面可以跟多个其它 Interface，我们不能保证被继承的多个 Interface 一定没有重复的属性，那么当属性重复，但类型定义不同时，最终的结果会怎么样呢？
在 TypeScript 中，Interface 会按照从右往左的顺序去合并多个被继承的 Interface，也就是说，同名属性，左边的会覆盖右边的。
obj[prop] 无法访问怎么办
定义一些集合型的数据，例如对象、枚举等，但在调用的时候，我们未必会直接通过 obj.prop 的形式去调用，可能会是以 obj[prop] 这种动态索引的形式去访问，但通过动态索引的方式就无法确定最终访问的元素是否存在，因此在 TypeScript 中，默认是不允许这种操作的。
官方文档中就有提到这个方案，官方管它叫 OptionBag，大概就是指 config、option 等用于提供配置信息的这么一类参数。
interface OptionBag {
[index: string]: any
}
Serverless For Frontend
文章对于具体 SFF 是什么介绍的不多，看完可能会懵逼，有感触的是架构演进的历史，可以参考下自己当前公司处于那个阶段，有什么可以改进的地方，首先一句话简单介绍一下几个核心阶段
- 青铜器时代：Web 2.0 时代，前端通过 Ajax 请求数据，前端负责渲染
- 蒸汽时代：微服务时代，BFF 概念：领域模型 -> UI 模型的转换，赋能前端
- 电气时代：SFF 概念：让纯前端开发者，只需写几个 Function 即可使用到后端相关的能力。
蒸汽时代架构演化为：
- 后端分为很多微服务。
- 前端还是通过 HTTP 访问后端，但接口变多了，性能变低，且带来安全问题。
- 后端会提供一层 API 粘合层来缓解。
随之而来的新的矛盾：服务下沉与用户体验灵活性的矛盾。
- 服务趋向稳定，倾向下沉。
- 用户体验趋向不稳定，诉求服务的高度灵活与定制。
- 不同设备对 API 有不同的诉求，需要裁剪。
- 服务端接口，究竟是面向 UI 还是通用服务？
面向 UI 还是通用服务，一句话让我感触很深呀
Backends For Frontends
- 服务自治 ，谁使用谁开发，带来了灵活与高效。
- BFF 根据团队的技术栈来选型，比如最能被前端接受的 Node.js。
- BFF 层一直都存在，因为 领域模型 - UI 模型 的转换是必然会存在的，区别只是在于维护者是谁。
- GraphQL 之类的网关可以视为通用型的 BFF。
这一次的进步在于：后端基于领域模型提供面向通用服务的 API，BFF 基于 RPC 协议调用后端提供的 API，同时基于自己的业务场景，为自身提供 API。接管了一部分后端的工作。