同样做前端，为何差距越来越大？(2)

下图是一个前端应用常见的4层架构。 代码和工具全面拥抱 TS 后，实现了从后端 API 接口到 View 组件的全链路静态分析，具有了完善的代码提示和校验能力。

前后端协作简图

除了上面讲的 iron-redux，我们还引入 Pont 【5】实现前端取数，它可以自动把后端 API 映射到前端可调用的请求方法。

Pont 实现原理：(法语：桥) 是我们研发的前端取数层框架。对接的后端 API 使用 Java Swagger，Swagger 能提供所有 API 的元信息，包括请求和响应的类型格式。Pont 解析 API 元信息生成 TS 的取数函数，这些取数函数类型完美，并挂载到 API 模块下。最终代码中取数效果是这样的：

Pont 实现的效果有：

1. 根据方法名自动匹配 url、method，并且对应到 prams、response 类型完美，并能自动提示;
2. 后端 API 接口变更后，前端相关联的请求会自动报错，再也不担心后端悄悄改接口前端不知晓;
3. 再也不需要前后端接口约定文档，使用代码保证前端取数和后端接口定义完全一致。

另外 iron-redux 能接收到 Pont 接口响应数据格式，并推导出整个 Redux 状态树的静态类型定义，Store 中的数据完美的类型提示。效果如下：

最终 TS 让代码更加健壮，尤其是对于大型项目，编译通过几乎就代表运行正常，也给重构增加了很多信心。

三、回归 Sass/Less

2015 年我们就开始实践 CSS Modules，包括后来的 styled-components 等，到 2019 年 css-in-js 方案依旧争论不休，虽然它确实解决了一些 CSS 语言天生的问题，但同时增加了不少成本，新手不够友好、全局样式覆盖成本高涨、伪类处理复杂、与AntD等组件库结合有坑。与此同时 Sass/Less 社区也在飞速发展，尤其是 Stylelint 【6】的成熟，可以通过技术约束的手段来避免 CSS 的 Bad Parts。

1. 全局污染：约定每个样式文件只能有一个顶级类，如 .home-page{ .top-nav {/

   （编辑：ASP站长网）